Step inside our new Developer Platform

It’s finally here. For months we’ve been working to release our new Developer Platform and Developer Portal. And we’ve learned a lot.

We’d love to share our experience along this journey, and tell you all about the technical goodies you should be excited about. But to spare you future headaches, let’s first take a quick step back.

UX as a service

Here was our goal: build a developer community around our new Developer Platform. This includes the technology underlying our Application Programming Interfaces (APIs), Webhooks, and Embed Software Development Kit (SDK), along with our Developer Portal.

It started way back when we launched Typeform.io—a standalone beta, consisting of APIs to create and manage forms. People were building amazing apps with it, and developers were excited about “UX as a service.”

But after talking with lots of Typeform.io developers, we saw a clear problem: users wanted their forms to live in their Typeform.com account, and this just wasn’t possible with the existing platform. (psst: if you’re a Typeform.io developer, please reach out and we’ll help you transition to our new APIs.)

And then there’s Typeform Version 2 (V2), a brand new version of Typeform with a completely revamped UX that needed a total architecture overhaul. More on this soon.

So with .io and V2 in mind, we began a massive migration from one big PHP application to a series of Golang microservices. Translation: the architecture and APIs that now power our Dev Platform are the exact same as those under the hood of Typeform.com.

Basically, we’re pretty confident you’ll be stepping into a badass developer experience.

Building the ultimate developer experience

In the world of interface design, you often hear about UX—the user experience. In the developer world, we talk more about DX—you guessed it—the developer experience.

A lot of organizations think of DX as the UX of their developer portal. We went in with a different mindset. Here’s why.

1. Technical users spend a lot of time using products like APIs with no obvious user interface. This makes it hard to improve the visual look of these products.

2. Interacting with technical products often happens without visiting a login page, exploring an account dashboard, or hitting an interface’s button. This makes it hard to manage the user journey like you do with everyday apps.

It turns out that Typeform’s Developer Platform has two major interfaces where design principles apply:

Technical documentation

We want developers to discover our new tools, imagine possibilities, and start using them right off the bat. But unlike everyday apps, reading documentation is a must when messing with technical products. So we made the structure, content, and readability of our documentation a key part of our strategy.

API usability

If people start tinkering with a shoddy product, they’re not going to stick around. So we knew we had to nail the API experience. Even without reading the technical docs, a developer should have a good sense of what an API can do. This means that the domain language used in the URLs, request/response models, and any parameters had to be intuitive.

For this, two simple principles go a long way:

• Use your end-users’ domain language

• Think more is less: simpler models are always easier to understand

We’re pleased with how far we’ve come, but we know we still have work to do. That’s why we’re investigating things like SDKs in a variety of languages. Simple version: it’ll make creating new projects using APIs or Webhooks a lot less intimidating.

Are you interested in SDKs? You can get involved here.

Don’t build in a bubble

It’s one of the easiest mistakes to make. You set out to build an amazing set of dev tools, and you start by creating a dedicated API team. Next thing you know, these select few are off building in a bubble.

We knew that to transform our vision into a platform people wanted, we had to draw on almost every part of our organization. This meant that virtually all our product development teams—with their 70+ team members—would be building microservices.

One initiative that makes this possible is OpenAPI. It’s the first stop for any team proposing API designs. We also use OpenAPI to share designs with collaborators. The result? Higher quality feedback sooner, from lots of non-technical stakeholders.

And then there’s the other side of the office. By including our Marketing, Customer Success, and other non-technical teams, we were able to create a better experience for both developers and business-oriented users.

First lesson: collaboration. Now we’ve got the whole organization on board. So as we move forward into more platform-centric thinking, we’ll have everyone up to speed and contributing in their areas of expertise.

Next lesson: understand your audience.

Developer tries, business buys

Creating a technical platform isn’t just about communicating with a technical audience. This is what our Developer Portal is all about.

With our customers and partners, we often see that “developer tries, business buys.” Basically, developers are strong influencers, but they’re not often the final decision makers.

Here’s an example. Whenever a Typeform user exceeds around 100 responses, they start moving toward automation. This typically happens in two steps:

1. Use “point-and-click” integration options like Zapier to connect their typeform to their favorite apps or systems of record.

2. Build custom solutions for integrating with their proprietary backends when dedicated development resources become available.

To make this happen, business users have to validate whether a product has sufficient developer tooling/APIs to integrate into their product’s infrastructure. And to do this, they need a quick way to review what’s possible before bugging their engineering teams.

There’s nothing worse than asking a developer to build something that isn’t possible, especially when you’re already paying for the product.

So what have we done for you? We’ve made a huge effort to create intro content in non-technical terms. We describe the functionality of the API without going into the 1s and 0s.

For example, for the Create API you’ll find this:

Even our Marketing Department understands this stuff. In fact, everyone can learn a lot about developer capabilities from our Developer Portal. We’ve seen it first hand. Numerous non-technical Typeformers have had “aha” moments after giving the content a cursory read.

Give it a spin

Now that you’ve heard a little about how we built our Developer Platform, here’s some ways you can already use it:

• OAuth 2: set up integrations without copying and pasting an API key.

• Create API: create, update, delete, and customize typeforms, themes, and images on the fly, without using the Typeform builder.

• Webhooks configuration API: tell Typeform where your server is located, so we can send responses directly to your URL via Webhooks.

• Responses API: access the submissions for your typeforms in JSON format, without setting up webhooks or third-party integrations.

• Embed SDK: integrate your typeform straight into your website or web app—you get seamless integration, and people won’t have to leave your site to respond.

Ready to give it a spin? Take a look at our “Get Started” page for some high-level ideas, and step-by-step guides for getting set up. We can’t wait to see what you’ll come up with!

By the way, our own developers have already started building new off-platform integrations using our APIs. We’re also working with new partners to integrate Typeform into some of your favorite products using these same tools. Stay tuned.

You’ll also be able to create typeforms and connect them directly to the data inside products you’re already using. And very soon, you’ll see Typeform connected with more platforms, including a Cloudflare app.

Follow-up posts on these new integrations are in production, so check back often.

In the meantime, let us know what you built, or are planning to build, and please pass the word around!

See you on the Interwebs 🙂