There's a lot of hype about no-code tools right now. Investors want to fund them, founders see them as a secret weapon, and engineers roll their eyes at them.
There's no question that the fastest way to get traction with your startup is building it on top of no-code tools. But what happens then?
Part 1: I built my first startup on a no-code stack
Let's say your startup is growing exponentially. You're built on a no-code stack. You know there's a point where you'll outgrow it, but you're not exactly sure when that point is.
The no-code companies say they can handle a heavy load. You figure if you're successful enough to need to migrate, you'll have enough money to hire help and it won't be a big deal.
This is what I thought in 2015 with my Y Combinator-backed startup, Sixty. My cofounders and I built our MVP 100% on a no-code stack. We were growing revenue 50% monthly for almost a year. Then we suddenly realized we'd no-coded ourselves into a corner.
We'd no-coded ourselves into a corner
The app was so slow it felt broken. We couldn't build the features we needed to unlock more revenue. There weren't many no-coders we could hire for help. The ones available had a lot of experience in prototyping but not much in scaling.
To top it off, every push to production felt like we were taking a leap of faith, praying that the app wouldn't crash. Growth started flatlining.
We hired a CTO who rebuilt the app using Ruby on Rails. We migrated as fast as we could, trimming out a painful amount of design detail and features from the website and app. Our spreadsheet analytics had to also be rebuilt from scratch to query a Postgres database.
Engineering cut the no-code tools out of the stack
Understandably, our engineering team didn't want a repeat of this mess. But now when new features, bug patches, and updates needed to be made, the no-coders couldn’t take care of it. Instead they specced engineering tickets. This quickly overwhelmed the engineers.
Building features that used to take between hours and days in no-code, now took days to weeks in code, if they got prioritized at all. The no-coders always felt like they had their hands tied in improving the business. Tension grew between the two teams.
Growth slowly recovered over the next quarters. But not nearly at startup-pace. We wouldn't be successful at this rate.
We decided to bring no-code tools back in
We layered them on top of the code foundation. The key difference was that this was scalable. We knew where no-code's limitations lay now, so we planned around them.
Experimental features started in no-code. The primary database remained Postgres. The no-code and code infrastructure was securely and stably connected.
Tension dissipated and growth accelerated. Quickly we were back to our 50% monthly revenue growth rate.
Part 2: the no-code movement had been crystallized
In 2019, Makerpad launched and the term "no-code" started proliferating on Twitter. Before then, there wasn’t a word for stringing together SaaS tools to replicate a web app. It was just a way to build faster and cheaper.
Now everyone was talking about how you could “build Airbnb without code”. Sure, you could build something that looked like Airbnb, but I knew from years of first-hand experience that you couldn’t scale far. No-code tools can only support so many users. I'd never heard of anyone raising anything past a seed round on no-code tools.
Then I heard of another Y Combinator company that raised a $150 million Series B, had 120 employees, and was still almost purely on a no-code stack: Lambda School.
Serving over 1,500 students and alums primarily through Airtable and Zapier, Lambda probably had the record for scaling the furthest on a no-code stack. They got this far for two reasons:
- Their operations team building the no-code stack was world-class. Many of them were already very technical and had engineering backgrounds.
- No-code apps scalability is highly correlated to the number of paying users. Since tuition per student came out to between $17-30k, they were able to grow the company larger than, say Sixty, which made about $200/user, before having to migrate.
At this point, Lambda was ready to migrate the no-code stack to a code foundation. They needed to build more performant and customized software to support the next stages of the school's growth.
Lambda School hired me to help them migrate from no-code to code
I joined Lambda School’s engineering team in 2019 to help them migrate to code. I learned their history building the no-code stack in the years past. Even with ~25x more team members, there was a similar pattern to what I saw at Sixty. Notably:
- The no-code tools' performance issues emerged much earlier than expected.
- The migration was more challenging than expected.
- The engineering team's sentiment when I joined was to write all the new software in code and eliminate no-code tools.
To reach feature parity re-writing everything in code would be an enormous amount of work. It would take too long to accomplish.
The engineering team had already created a one-way sync of the production no-code databases to Postgres. So to accelerate the migration, I suggested we use a use a low-code internal tool builder called Retool that sits on top of Postgres. This would give us the development speed of no-code tools but with the scalability of code. The team liked the approach.
Launching the first Retool app marked the tipping point in the migration. It enabled us to delete the first, largest, and most problematic piece of the no-code stack. Over the following months, we repeated this process of building more Retool apps to speed up the migration, in parallel with the other engineering efforts.
After we were through the majority of the migration, I started watching the no-code movement again. Despite almost a year having passed, there was still no one talking about how to scale past an MVP on no-code tools. No one was talking about when it breaks down and how to migrate.
There was no playbook for no-code to code migrations
There wasn’t a single resource for what to do once no-code tools stopped scaling. No one was talking about migrations to code, or how to connect the tools together with a code stack.
I started speaking with other startups on no-code stacks. I wanted to see how building on them compared to Sixty's and Lambda's.
It turns out that that whether their whole tech stack consisted of no-code tools, or just the operations team, a similar pattern emerged. This made me realize that no-code to code migrations are a different animal.
They're not like normal tech debt, where engineers create the debt and have a plan to migrate and re-factor everything later. Operations teams are creating the no-code tools, and even in the cases where they are technical, the challenge of having product being built under two separate teams is novel.
In retrospect of each no-code to code migration, it's easy to see where improvements could have been made. But since there's presently no one telling their story, each startup has to figure it out on their own, without guidance.
Now with the exponentially growing number of startups using no-code tools, and investors funding them, a mass migration crisis is imminent. The most successful of the startups will have to migrate their no-code MVP to a new tech stack to achieve the next level of growth. I'm here to help them do it.
