Explore

Pack Studio: Five lessons from building a platform with the garage door open

How we launched a platform for developers...and everyone else

Punit Shah

Alicia Salvino

Published July 25, 2022

Last month, we launched

Pack Studio⁠

, a way for any user to build extensions and integrations for Coda. Packs add new powers to your doc by supplementing Coda’s core building blocks. And makers from all technical levels have already impressed us with their ingenuity (

here’s just one example⁠

We’re the designer (Alicia) and product manager (Punit) behind Packs, and we wanted to give you a peek into the journey here.

Our vision: The doc that brings it all together for any team.

At Coda, we’re building an all-in-one doc that brings your words, data, and team together. Coda comes with a set of building blocksーlike pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your docーso anyone can make a doc as powerful as an app. But until recently, only the Coda team could create these building blocks.

With an open Packs platform, we hope to unlock opportunities for anyone to be successful - be it a product team in San Francisco, a real estate agent in Kampala, or a dairy farm manager in Tokyo.

This vision requires three promises:

You can build what you need, from robust integrations to custom visualizations and formulas.

You don’t have to be a software engineer to build a Pack — but you’ll still love the process if you are.

You can build a business making Packs for the world’s most innovative teams, who in turn get amazing solutions at their fingertips (we’ll share more on this in a few weeks).

An API isn’t enough.

One common way many companies try to achieve these goals is through an API that lets anyone connect to their service. We launched an API four years ago and saw teams use Coda docs as databases and makers building DIY template sales systems. But it takes a lot of mastery, time, and effort to get going. While powerful (and we’re still fully supporting our API!), it felt insufficient for our larger vision because:

Only professional software engineers have the skills to build extensions.

These extensions can’t be discovered or used directly within a Coda doc.

The result? A limited set of extensions for few teams that feel disconnected from the user experience.

But we realized citizen developers are everywhere. They may have taken an intro programming class or are just now picking up coding on the side. They can code but aren’t experts at it. They’re the people in your company who hack a solution together, your friend who used to build websites as a hobby, or maybe even you.

How we might build a way for professional and citizen developers to create building blocks directly inside the doc? This question shifted how we designed the product from the ground up.

⁠

Our five product principles.

We answered that question with five principles:

1. Make simple things simple, and complex things possible.

Early on, we explored simplifying Pack building as much as possible. For example, what if you could build a Pack just like writing text in a special type of doc? We found this meant sacrificing power for ease. It prevented motivated, skilled users from being able to do as much. Setting up important features like authentication or sharing Packs with your team felt confusing and difficult.

Instead, we aimed for

simplicity that’s helpful for all⁠

— professional and citizen developers.

A better citizen developer experience led to a better professional developer experience. When we decided to allow Pack building in the browser, everyone could get started more quickly, even if they later transitioned to

our more advanced tools⁠

. When we built good code examples to help those less confident write code from scratch, everyone built Packs faster.

2. Inspire citizen developers in 60 seconds.

Citizen developers can build amazing things. However, our research showed many makers had internalized an identity that they’re “non-technical” or less capable than they actually are. They’ve seen other tools make coding feel complicated, built only for the “hackers” and “l33t” among us. They felt excitement and curiosity for what’s possible — mixed with anxiety, fear, and confusion upon seeing code.

We aimed to show makers their true potential quickly, to motivate them and move beyond this identity. This meant helping them build a working Pack in less than 60 seconds.

Quick affirmation counters the initial headwinds of anxiety. Anything to download? Nope, do it in the browser. Anything to set up or copy and paste? No, just pre-fill examples and set sensible defaults. We made sure to show the maker they can truly build a Pack in just a few clicks. And we found that these emotional assurances benefited even the most advanced developers.

3. Speed up test-and-iterate loops by making every keystroke count.

Building software usually involves doing a lot of things that aren’t just writing code: loading libraries, digging through samples and documentation, managing multiple tabs, understanding the unique nuances/fields of the given API or error, and more. For citizen developers, these issues are particularly painful and intimidating.

Our goal: Make every keystroke a brick in the wall. Omit fluff.

We reduced “figuring things out” time with the / command to give you template code at your fingertips when adding a new building block to the Pack. We automated common tasks such as auto-updating test docs with the latest code. And we made debugging easier with error logs available right inside the doc including support for console.log(), which nearly everyone writing JavaScript knows.

4. Treat code as UI.

Makers will spend significant time writing code, so it’s a primary user interface. We wanted to make Pack code feel familiar yet still powerful for both professional and citizen developers.

We focused on making Pack code readable and simple, with room to expand for more advanced developers. We wanted to maximize the ratio of code that’s unique to the Pack vs. generic to all packs.

JavaScript was an obvious choice — it’s the most common scripting language. Our code examples largely follow common JS patterns over the last 10 years. We designed the code to be modular, making it easy to copy and paste small snippets. We formatted and commented sample code to read as simply as possible.

But JS has evolved over the years. While our examples avoid

more “jargony” code patterns⁠

, Packs work with these newer, slick syntaxes. And for those who want robust typing, Typescript is optional but enabled.

5. Build the platform with the garage door open.

It’s difficult to know what users will make and what issues they’ll encounter with an open platform. We immersed every single team member in research from day one and opened our platform to feedback as quickly as possible. This built empathy, guiding our later choices and motivating fast progress.

⁠

Start building a Pack today!

As we’ve gradually brought more makers onto the platform, their reactions have been incredible. Coda Packs have become a primary income source for some makers and unlocked new possibilities for teams. This is why we built the platform, and it’s exciting seeing that impact in real-time.

Whether you’ve lived in code for decades, or literally never tried (

just like Scott!⁠

), we’d love to see the Packs you make. Until August 3, you can join our Packathon by building a Pack for a chance at $20,000 in prizes.

⁠

Build a pack in 60 seconds

⁠

Learn more about the Packathon

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.