Why I Chose to ‘Build in Public’ for my 4th Startup

It’s scary to have your work out there in the public eye. What if it’s not good enough? What if we’re not on the right track? What if we look foolish? All these insecurities are human, and CTOs are not immune from having them. But I can also tell you that they are the best reasons to build something (you’re incredibly passionate about) in public. Why? Because transparency and community involvement help us in both the short and long term.

This is my 4th startup and have seen many ups and down in my decade long journey. I saw quick explosive growth in my mobile gaming startup, an acquisition of my payment startup, failure of an AI based startup and numerous pivots in between. I’ve also seen investments from marquee investors like Sequoia, Accel and YC. And then worked for a few years to cool off. But the startup bug in me is too strong and I decided to startup again.

Along with my co-founders, I am now building Appsmith, a drag-and-drop framework to build functional and beautiful internal tools.

Well, I was the one building them and maintaining them in my previous companies. I know the drill all too well: There’s never enough time, specs are ever-evolving, and resources are always low. And they’re relevant at all stages of the organization. For a young startup, they’re critical as you find early scale and you need tools to automate the various tasks so that your engineering team has the time to focus on building our core product. And as a large company, you need a way to manage the hundreds of various internal tools that you have as well as use it as a way to empower multiple teams to take decisions without it burdening the engineering team.

It’s not just source code that’s public; everything we do, including our design strategy, is available for public view. (Our Figma files and Miro boards if you’re curious!)

Building in public is something I’ve begun to love, I’ll tell you why.

When you have a like-minded yet diverse community working together to create a product, the quality and value spec is incredibly high. The spirit of collaboration to solve problems drives open source projects. I can say this is true for Appsmith. For us, public road-mapping worked in a few different ways. It helped us get our priorities right and allocate the right resources for features. It also helped us engage with our community, gain valuable users’ input, and keep them hooked.

While we initially hoped to build a JS Editor quite early in our product lifecycle, it kept falling from our priority list. Having a highly engaged community repeatedly bring it up, helped us stay accountable to our plans. When we launched the JS Editor, everyone loved it!

Not just this, Git Sync is another community-led feature that we’re almost ready to launch, and it will enable developers to version control their apps. In fact, what we considered as some of Appsmith’s smaller features like the audio recorder widget, and document viewer were prioritized because people asked for it! One of our users contributed a custom chart widget which increased the availability of chart options to 100+!

Good things are great, but bad things take you to hell. There was a time when we introduced a change in how the row selections work in the Table widget (our most used widget). From a technical and UX point of view, it was an improvement to the Table widget. However, it inadvertently broke a lot of user applications. Feedback was unrelenting! We reverted the change within two days, and are now extremely cautious about versioning our changes so that existing user applications don’t break. It was a critical learning moment for us.

By trial and error, we have learned to think more deeply about product architecture before building on it.

Everyone can openly see what we are working on, create new feature requests, influence product features before they are formally rolled out, and inspect the actual code base to understand why a particular bug exists. In some scenarios, they can also help us fix it! With all this openness comes honesty. And you don’t really have to ask twice for honest feedback from developers! While they can be brutal, they can also be loyal and supportive.

We often felt convinced about a feature internally, but immediate user feedback made us re-examine our decisions. Let me share a few examples here:

Floating Property Pane: We believed it was better to have the property pane as close to the widget as possible, assuming that it would make the property pane better. However, based on feedback from the community, we’ve now docked it to the right-hand side of the app, and of course, the response has been tremendous.

Entity Explorer: We modeled our entity explorer after VSCode to make all the relevant widgets, files, etc., more visible and accessible. We got feedback from users that it’s very cluttered and hard to navigate the explorer menu. We’re now simplifying and making it easier to read and grok for larger applications.

Deployments: Appsmith requires five Docker containers to run (Server, Client, MongoDB, Redis, and Auto update). Earlier, we shipped with a script that would configure all these containers as we believed that it would give developers flexibility in their installations. But we saw a lot of failures. We immediately changed course and now ship with a single container with everything included. Users installing Appsmith now see a 100% success rate on the first install. This is a massive difference in terms of experience.

We think of this feedback as a precious two-way communication, where we can evaluate our product thinking by involving our direct stakeholders (our users) in the conversation. It’s honest, it’s raw, and it’s a fantastic north star to have.

Transparency isn’t just great for us, it’s great for the entire ecosystem. Sure, features can be copied, but users’ love and investment in a product can never be copied or stolen.

At the heart of building in public is trust. Trust is a hard-earned, fragile value that no marketing spend can buy. We invest our time and energy into our product, and we see our incredible community of users do the same. What will help us go forward is to develop our user education initiatives to empower our users and make time to always listen to what our users have to say. Our learnings are as critical as our wins. I see them as essential milestones; they become moments of learning from the community.

As we’re pushing into 2022, I can’t help but think of the tremendous growth we’ve had here at Appsmith in the last 365 days. In quantitative terms, it has meant adding 28 new drag and drop UI elements to our widget library, increasing data source integrations to 16, fixing 3267 bugs. I could go on (alternatively, you can look at our exhaustive year-ender page)! Putting everything out there for public scrutiny has helped us take an authentic look at our production priorities, enabling us to focus on things that truly matter to our organization: Enabling developers to do their best!

A version of this blog was previously published on Product Coalition.