A few months ago, I wrote about how various low-code tools such as Bubble and Webflow can supercharge your startup’s MVP/MAP. More specifically, I wrote about how Platform leverages these tools to streamline our product development timeline for our early stage founders.
Regardless of our process, there almost always needs to be a conversation with a founder regarding their hesitation using these tools. That conversation always goes one of three ways:
- Will it scale?
- Will it scale?
- Will it scale?
Candidly, a founder’s expectation for their intended traffic is almost always a tad lofty but, as an optimist, my answer is always the same:
If you build it well, it will scale.
The above sentiment applies to any early stage development process, especially if you choose to hire a team of full-stack engineers for your MAP. If the structure of your database is too cluttered or your app’s workflows are over-engineered, your product will not perform well at scale, and will certainly not be as performant as it could be early on. The same principles apply for low-code tools. If you choose to use Bubble’s built-in database, it is extremely powerful. But if you don’t spend the time to engineer it properly, it will fail you just as any other backend would.
To quote founder-in-residence, Derek Snook: “The devil really is in the details”.
These details will make or break any early-stage startup, and they are not as expensive as you might think. Investing the mental capital early on to define the secret sauce for your MAP will save you literal capital down the line.
You may be rolling your eyes right now. Does this sounds obvious? That’s because it should be obvious, and often is. What may not be obvious is the advantage low-code tools have at this stage in the development process. While it is essential to properly engineer your early stage product, there is no competing with low-code tools when it comes to speed and cost of build.
Thus, if you need a live product in the hands of your potential customers in a week, you can do it. But more importantly, you can do it imperfectly without compromising time or money. If you need to improve your product, you can build it again while your customers are testing your imperfect one or iterate on the live product while your customers are using it.
Low-code allows you to make mistakes and intentionally cut corners. That’s a helpful advantage, but this article isn’t about the scrappiness of low code tools; it is about the scalability of them.
User-testing on a live product is a luxury, and one that low-code tools easily provide. But what people often doubt is the ability to build your final product within the same ecosystem. Scaling a product means something different for every startup, but is almost always summed up as one big milestone.
The crazy thing is, these tools don’t require you to relinquish control and hope that they don’t crumble under the weight of your amazing startup. They give you the ability to build the easy stuff faster so you can save time and money to invest in the hard stuff. They encourage you to implement more robust third-party tools in order to strengthen your foundation.
These things don’t hurt your performance, they improve it. If you decide you need to scale, you can invest more in these platforms in order to increase the capacity of your product. If you eventually decide you need to migrate away from a low-code platform, that process is easier than you think. But until that moment, you can build on a budget.
One of my goals at Platform is to educate our founders about the amazing capabilities of low-code, while simultaneously pushing these tools to their absolute limit. The tools that we use help empower non-technical founders and save them time to focus on solving the right problems. As I mentioned in my previous article, these tools are only getting better. There is no better time than the present to experiment with new developer tools.
Low-code tools are transforming the perception of early-stage product development, and encouraging both founders and developers to ask more questions about what is possible.
What hesitations or questions do you, the reader, have regarding the scalability of low-code tools? When you encounter blockers or other limitations during the development process, how do you handle it? Our process is constantly improving due to conversations like this.