Speed is a very important element of startup success. Most of the successful companies I know and worked at launched and iterated fast. The fastest company in any market will win. Building faster means you have extra time to talk to your customers, do sales or fundraise.
In this essay, I am going to share how you can be faster with your startup. First, some context about me. Building and launching products is my passion. 7 years ago I launched an educational course named Startup Summer, where students learn about product development and launch startups in 2 months.
I built a prototype in 7 days, and that product became a unicorn later. This year, I’ve launched a product in just 3 weeks. I’ve been launching products for 15 years and would like to share things I’ve learned.
Every startup is different, but there are common techniques I’ve been using for years. They will save time for you and your team.
Hack a prototype
This became my favorite approach over the years. The idea is to build the first version of your product quickly (1-10 days). The product is not meant to be used by the end users, but rather to help you better understand the overall effort and find any blockers. That raw, somewhat usable product helps to better prioritize development, skip or push back some features. Or, in other words, understand the risks and details quickly.
Hacking means doing something in an ugly way or something clever to beat the system. Try to ‘hack’ a prototype. Move fast, find simple ways to resolve or skip blockers. Here are a few tips:
- Do not build things you know. It makes no sense to focus on things you know how to build. They might be required to complete the product, but they should have the lowest priority when you’re building the raw version, because they do not have any risks and do not bring extra value. E.x. no need to focus on building a signup form or detailed onboarding — you can build later. You can just keep a single, hardcoded user.
- Focus on things you don’t know. The goal of the raw prototype is either to reduce risks or scope. Things you don’t know are the riskiest areas and can either delay the product release or block it completely. Start by getting the most complex parts done and later connect them into the raw version of your product, into the key user workflow.
- Do not build complex algorithms. You don’t know where you’ll end up with your product idea, so in most cases it does not make sense to invest lots of time into building complex algorithms. Instead, just start from a simple version or in other words “Fake it till you make it”.
- Find out details. The main goal of hacking together the prototype is to get a full understanding of how your product will work and look.
If you follow the guide, you’ll:
- Have your raw product you can show to friends & family in a matter of days or weeks
- You’ll discover lots of missing parts and prioritize them accordingly
- You’ll likely simplify the first version of your product
- You’ll reduce the risk of not releasing the product quickly enough or being blocked completely.
I remember back in 2013 I hacked a UI prototype of the full product in just 7 days. That was not perfect, but that was a great way to start the conversation with our end users and gradually improve the product.
Learn no-code
The no-code/low-code solutions are certainly taking a lot of my attention this year. They can not only help you launch your product without developing your team, but also accelerate your product development in general.
I recently found Plasmic and their idea looks very promising, especially for the founders. Founders or anyone who don’t know how to code, but want to build something can use Plasmic to build all pages and later export the code and give it to developers.
Take a look into Webflow, Airtable, Softr, Supabase, Plasmic. We managed to cut the first launch time by ~30% by using combinations of them. Read How to launch an MVP in the no-code era.
Build less
Aside from using no-code tools, you may also spend more time with the scope and find things you can skip and not write code for. The less code you write, the less you need to maintain and the less complex your end product will be, allowing you to move fast for an extended period of time.
If you try to build too much, your product will get complex much quicker and complexity can kill your startup. It will exponentially reduce your ability to deliver value and build new features. So building fewer things is very important. Below are some tips on how to do it.
Use the 90/10 solution
A piece of advice by Paul Buchheit, creator of Gmail, is to look for the “90/10 solution”. Always look to accomplish 90% of what you want only with 10% of work/effort/time. Try hard to find that solution. Work closely with your engineering team and tell them about this rule — the solution is there.
The two most common use cases where this rule applies are:
- Pricing: Instead of building a custom pricing solution, you can just use Stripe components.
- Registration: There are many tools (e.x. Firebase, Supabase) and starters which come with all you need.
Reduce scope
If you’re at an early stage of your startup, reducing the scope and finding a few essential features is key. You should evaluate every feature you add to the backlog and find a way to reduce the scope and complexity of that feature. Keep things as simple as you can.
Use the experience of your engineer, design and product team members to reduce the scope and find solutions that are smarter and simpler.
Use prebuilt assets
Prebuilt assets can help you move faster. Usually, every startup has one unique feature and lots of common features from pricing to onboarding. Finding the right tool to solve your problems along the way can help you move much faster and save weeks or even months.
I can not imagine building subscriptions without Stripe’s hosted subscription page. Pricing is important, but usually not a key feature. The rule of thumb is to always evaluate existing solutions, before investing into building your own.
Not every product requires custom design and not every startup can afford to hire a designer. You can save a lot of time and money by using design/UI templates (e.x. themeforest). We adopted and use a customized version of the Mantine UI framework. That enables engineers to experiment and propose their ideas faster, owners to draw raw mockups and give them to the team.
For sure, there are some products that do require design, but still consider this as an option. You can use Looka to create your own logo very cheaply.
We used Ship to create over 20 products faster. Ship is an opinionated framework, which comes with a lot of pre-built components, such as registration, onboarding, pricing and many more.
Written by Andrew Orsich. Thanks to Anton Shardyko, Stanislau Tarazevich, Vitaliy Bychik and John McTavish for reading drafts of this.