
Planning for the switch from no-code to code
My name is David Head. I’ve been building no-code products and features since 2014. I led my team to get funding from Y Combinator for the summer 2017 batch with a product that went through two no-code iterations before transitioning to a Ruby on Rails stack.

Principles
A core principle I’ve found in every no-code project is the more traction you get, the more beneficial it becomes to move to code. You’ll notice three things start happening, which we’ll call no-code limitations:
No-code limitations
- Feature limitations: you’re limited in how much you can customize features to your specific use case
- Community limitations: you’ll want to hire someone to maintain the product/feature and build more code
- Infrastructure limitations: there is a lower limit to how many people can be using the product at once
The more traction you have, the riskier your situation will be. You have to plan a smooth and swift transition from your current stack to your next stack. Your next stack may be another no-code stack, but eventually if you continue to be successful, it will usually turn into a code stack like Ruby on Rails. We’ll call these stack transition steps.
Stack transition steps
- Predict breakdown: always be thinking of when and where your current stack will break down
- Build new stack: start building new stack to transition to when your current stack breaks down
- Transition to new stack: migrate all of your data and users to the new stack
Finally, unless your coding skills are that of a senior developer, plan to hire someone to lead development of the codebase when it gets to that stage. Someone who can handle all technical decisions, rather than a junior developer working under you.
My backstory
In 2015, I owned a web design agency that built a lot of Squarespace websites. We were partnered with Jake Jorgovan, who created a popular course on how to build a Squarespace website. Jake’s course generated dozens of people reaching out to ask things like, “Will you help me polish my website’s design for launch?” Jake would refer these leads to us.
Most web designers didn’t want these small-scope leads since all the back-and-forth made them expensive. But we discovered that working with the client via video conference allowed us to bill 50% more than our standard rate (so, $150/hr) and launch their site in about 2 hours. Which made it worth it for most professional designers.
Thinking about all of the other web tools marketed as do-it-yourself, we figured there was a larger market for on-demand help like this far beyond web design. So I reached out to a colleague, who also owned a web agency, to be my cofounder on this side project.
Squarespace stack: proving the concept
My new cofounder handled the sales and recruited web designers to offer their services. I focused on hacking together an infrastructure to scale the service. My goal was to bring on another team member to lead the tech once we proved the concept and went full time.
Since we had an abundance of leads, our first bottleneck was having an infrastructure to facilitate web designers doing on-demand sessions via video conference. I solved this with the following stack:
- Acuity Scheduling embed
- Zapier to send the transaction data from Acuity to a Google Sheet
- Zoom API plan to set up the video conference
- Mandrill to send transactional email and video link
- Squarespace website

Once we had this stack built, and tested out with a few clients, my cofounder started recruiting designers to join.
When building the platform and predicting when it would break down (step 1 of stack transition steps), I knew Squarespace and Acuity were the first bottlenecks.
- Acuity had a team account but no API plan like Zoom. All of the designers would login and sync their calendar like they were a team member. This was a dealbreaker for scaling.
- We had to make each web designer a unique page in Squarespace because there was no CMS. So updating the template of a designer’s profile meant updating each page individually. This also wouldn’t scale far either.
Other breakdowns included:
- We were unable to add basic web app features one would expect, like user login
- Client users had to enter their credit cards every time they scheduled a session. There would be no record of past transactions they could see in a UI, which was also an opportunity to prompt follow-up sessions
- Designers had to put in requests changes for profiles and we had to change it manually
We scaled on this stack for 5 months at 50% growth per month. Our primary metric was hours of sessions per month.

Going back to the no-code limitations concept, our primary issue was #1, feature limitations. At the stack transition steps, we predicted things would get problematic around May and we’d need to change stacks.
Bubble stack: building a web app
To keep increasing revenue, we needed to make it easier for clients to buy, and increase the number of designers on the platform so there was more time availability. Our vision was to eventually make it possible for clients to hire a designer within 60 seconds.
Our next step was to rebuild most of our stack. We thought we’d need to hire a developer, but there was a new “codeless web app builder” platform called Bubble that seemed promising. It seemed to be able to do everything a traditional web app could, but way faster. We decided to give it a try. Next steps:
- Replace Squarespace with Bubble so we could build a client dashboard and manage dozens of designer profiles
- Seed Bubble’s database with our Google Sheets data
- Rewire Zapier to still post data into Google Sheets to use for analytics
Since we were growing revenue at this point, it made sense for one of the junior front end developers at my web agency to learn Bubble so I could focus on other growth tasks. It took him one month to learn Bubble, rebuild our platform, and take us live.
We now had a signup flow, a client dashboard, and had integrated Stripe Connect to store client credit cards. Next, we needed a feature allowing each designer to sync their calendars via OAuth. We assumed that since we were good with APIs, we could make anything happen in Bubble that could happen in a codebase. Of the few tools that seemed promising for this, we planned to use Timekit since it seemed the most polished.
This ended up being a massive learning opportunity for us. When it was time to implement Timekit, we realized there were “callbacks” that had to be programmed for the OAuth to work — they were impossible to hack into Bubble. We now had a new feature limitation on a critical feature. We decided to scale around it as long as possible.
Next up was enhancing the client dashboard so they could view past sessions — an extremely basic functionality to program into a web app. When we programmed it in Bubble, there was about a two delay until the historical session data would show up on the screen. While it technically worked, the UX felt janky. We spent a dozen or so hours working with the best Bubble freelancers to optimize this workflow, but there wasn’t much of a difference. This was an infrastructure limitation that turned out to be a UX issue.
While we worked through all of these issues, each new one became increasingly more challenging. While our developer picked up Bubble and rebuilt the platform blazingly fast, there hit a point where all of us were overwhelmed and looking for a more senior developer to take the lead.
Note: You’ll live or die by the fundamentals
Being able to stick apps together to do things is easy. Knowing the fundamentals of web app architecture is where you’ll get killed. This is because you’re creating technical debt. Not just in the sense that you’re not in a codebase, but because you will do things like improperly model your database.
This is what happened to us. It was easy to spin up the database and associations in Bubble, but because it wasn’t done in a fundamentally sound way, the database queries took longer and we would have to change the schema and do database migrations when adding new features.
This is the same with Webflow and Squarespace users who were reaching out to us for help: they could put something together that technically was a live website, but they weren’t proud enough of it to make it public. Their problem was they didn’t know web design fundamentals.
We searched for a senior Bubble developer. There were only about 10 to choose from on the forums (this was pre Bubble-developer directory). While working with them, we learned that our junior developer who just learned Bubble two months previous was at roughly the same skill level.
Everyone had a similar background to us: they wanted to quickly hack something together and didn’t know how to code. No one had experience building scalable web apps and definitely not a Computer Science degree.
The average rate for a Bubble developer was about $150 an hour, too. Compare that to the average Rails developer, who is $80–100/hr, has a few years of app development experience, and often a CS degree. The initial efficiency gains of a quickly built app were over. Now we would be paying exponentially more in talent to scale.
We tried to find the most successful consumer Bubble app. We thought we could follow in their footsteps and scale to as least as large as they were. Unfortunately, we were the most successful of anyone we found. While you may think this was good for our egos, it was actually terrifying — we realized we couldn’t scale on Bubble as far as we thought. Now we're experiencing an extreme form of community limitations.
Despite the challenges of dealing with these no-code limitations, we still scaled on Bubble 50% per month for another three months. To recap:
- Feature limitations: mainly building scheduling features and Google OAuth
- Infrastructure limitations: mainly with database queries taking too long
- Community limitations: limited experience with scalable web app development, small community, few professionals to freelance, essentially none who were candidates for full time, high prices for those who did freelance.

Moving to a codebase
Since Bubble was and still is the pinnacle of a no-code platform, and we were maxed out, now our only option was a code-based platform. At first we thought we could just hire someone to rebuild the platform in code. We tried that and realized we needed a “technical co-founder” instead of an employee: someone who could act as our CTO, going all in for the next few years while we built the company.
We spent the next 3 months hiring freelancers, posting jobs for a cofounder position, and networking around Nashville before finding the right person.[4] He said one of the biggest reasons he wanted to join the company was the traction we’d already demonstrated.
Over the next 2 and a half months, our new CTO rebuilt the app in Rails and we were ready to make the switch. This was the core scope of the transfer:
- Data import: CTO instructed how he needed the data setup for import. I spent a day or so organizing that in spreadsheets.
- 301 redirects: Routes needed to change, so I crawled our website with Screaming Frog to get a list of the URLs and created a spreadsheet mapping them over. Here’s a template.
- 3rd party tool connections: I reconfigured Zapier workflows to be triggered by a webhook. Our CTO programmed our app to send JSON data to Zapier at the appropriate workflow step in Rails.
- User email: Each of our users needed to do a password reset process to capture their account. My cofounder drafted an email to users that we planned to send at launch.
From here, our product was no longer bound by any of the no-code limitations. With our new team and code platform ready, we applied to YC that spring and secured funding for the summer 2017 batch.
Reflection and Takeaways
Our tactic of hacking things together with the Zapier/Squarespace/Acuity stack was a great choice and proved our concept. We may have been better off moving straight to hiring a technical cofounder rather than rebuilding in Bubble. I think we were overly optimistic about no -ode’s potential as the core platform.
That said, we still believe in and employ no-code prolifically. We’ve built thousands of web pages using Webflow’s CMS and a reverse proxy setup on top of our Rails app. One was the prototype for the Showcase product. It grew organic Google traffic 30% a week for 4 months until we moved it to Rails after it hit infrastructure and feature limitations.
For some pages we’ve built like the Sixty blog and our Insights product, they may never move off Webflow.
If Sixty started over, I would actually have Webflow power all our marketing pages. Bonsai and Alto are doing this and I’m also seeing many other Y Combinator startups build this way. It’s a powerful setup — the marketing team can make changes to the site without burdening the engineering team.
Hopefully this helps you better tackle your no-code challenges. If you still have questions about which stack to use and how far it will scale, feel free to reach out to me on Twitter. I’ll also be sharing more content from the no -ode projects I mentioned on there as well.
Principles
A core principle I’ve found in every no-code project is the more traction you get, the more beneficial it becomes to move to code. You’ll notice three things start happening, which we’ll call no-code limitations:
No-code limitations
- Feature limitations: you’re limited in how much you can customize features to your specific use case
- Community limitations: you’ll want to hire someone to maintain the product/feature and build more code
- Infrastructure limitations: there is a lower limit to how many people can be using the product at once
The more traction you have, the riskier your situation will be. You have to plan a smooth and swift transition from your current stack to your next stack. Your next stack may be another no-code stack, but eventually if you continue to be successful, it will usually turn into a code stack like Ruby on Rails. We’ll call these stack transition steps.
Stack transition steps
- Predict breakdown: always be thinking of when and where your current stack will break down
- Build new stack: start building new stack to transition to when your current stack breaks down
- Transition to new stack: migrate all of your data and users to the new stack
Finally, unless your coding skills are that of a senior developer, plan to hire someone to lead development of the codebase when it gets to that stage. Someone who can handle all technical decisions, rather than a junior developer working under you.
My backstory
In 2015, I owned a web design agency that built a lot of Squarespace websites. We were partnered with Jake Jorgovan, who created a popular course on how to build a Squarespace website. Jake’s course generated dozens of people reaching out to ask things like, “Will you help me polish my website’s design for launch?” Jake would refer these leads to us.
Most web designers didn’t want these small-scope leads since all the back-and-forth made them expensive. But we discovered that working with the client via video conference allowed us to bill 50% more than our standard rate (so, $150/hr) and launch their site in about 2 hours. Which made it worth it for most professional designers.
Thinking about all of the other web tools marketed as do-it-yourself, we figured there was a larger market for on-demand help like this far beyond web design. So I reached out to a colleague, who also owned a web agency, to be my cofounder on this side project.
Squarespace stack: proving the concept
My new cofounder handled the sales and recruited web designers to offer their services. I focused on hacking together an infrastructure to scale the service. My goal was to bring on another team member to lead the tech once we proved the concept and went full time.
Since we had an abundance of leads, our first bottleneck was having an infrastructure to facilitate web designers doing on-demand sessions via video conference. I solved this with the following stack:
- Acuity Scheduling embed
- Zapier to send the transaction data from Acuity to a Google Sheet
- Zoom API plan to set up the video conference
- Mandrill to send transactional email and video link
- Squarespace website

Once we had this stack built, and tested out with a few clients, my cofounder started recruiting designers to join.
When building the platform and predicting when it would break down (step 1 of stack transition steps), I knew Squarespace and Acuity were the first bottlenecks.
- Acuity had a team account but no API plan like Zoom. All of the designers would login and sync their calendar like they were a team member. This was a dealbreaker for scaling.
- We had to make each web designer a unique page in Squarespace because there was no CMS. So updating the template of a designer’s profile meant updating each page individually. This also wouldn’t scale far either.
Other breakdowns included:
- We were unable to add basic web app features one would expect, like user login
- Client users had to enter their credit cards every time they scheduled a session. There would be no record of past transactions they could see in a UI, which was also an opportunity to prompt follow-up sessions
- Designers had to put in requests changes for profiles and we had to change it manually
We scaled on this stack for 5 months at 50% growth per month. Our primary metric was hours of sessions per month.

Going back to the no-code limitations concept, our primary issue was #1, feature limitations. At the stack transition steps, we predicted things would get problematic around May and we’d need to change stacks.
Bubble stack: building a web app
To keep increasing revenue, we needed to make it easier for clients to buy, and increase the number of designers on the platform so there was more time availability. Our vision was to eventually make it possible for clients to hire a designer within 60 seconds.
Our next step was to rebuild most of our stack. We thought we’d need to hire a developer, but there was a new “codeless web app builder” platform called Bubble that seemed promising. It seemed to be able to do everything a traditional web app could, but way faster. We decided to give it a try. Next steps:
- Replace Squarespace with Bubble so we could build a client dashboard and manage dozens of designer profiles
- Seed Bubble’s database with our Google Sheets data
- Rewire Zapier to still post data into Google Sheets to use for analytics
Since we were growing revenue at this point, it made sense for one of the junior front end developers at my web agency to learn Bubble so I could focus on other growth tasks. It took him one month to learn Bubble, rebuild our platform, and take us live.
We now had a signup flow, a client dashboard, and had integrated Stripe Connect to store client credit cards. Next, we needed a feature allowing each designer to sync their calendars via OAuth. We assumed that since we were good with APIs, we could make anything happen in Bubble that could happen in a codebase. Of the few tools that seemed promising for this, we planned to use Timekit since it seemed the most polished.
This ended up being a massive learning opportunity for us. When it was time to implement Timekit, we realized there were “callbacks” that had to be programmed for the OAuth to work — they were impossible to hack into Bubble. We now had a new feature limitation on a critical feature. We decided to scale around it as long as possible.
Next up was enhancing the client dashboard so they could view past sessions — an extremely basic functionality to program into a web app. When we programmed it in Bubble, there was about a two delay until the historical session data would show up on the screen. While it technically worked, the UX felt janky. We spent a dozen or so hours working with the best Bubble freelancers to optimize this workflow, but there wasn’t much of a difference. This was an infrastructure limitation that turned out to be a UX issue.
While we worked through all of these issues, each new one became increasingly more challenging. While our developer picked up Bubble and rebuilt the platform blazingly fast, there hit a point where all of us were overwhelmed and looking for a more senior developer to take the lead.
Note: You’ll live or die by the fundamentals
Being able to stick apps together to do things is easy. Knowing the fundamentals of web app architecture is where you’ll get killed. This is because you’re creating technical debt. Not just in the sense that you’re not in a codebase, but because you will do things like improperly model your database.
This is what happened to us. It was easy to spin up the database and associations in Bubble, but because it wasn’t done in a fundamentally sound way, the database queries took longer and we would have to change the schema and do database migrations when adding new features.
This is the same with Webflow and Squarespace users who were reaching out to us for help: they could put something together that technically was a live website, but they weren’t proud enough of it to make it public. Their problem was they didn’t know web design fundamentals.
We searched for a senior Bubble developer. There were only about 10 to choose from on the forums (this was pre Bubble-developer directory). While working with them, we learned that our junior developer who just learned Bubble two months previous was at roughly the same skill level.
Everyone had a similar background to us: they wanted to quickly hack something together and didn’t know how to code. No one had experience building scalable web apps and definitely not a Computer Science degree.
The average rate for a Bubble developer was about $150 an hour, too. Compare that to the average Rails developer, who is $80–100/hr, has a few years of app development experience, and often a CS degree. The initial efficiency gains of a quickly built app were over. Now we would be paying exponentially more in talent to scale.
We tried to find the most successful consumer Bubble app. We thought we could follow in their footsteps and scale to as least as large as they were. Unfortunately, we were the most successful of anyone we found. While you may think this was good for our egos, it was actually terrifying — we realized we couldn’t scale on Bubble as far as we thought. Now we're experiencing an extreme form of community limitations.
Despite the challenges of dealing with these no-code limitations, we still scaled on Bubble 50% per month for another three months. To recap:
- Feature limitations: mainly building scheduling features and Google OAuth
- Infrastructure limitations: mainly with database queries taking too long
- Community limitations: limited experience with scalable web app development, small community, few professionals to freelance, essentially none who were candidates for full time, high prices for those who did freelance.

Moving to a codebase
Since Bubble was and still is the pinnacle of a no-code platform, and we were maxed out, now our only option was a code-based platform. At first we thought we could just hire someone to rebuild the platform in code. We tried that and realized we needed a “technical co-founder” instead of an employee: someone who could act as our CTO, going all in for the next few years while we built the company.
We spent the next 3 months hiring freelancers, posting jobs for a cofounder position, and networking around Nashville before finding the right person.[4] He said one of the biggest reasons he wanted to join the company was the traction we’d already demonstrated.
Over the next 2 and a half months, our new CTO rebuilt the app in Rails and we were ready to make the switch. This was the core scope of the transfer:
- Data import: CTO instructed how he needed the data setup for import. I spent a day or so organizing that in spreadsheets.
- 301 redirects: Routes needed to change, so I crawled our website with Screaming Frog to get a list of the URLs and created a spreadsheet mapping them over. Here’s a template.
- 3rd party tool connections: I reconfigured Zapier workflows to be triggered by a webhook. Our CTO programmed our app to send JSON data to Zapier at the appropriate workflow step in Rails.
- User email: Each of our users needed to do a password reset process to capture their account. My cofounder drafted an email to users that we planned to send at launch.
From here, our product was no longer bound by any of the no-code limitations. With our new team and code platform ready, we applied to YC that spring and secured funding for the summer 2017 batch.
Reflection and Takeaways
Our tactic of hacking things together with the Zapier/Squarespace/Acuity stack was a great choice and proved our concept. We may have been better off moving straight to hiring a technical cofounder rather than rebuilding in Bubble. I think we were overly optimistic about no -ode’s potential as the core platform.
That said, we still believe in and employ no-code prolifically. We’ve built thousands of web pages using Webflow’s CMS and a reverse proxy setup on top of our Rails app. One was the prototype for the Showcase product. It grew organic Google traffic 30% a week for 4 months until we moved it to Rails after it hit infrastructure and feature limitations.
For some pages we’ve built like the Sixty blog and our Insights product, they may never move off Webflow.
If Sixty started over, I would actually have Webflow power all our marketing pages. Bonsai and Alto are doing this and I’m also seeing many other Y Combinator startups build this way. It’s a powerful setup — the marketing team can make changes to the site without burdening the engineering team.
Hopefully this helps you better tackle your no-code challenges. If you still have questions about which stack to use and how far it will scale, feel free to reach out to me on Twitter. I’ll also be sharing more content from the no -ode projects I mentioned on there as well.
Free until you’re ready to launch
Build your site for free and take as long as you need. Just add a site plan for more pages, and a custom domain when you’re ready for the world.