Nine months. The time it takes from conception to development of a fully-functional human being with their own thoughts, feeling, hopes, dreams and ambitions. That's how long the Standard Library team has been working to develop the latest iteration of our product, Build on Standard Library. Today, we're excited to launch it to the world.

Introducing Build on Standard Library

Build on Standard Library, to put it simply, is workflow automation — similar in spirit to well-known products like Zapier — custom designed for developers, with professional engineering tools of the trade like environments, version control, rollbacks, the ability to build custom connectors using FunctionScript API schemas and more built-in. There are no black boxes, everything that you can build with our user interfaces is completely decomposable to code. Build, as we refer to it, is the culmination of tens of Hackathons, hundreds of customer introductions and interviews, and thousands of hours of developers both building and running APIs and workflows atop our API platform.

There's a lot we can say about Build, but this six minute demo video captures most of the product capabilities.

Why Build? A Brief History of Standard Library

The core mission of Standard Library has always been to make the web more programmable with APIs. Three years ago, in the summer of 2016, we realized there was something obviously missing from the World Wide Web. APIs, or more aptly, remote procedure calls, have never been given a formal definition as part of the Web's specification. As a result, the developer community has spent the past three decades iterating on server-side scripting technologies and interface patterns — SOAP, REST, GraphQL, OpenAPI, YAML configuration and more.

Serverless web technologies and the rise of Node.js made something readily apparent: for better or worse, the accessibility of JavaScript in the browser had opened up software development to a brand new cohort of developers. All you needed was a text editor and a browser. We surmised that the main consequence of the introduction of serverless architectures (no infrastructure management) would be the commoditization of back-end development, likely to herald the same sort of "Cambrian explosion" we saw in front-end development in the early 2000s that continues to this day.

This led us to begin work on Standard Library, a central registry for building, organizing, and executing APIs. After all — if we were likely to see an explosion in the amount of APIs being developed by a larger constituency of developers, we would need a way to organize them. There were two major problems with this thesis. First, we were effectively nobodies. Who would listen to us? Second, as we launched the first few iterations of our product it became clear that the largest problem we faced with adoption of our proposed "Standard Library" was developer and Enterprise inertia. The value proposition of automatically generated API docs combined with hosting may have been appealing as a corner of, say, the AWS or Azure cloud — but it was not turning heads coming from a meager team of two software engineers (myself and Jacob Lee).

So, we added another software engineer in the summer of 2017, Steve. And we worked tirelessly — somewhat behind the scenes — to recruit some of the most successful companies and individuals to our corner. Over the years we've received investment from the original author of RubyGems: Chad Fowler, Slack, Stripe, folks like Carter Rabasa who helped lead development of Twilio Functions, and many, many more. Our friends and supporters have been equally helpful in keeping us moving forward — Ahmad Nassri, CTO of NPM, Evan You, author of Vue.js, Ben Tossell, founder of MakerPad, and Romain Huet, head of Developer Relations at Stripe — to name just a few.

Build on Standard Library — Connecting APIs

We have always had and continue to maintain a strong belief in our mission. Our command line tools and even our in-browser editor weren't enough, we realized that if we were to succeed in "making the web more programmable" we would need to create a product that leverages the technologies we've built to make API composition orders of magnitude more accessible, especially to new entrants to software development. Some refer to this as the "low-code" movement, we simply see it as a natural progression of software development accessibility. Speaking to students at Hackathons and some of the most enthusiastic early Standard Library developers, we noticed that these new entrants to software development wanted to build software even though they were not necessarily industry professionals. We asked ourselves, "can we build something easy enough for anybody to use, but flexible enough for professional, and even Enterprise engineering teams?"

In response to this question, Build on Standard Library was truly born after a brief discussion with Patrick Collison, when he asked me why — given a free hour of time, of which he doesn't find often — the most difficult part of scripting against the Stripe ecosystem was finding the environment variables he needed to connect to all of their internal apps. Everything clicked. The following nine months led to the development of:

  • FunctionScript, a language and specification for turning Node.js functions into typed HTTP APIs
  • KeyQL, a simple query language that can be used to do things like turn Google Sheets spreadsheets into queryable databases
  • Identity Tokens, the federated identity (keychain) model of API accession that allows you to link multiple resources from different apps / APIs to a single key
  • Incorporation of RunKit's technology to be able to prototype and script without first shipping to a cloud platform
  • Leveraging FunctionScript schemas to automatically generate clean user interfaces

The first version of Build took five months to build, with three engineers. We had close to two years of platform development backing it. We started testing it with customers and users.

It was promising, but it kind of sucked. We realized that a lot of APIs (Google Sheets, as a prime example) were in no way actually designed for usability — they instead opted for flexibility, providing a robust but difficult to reason about interface, expecting keen software engineers to simply, "figure it the hell out." These keen developers were not representative of the most enthusiastic early adopters of our platform. So we started shipping our own APIs as abstractions on top of existing ones, following the design mantra of, *"a non-developer has to be able to easily use this from a form-based interface, and a professional engineer has to still feel like it's flexible enough"*.

Four painstaking months later, and countless sleepless nights, we finally feel like we're able to deliver the seed of a product we can feel proud about.

So, at 3AM, from a hotel in Toronto that we haven't left all week, we're launching Build on Standard Library to the world.

You can check us out on Product Hunt → Build on Standard Library or simply visit to get started.

What's Next?

This is only the beginning. We have hundreds, thousands of API "connectors" to build. Our platform is open — while source code of APIs is not visible, anybody is free to publish an interface and host their code on our platform. To have your connector officially added, you need only ask us to verify that it is (1) not malicious and (2) ideally, officially sponsored by the corporate entity it's communicating with, if applicable. For now, we'll need to create an auth process for you manually. In the meantime, we'll be adding connectors ourselves, prioritized by company partnerships. You can expect to see the Slack and Stripe APIs fully supported, with new (some unannounced) partnerships coming soon.

You can get started with our Documentation if you want to know the ins and outs of our platform. We've set up a very permissive free tier for you to play with, it should not restrict your ability to develop upon us in any way.

  • Free, unlimited workflow projects
  • Free, unlimited steps in your workflows
  • Free observability with built-in logging and error detection
  • Free conditional logic as part of your workflows
  • Free version control and project history, including rollbacks
  • Free customization of any workflow, with code
  • Free general API and webhook development

Our paid tier starts at $15/mo and adds a few nifty features for the power users in the crowd:

  • Upgrade from 1 environment (dev) per project → unlimited environments
  • Upgrade from 3 additional collaborators per project → 5 additional collaborators
  • Upgrade from 3 Linked Resources per Identity → unlimited Linked Resources
    • Please see the Identity section in our docs for more details.
  • Upgrade from 1 General Use Identity Token3 General Use Identity Tokens
    • Please see the Identity section in our docs for more details.
  • Upgrade from $5.00 in available platform credits per month → $15.00
    • Supports roughly 750,000 × 100ms requests
    • Workflows are billed at an on-demand rate of $0.0002 per second while running, rounded to the nearest millisecond
    • There is a minimum billed time of 100ms per request
    • Some APIs you can connect with, like utils/sms, bill you per request made to them ($0.01 per request in this example).
  • Additional rollover credits can be purchased based on usage that roll over to your next month's balance (never overpay or force a tier upgrade)

Let us know what else you'd like to see from us at any time, and feel free to peruse pricing on our Pricing page.

Thank You

Before we let you go, we are of course compelled to let you know that we're hiring. E-mail us your resume. That e-mail, as it stands, gets directly forwarded to my inbox.

We hope you'll support us in our endeavour. It's ambitious, it will be difficult, but we want to make building software easier for everybody. We truly want to make the web more programmable.

Thanks for all of your support. It means the world. And, as always, happy building.

Keith Horwood
Founder and CEO, Standard Library