Startups are essentially machines that build MVPs (minimum viable products) that help answer questions and gradually de-risk the company's value proposition.
The key is that every MVP a company creates needs to be laser-focused on answering a very particular question. If you do anything more than that, it's wasted time and effort. In my experience, many startups worry about scaling too soon, wasting resources on something that may never be needed.
This trend is particularly evident in start-ups founded by people coming from engineering disciplines at large and scaled companies. But the things you need to do to submit code on Facebook, Netflix, Amazon, or Google don't apply the same way to early-stage startups.
Early-stage startups may have a few hundred or thousands of customers, and each customer list has its own unique set of challenges.
Do not misunderstand; It's always best to make sure your code is relatively secure and written in a way that doesn't degrade the customer experience. But technical founders often get it wrong and spend a lot of time hardening the code (ie making it secure) as well as writing and implementing it in such a way that it's scalable.
But that doesn't quite work when you're in proof of concept mode.
Inexperienced founders often get defensive about this kind of thing, worrying too much about whether the product or feature they just created will deliver a seamless user experience or worrying about whether it can handle a million concurrent users. Yes, those things are important, but they may not be right at this exact moment.
The mindset in early stage startups should be that you are creating MVPs to answer questions. Keep in mind that MVP is still a terrible term; it is neither a product nor viable. It is also not so “minimal” in many cases. An MVP is the least amount of work you can do to confirm or reject a hypothesis for your startup.
If the hypothesis is, "Can a million customers use this app at the same time?" Of course, that's the right time to optimize it to within an inch of its lifespan. But, when you're building a business in the early days, that's rarely the question, and unless you're in particular categories of apps that need to be resilient to notable amounts of traffic, investors are unlikely to care.
At one of the start-ups I helped with, the company had a product where they put tens of thousands of people in a waiting room, and when a countdown timer expired, everyone could walk into the product. That turned out to be an interesting challenge: What happens when 10,000 people access the exact same part of a web application within a second of each other?
As you can imagine, even small inefficiencies in the platform caused major bottlenecks and potential service degradation. In the short term, it "solved" the problem by turning on a bunch of additional servers and then letting people in within minutes; having 500 people hitting the slightly inefficient code at once was much less of a problem than having 10,000 people all logging in at once.
Elegant? No. Did it work? Yes, and it made sense because, at the time, the company was not explicitly concerned with whether the service could serve 100.000 customers at the same time. Alert: it couldn't, and at the time necessary, that part of the code had been refactored in a way that ensured it could.
In the early stages, the questions tend to be: "Is what we are trying to do possible?" or "Will people pay for this?" or "Can we convince a corporate partner to integrate this?" or "Can we acquire customers at a reasonable cost?" or "Can we make this at a price that makes sense?" or “How does the unit economics of this product work out as we scale?”
For a pre-seed business, you don't need perfect design and scalability; you need to create enough product and traction to get user feedback. From there, you can iterate and create value for customers. Once you start to deliver enough value that customers are willing to pay for, you can start to consider investing more in scalability.
Over-engineering a product too soon is neither important nor smart. It's a counterindicator: it tells investors that you don't know what's important at the current stage of your startup.
When attention is focused, the litmus test runs: Is your current activity contributing to collateral to help you with your next round of fundraising? If not, you're probably working on something that seems super important, but isn't appropriate for the scenario.
This is a problem - you could always spend more time building something fancier, faster, prettier or more scalable - but the mantra at startup should be "good enough is good enough". It's amazing how quickly you can go once the company internalizes it.
