Common overengineering mistakes that kill startups before they even launch
Posted on 2025-02-25 by Simon Moisselin
So you have a brilliant idea and want to build an MVP? Here's a comprehensive guide on how to ensure you ship the best possible version of your MVP.
Do not think for a second that your local and prod environments are the same. They are not. YOU CANNOT REPLICATE YOUR APP LOCALLY - despite developers having done exactly that for decades.
You absolutely need an entire staging server with identical infrastructure to production. This ensures 100% of your code will work in prod if it works in staging - except for those mysterious production-only bugs that will still happen anyway. The doubled cloud costs and deployment complexity are a small price to pay for this felt sense of security!
You never know how many users will flood your app on day one, so you need to be prepared for anything. Sure, platforms like Railway or Vercel might let you deploy in minutes with zero configuration, but their CPU costs might be 5x normal AWS prices - a catastrophic difference when you're deploying a website that any human being on earthcan visit.
Avoid this naive mistake and configure a bullet-proof ECS cluster on AWS with auto-scaling policies, load balancers, and at least three environment-specific configuration files.
"Because of Terraform, having an entire infra stack for your website is easier than ever."
Why write SQL when you can add a complex abstraction layer that slows everything down?
ORMs are essential for your MVP because committing SQL queries into your codebase is not scalable. ORM will help you reverse migrations, manipulate python objects, and generate secure queries.
When your ORM produces a 30-second query, you'll be a much more robust backend programmer by spending days debugging Python classes in your abstraction layer instead of dealing with those SQL queries directly.
"Git diff works better with python classes than with SQL."
Because every user is a potential admin, moderator, editor, viewer, and superhero.
Your MVP absolutely needs a complex permissions system with hierarchical roles, custom permission flags, and a dedicated permissions database table. As soon as a new user asks for a specific feature, dont take the risk to share this feature to all possible users. Just play with permissions and roles to show the relevant features to the relevant users.
And nothing is better than a multi-tiers pricing system when you start, segmenting your users as efficiently and early as possible will save you a lot of headaches later. How can you know if you have found market fit if no segmentation exists? Don't rely on early adopters to tell you what to do.
"Pricing tiers system is a must for a successful startup launch"
Your MVP absolutely needs a sophisticated task queue system. Even though your app only needs to send a welcome email occasionally, you should implement a full Celery infrastructure with Redis as a message broker and separate worker processes.
Make sure to spend some time configuring supervisor scripts and monitoring dashboards before writing a single line of business logic. An app that cannot do async tasks should not make money. It would be a shame to the developer community.
Install a dedicated vector database, even though you still have a few files to embed. By doing that, you don't have the need to change your system later on.
Storing embeddings in a postgres ARRAY is definitely not a good idea. What will you do when you have more than 10M embeddings to store and you want to have a search in milliseconds ? Yes, you will have to change your system. Don't feel like a fool by anticipating those long term issues right now.
If you ever think of using files for storing your embeddings, I think you should start looking for a new job. Who would hire such an erratic developer?
"Use the scaling power of a vector database"
Microservices or bust! Conway's law demands at least 5 repositories for your blog.
You need at least a separate frontend, backend API, authentication service, and analytics microservice for your new site. Ideally, each should have its own repository, CI/CD pipeline, and deployment process.
Also, Github Workflow is not good enough, CircleCI might be able to do the job of most of your CI/CD pipeline. Github is not in the business of workflows, they are in the business of hosting your code. Do not trust github workflows.
Because your MVP needs 100% test coverage before a single user sees it.
Have at least 90% test coverage. Users will use your product in an unintended way, you need to be prepared for that by writing all the possible and imaginable edge cases.
"Build tests for edge-cases you never imagined"
Optimize for ultimate flexibility before you even know what your API needs to do.
RESTful APIs are for old apps that are not capturing the complexity of modern web-apps. Your MVP absolutely needs the complexity of GraphQL, schema definitions, resolvers, and a complex type system. The fact that you need to make simple CRUD operations is irrelevant - what matters is being ready for that hypothetical day when your client needs to fetch a deeply nested, precisely specified subset of your data model.
If you don't know GraphQL yet, spend some time learning about it. Your future potentials clients will thank you for that.
"GraphQL is compatible for modern web-apps needs"
TypeScript may offer decent type safety, but a real startup engineer knows it's full of escape hatches and compromises. Your MVP needs ReScript with their absolute type safety.
TypeScript isn't strict enough for a 0-bugs website
Perfect pixels matter more than validating if anyone wants your product.
Before writing a single line of code, hire a world-class designer to create a landing page worthy of being looked at. A different shade of blue for your call-to-action button could make all the difference for your conversion rate.
Once you've selected the perfect component library, immediately eject from its defaults and customize everything anyway. You need to differentiate your product from the competition.
Also don't forget to write tests around those UI components, you never know when those frameworks will release a breaking change.
Reuse the best UI components from the best UI libraries
Make sure to hire a professional lawyer to draft comprehensive privacy policies covering most of the jurisdictions in the most popular countries, a lawsuit can quikly kill your business, this is one of the most important threat to your success.
Also, earth is big, latency will kill your conversion rate. Activate multi-regions for webserver AND for database too.
Your mom in Nebraska and potential German users deserve a globally distributed architecture just like americans in us-west-2.
Every great product needs search functionality, especially
when you have barely any content to search through.
Search is always trivial to implement and absolutely critical for any website. Not the other way around.
Drive traffic to your unfinished product because acquisition matters more than retention.
Once your product sort of works (on your development machine, at least), it's time to spend your limited runway on Google Ads! The perfect way to get users without bothering with those fake branded social networks.
Your first $ budget should have a huge ad portion, specifically in the first weeks. First try targeting broad keywords, then sit back and let Google's AI optimize your campaigns for you while gradually narrowing your targeting.
You need to spend at least 1000$ on ads to get a good idea of your conversion rate, otherwise you will only be guessing with not significant data.
Build a complex cross-platform automation system before having content worth sharing.
No MVP is complete without a sophisticated social media integration. We don't know where our potential customers are, so the best way to catch them is to post everywhere and at the same time. Otherwise, there's no A/B testing possible. Build an automation tool that posts simultaneously across LinkedIn, Twitter, and Instagram with platform-specific formatting.
OpenAI and other API providers are far too slow and expensive for your MVP chatbot feature. The obvious solution is to fine-tune your own model on synthetic data and deploy it on GPU instances. Later, you will just need to retrain those llms with real data.
Fine-tune your own language model because 200ms faster response times will drive more revenue for free.
If you've diligently followed all the advice above, congratulations! You've successfully delayed your product launch by months, burned through your funding, and still have no idea if anyone wants what you're building. But at least you have a beautiful landing page and a custom LLM! Add that to your resume and you'll be in good shape for your next job.