No-code — how to go live in 10 days
--
No-code has become a buzzword, especially in venture building. But it is no different than anywhere else — talking is easy, execution is tough. Resulting in people thinking no-code is overpromising and under-delivering. So you can’t blame them if they reduce it to the use of hobby apps only. But they couldn’t be more wrong. No-code is particularly helpful in venture building, where it can easily and rapidly bridge the gap between idea and product.
At Sparrow Ventures, we have long been proponents of no-code solutions and use them daily. The primary reason for this is that working in no-code helps us to validate hypotheses up to 10 times faster than working purely with code. Wait, 10 times faster?! It’s all about execution. And this blog shows you how it’s done.
A few years back, we started simple. Our first no-code solutions were setups such as landing pages with Calendly links. But already back then we saw the full potential of no-code. Here is the proof. Today in most cases we still start with a simple landing page to validate the initial value proposition. But moving towards the MVP (minimum viable product) we have grown far beyond simple no-code solutions, building sophisticated products within days.
One of our current ventures heavily relying on no-code is YUNO. Yuno is a Swiss company that lets customers rent technology products instead of buying them, including cameras, wearables, smartphones, computers, tablets, and home entertainment systems.
Don’t build to scale — build to validate
Before you start building your no-code solution you need to know one key principle: Build to validate, not to scale. Meaning, that at the early stage of a startup it is more important to validate the riskiest hypothesis as fast as possible rather than to build a scalable tech stack. The riskiest hypothesis is different for each venture, but often it comes down to one of the following questions: Do people want this? Can I execute/operate this? Can I get customers? To validate those questions sometimes you don’t even need to use no-code, a simple phone call to possible customers could be enough.
What most get wrong about no-code
Most startups fail. So figuring out early on if your business has potential outweighs building a scalable tech stack early on by far. This is one of the big thinking errors people make when it comes to applying no-code. But in this lies the whole magic of no-code. It gives you speed and flexibility. You’re up to 10x faster in validating your hypothesis, allowing you to make a better decision early on. And in many cases perish the venture early on. Which gives you more time to pivot or free up time to work on the next idea.
This sounds all good, but what if the validation is successful and you are stuck with a non-scalable no-code tech stack? You rebuild it from scratch. Yes, you were reading right. You rebuild it. But this time you build a better version, including all your learnings from the first version allowing you to test your next critical hypothesis. You keep doing this till you have product-market fit. And only now you can start thinking about building a scalable version. But is it faster to rebuild the product 2–3 times? Yes, it is. Why? Because no one gets it right the first time. You add functionalities you wouldn’t have thought of or you pivot into a new business model which requires a completely different product. And don’t get me wrong, I am not saying you shouldn’t be thinking about scalability. You have to. But don’t build it yet.
Here is how to execute no-code
Enough theory, lets get back to Yuno to give you an idea about our approach of applying no-code in our venture building process. First, it was all about figuring out if people want to rent tech products instead of buying them. We started with conducting interviews, we looked at market signals, but at a point, with enough validation, you need to figure out if people would rent the products in an online store. So we created an online store offering up to 80 tech products for renting. Like this, we could test if the demand was there. Traditionally building this store would have taken several weeks or even months. But with no-code, we built it in four days. Besides learning a lot about customer demand, we also gathered insights about how to get customers and which products they are most interested in.
After three weeks we had enough data gathered, giving us enough confidence to decide that we wanted to proceed with the venture and build an MVP. Here comes the key. For the MVP we reevaluated the whole tech stack and built everything from scratch: an online store with checkout, including user accounts and verification for ID and phone number for fraud protection. The operations like shipping the products were (and are still) done manually. This time it took us 10 days to build it. And we even overbuilt for the first MVP. Without no-code, we would still be building our prototype. Now we are already gathering valuable data with a fully working product.
What is the lesson learned from this? Keep in mind that it is not necessary to select one tech stack for the whole startup journey — what is important is finding the right tech stack for the right stage to validate your hypotheses as fast as possible.
For Yuno we found Problem/Solution Fit and Product/Market Fit by using different tech stacks. Next, it will be all about scalability. And here again: We continuously reevaluate the whole tech stack. Now we likely go towards custom code for certain parts. But at this point, we have a higher certainty that the business will be successful. Therefore we can invest to build a solution covering all our needs and one that is scalable to cater hundreds of thousands customers.
How to select a no-code tech stack?
The approach towards no-code in venture building should be clear by now. But how do you select the tools or tech stack? In the beginning, you define and prioritize needed functionalities to test your assumptions (for example by doing a user story mapping). From there you can start thinking about tools. And ask yourself among others the following questions:
What is really creating value for the customer?
Is it the tech stack (for example, if you build a social network or an online marketplace) or is the tech just supporting the value creation (for example an online school)? In the case of the online school, the true value is created through the teacher and not through the sign-up journey. In this case, you can use a rather standardized tool and customization is not so important. In the other case where the tech stack is creating the main value, you rather aim early on for a more sophisticated no-code tool allowing for a lot of customization, maybe including the option to add custom code.
What are the competitors doing?
For this I use Wappalyzer. It is a service telling you which tech stack other websites are using. It is a great source of inspiration.
Do I already know a tool capable of providing these functionalities?
Always start with the tools you know. There you already know potential limitations and you are way faster in building and testing the core functionality. Rather take a tool you know than search for the perfect tool. Given that it allows you to test your hypotheses.
Are there regulatory requirements?
If you process data (which you will do) you need to be aware of the regulatory requirements (for example GDPR), especially when your target market is in Europe. Most no-code tools process their data through servers based in the US. This is not by default an issue, but you need to be especially careful when you build something for the health or fintech industry where data can be highly-sensitive. Therefore, before you start building with a tool, check if it complies with the regulatory requirements in your country. Many no-code tool providers offer support pages for those questions. If not, reach out to them.
How we built the Yuno MVP
Having the answers to those questions in mind you can start looking for your tech setup. Here is how we approached it for building the MVP at Yuno. Our first tool choice was Shopify since we knew the tool very well. But still, we were not sure about implementing the ID and phone number verification as well as the subscription payment handling. So we immediately tested those two critical parts without designing anything. After half a day of testing, we knew it would not be easy to implement the verification and checkout flow as we wanted it. Shopify was discarded and we started looking for another setup.
Okay, but how do you find tools which could be a good fit? It is simple, you google. So did we. And just a few hours later we had a new possible setup, a combination of several tools (Webflow, Memberstack, Monto, Stripe, Make, etc.). Here again, we immediately tested the key functionalities, verification, and subscription payment. This time the test was successful and we had enough confidence to start building our MVP.
Limitations exist — leverage them
Let’s be honest, no-code is not yet nearly as customizable as custom code. Each tool has its limitations but this is wonderful. Why? It helps you stay focused. You select a tech stack that helps you test your key hypotheses and not more. You don’t get distracted by building unnecessary functionalities. A mistake you most likely experienced if you ever built something. I at least did — several times. Therefore, be careful with the ‘you can build everything’ no-code tools for example bubble.io. Sorry guys from Bubble, I love your tool and it is powerful, but it is so easy to get distracted in overbuilding. Believe me, I did it.
Know the risks of no-code
Building with no-code has risks and you have to know them. One big risk you almost always have is tool/platform dependency. Meaning, what if the tool has a bug? Or worse what if the tool provider is going out of business? There are several ways to mitigate the risks for example by checking the support pages and figuring out how fast the response to bugs is. I personally always test the support response time before I decide to use a tool.
Tip: To figure out if a ‘never used before’ no-code tool is mature enough, to not become the bottleneck, read the release notes. If they announce very basic functionalities and bug fixes of key functions. You immediately know this tool needs a few more years.
Nevertheless, I am always thinking about the most critical and the weakest part of our no-code setup and have a plan B in mind. This can either be another no-code tool or custom code. If custom code is the plan B, I have a rough estimation in mind of how long it will take to replace it.
Another risk that also goes into platform dependency is to check if you can export your customer data and take them to another tool. This especially gets more important the closer you get to scalability. If a tool does not allow you to export the data, don’t use it.
One last remark: no-code vs. code
Often people ask me: shall we use code or no-code. Please excuse me, I don’t want to be rude. But if you ask that question, you don’t get the basics about venture building. It is not about technology, it is about validating your key hypothesis as fast as possible. And that is what we do at Sparrow Ventures. Day by day. With no-code and code.
