I Built a Ferrari for a Skateboard: 5 Engineering Mistakes That Cost Me Months
We’ve all been there. You have a great idea, and you want to build something serious.
You start drawing up complex diagrams and setting up complicated systems. Before you know it, you’ve built a complex laboratory instead of an actual product.
I’ve been a founding engineer and a CTO, and I learned these lessons because I failed. I built things that didn't work, deleted databases I shouldn't have, and spent weeks fighting infrastructure that didn't need to exist.
That's why I’m sharing the mistakes that turned my projects into scalable pieces. Here is what I learned about building for reality, not for the resume.
1. Be Careful with Distributed Systems
When I started my projects, I thought a modern stack meant React, a separate backend, and a network of microservices. I treated my MVP as a critical system with millions of concurrent users.
The trust was simple. It was an idea that needed to be validated. When I created a distributed system for an MVP, I spent 80% of my time fighting network latency and deployment configurations, and 20% of my time actually building features. Here's when I learned the following:
A monolith is the fastest path to market.
If you aren't at the scale where you need to separate your services, don't use them. Don't pay the distributed system tax until you actually have the traffic to justify it.
2. Manual Labor (Clicking in the Terminal)
I’m sorry to say it, but I spent too much time clicking around the AWS/DigitalOcean dashboards like a trainee in existing projects. I built professional DevOps pipelines for projects with fewer than 100 users.
There I was, documenting the deployment setup using Notion and copying and pasting the same Linux commands...
If it’s not in code, it doesn’t exist. I learned the hard way that Infrastructure as Code (IaC) isn't just for major companies. Tools like Pulumi or Terraform should be your first commits. For any serious project, you should automate your infrastructure from day one, or accept that you’re going to be your own worst bottleneck.
3. Building a Ferrari for a Skateboard Request
The most important lesson? Know your scope.
I built a Ferrari when the user and the market only needed a skateboard. I obsessed over the engine specs, the aerodynamics, and the fuel efficiency, but I forgot to check if the skateboard even rolled.
I created OpenAPI specifications and enterprise DevOps deployments for an MVP... I'm not proud of that.
If your goal is to validate an idea, build a skateboard. If the skateboard takes off, then you can build the Ferrari.
Don’t fall in love with the engineering at the expense of the product.
4. Keep your Communication Simple
Stop using technical jargon to justify business decisions. It doesn't make you look smart; it makes the project look complicated and risky.
Use Visuals: I started using a digital drawing tablet. It lets me sketch high-quality diagrams live in meetings, making complex ideas clear to everyone instantly.
Focus on Results: Don't sell the tech stack. Sell the result. Instead of saying, "We're using X because of our microservice architecture," you can say, "We're using X to ship features twice as fast."
5. Master the Tools you Have
Adding more tools won't fix a lack of mastery. Success comes from doing more with less.
Think like a musician: Michael Jackson didn't need 100 tracks to write a hit; he mastered simple, fundamental chords and arrangements.
If you can’t build a great product with a simple setup, adding more complexity won't save you; it will just hide the problem. Master your tools, stay within your constraints, and focus on providing value to your users.
TL;DR
Always start with a monolith.
Use Terraform and set up your project properly. The foundation is everything.
Ask "does this need to exist?" before asking "can I build it?"
Communicate with diagrams and simple terms, not jargon.
Master fewer tools. Use them better.
Conclusion
Thanks for reading. I’m currently pivoting my workflow to prioritize speed and simplicity in my next projects. If you’ve learned the hard way that less is more, I’d love to hear your war stories in the comments.
I'm also open to product engineering roles at https://www.itsfranciscoluna.com/, where I worked with brands like Edge Fitness on products I contributed to, maintaining 99.9916% uptime in the systems I built solo.
