Jut Built a Language for the Data Deluge. Then It Had to Teach People to Speak It.

A computer throws an error at three in the morning. The log knows something. A metric knows something else. A deployment event knows when the trouble started. Yet the person on call may need three screens, three query habits and a heroic amount of patience to assemble the answer. Jut, the San Francisco software company founded in 2013, was built around that small, maddening gap between having data and understanding what happened.

Founder and CEO Steve McCanne had a name for the collection of disconnected operational tools: the “Franken-ops problem.” Jut's proposed cure was an Operations Data Hub that would bring logs, metrics and events into a common backend, then let people question live streams and stored records through Juttle, a language the company made for the job. It was an ambitious piece of software. It also placed a new question in front of the customer: would a team learn another language to escape the old tool pile?

The bill for a cleaner picture

In November 2013, while Jut was still in stealth, Accel Partners led a $20 million Series B, with Lightspeed Venture Partners and Wing participating. That figure is the capital raised, not a published price for the product. The public record does not establish a customer subscription price. What it does show is the scale of the wager: two years of building before the open beta arrived in June 2015.

McCanne, previously Riverbed Technology's chief technology officer, described two unsatisfying choices for software teams. They could build their own analytics environment with tools such as Hadoop or Spark and write the plumbing in Java or Scala. Every new question then threatened to become another development task. Or they could buy separate products, each with its own store, interface and assumptions about the data. Jut put itself between those options: one operational backend with a programmable analytics layer.

The distinction mattered in practice. A team could compare a spike in CPU activity with application errors, then put those observations beside a release event. Jut pitched that same data for troubleshooting, performance analysis and understanding how software was used. The first buyer of this argument was the developer or DevOps team; McCanne expected them to create interfaces that analysts and other colleagues could use without knowing the machinery underneath.

One language, two kinds of time

Juttle was Jut's claim to difference. Its dataflow syntax was meant to pose questions to both data arriving now and data already saved. The company's published command-line examples show what that meant more clearly than any slogan. One program reconstructed error logs from multiple hosts in time order. Another turned CPU readings into a sustained high-usage alert. A third counted incoming points. These were ordinary operations questions, made portable by a common way to read, filter, transform and display data.

That was the technical elegance. It was also the product's first obvious strain. Sajid Reshamwala, who joined Jut's product design work in late 2014, wrote that a conventional graphical interface let people begin quickly but could limit them later. Juttle offered much more flexibility, yet users found it hard to become comfortable with. The trade was familiar to anyone who has watched an expert type one graceful command while a newcomer searches the screen for the first button.

“The power of a language, the accessibility of a GUI.”Jut product designer Sajid Reshamwala, describing the design challenge

The team's response is more interesting than a tidy success story. Customer conversations showed where workflows broke down. Reshamwala says they ran a design sprint, developed a shared product vision, added two applications around the existing language and built a reusable design system. They worked on an onboarding flow to help users arrive without immediately facing a blank programming editor. None of that weakened the language. It made the route toward it less abrupt.

What customers were actually buying

Jut's beta used a hybrid SaaS model. Its pitch gave organizations control over operational data whether their software ran in a public cloud or their own data center. It was enterprise software for teams living with both kinds of infrastructure, and a direct alternative to building a custom operations data platform or stitching together several commercial tools. The company also put command-line utilities on GitHub, which let technically inclined users run Juttle and move data from the shell.

The company offered an open beta and a free trial. McCanne said in August 2015 that customers around the world were processing billions of data points on Jut. That is a founder's account of data volume, not a published count of paying customers. Named customer case studies and product pricing are not part of the visible record, so the useful measure here is narrower: the platform had reached real users at meaningful data volumes, while its team was still learning how to make adoption easier.

Jut's product design archive supplies one memorable detail. The team made a “Creature Graph,” a little data monster intended to show the health of incoming data at a glance. It sounds like comic relief in a room of engineers discussing ingestion. It was also a compact design decision: if the data pipeline is sick, the user should be able to see that before composing a clever query about it.

The lesson in the learning curve

The reusable idea in Jut's history is quite specific. Start with a real repeated question: what happened around this error, on which host, after which change? Put the relevant streams where they can meet. Then watch how a new user tries to answer that question. Jut's designer did the latter and found the language was both the source of the product's power and a barrier to reaching it. Example boards, onboarding and visual exploration were attempts to shorten that distance.

This approach asks a lot of its setting. A common backend has to ingest the sources a team actually uses. A language earns its keep when questions change often enough that fixed dashboards become a cage. And the users need either the time to learn it or a visual route that lets them get value before they do. For a simple monitoring need, a single ready-made tool may cost less effort. Jut's most persuasive use case was the messy one: several data types, several systems, and questions no vendor had anticipated.

In 2015, McCanne was already imagining interoperable applications built on the hub. That vision followed naturally from the product's architecture: once the data and queries have a common language, one team's answer can become another team's tool. The surviving story is not a claim that Jut solved every operational mystery. It is a sharper observation about software design. Sometimes the difficult part of inventing a language is building the door through which people can enter it.