Architecture Choices: Lessons from Two MVP Journeys

Photo by Emile Perron, Unsplash.
The first time I stepped into a Technical Lead role, I was the only person on the team. I had to hire teammates one by one while racing against the deadlines of an MVP. At that stage, we chose Next.js for the frontend and Django for the backend. It was a solid choice, but the split stack brought its own challenges: hiring was slower, onboarding took longer, and the complexity added extra pressure to the team.
Two years later, I joined another organization as a Technology Consultant. The situation looked familiar: a new team, tight deadlines, high expectations. But this time my role was different. I wasn’t hands-on with the code. My responsibility was to design the architecture and monitor the systems.
Here, I made a different choice: we built the MVP with Django and its templates, avoiding a separate frontend and backend. The results were striking:
- We hit deadlines much faster.
- The hiring load was lighter.
- Onboarding was quicker and smoother.
That experience taught me something important: choosing exemplary architecture isn’t just about the tech stack. It’s about context. You need to weigh factors like:
- Talent availability. (in your geography or network)
- Deadline pressure.
- Budget and team seniority.
Starting simple, without overengineering, gives your team the momentum it needs. Later, as the product matures, you’ll always have the option to Refactor or even rewrite parts of the system. That approach reduces long-term workload and stress.
My takeaway: when picking a stack, don’t only chase “cool” technologies. Pay attention to the real constraints of your team and business. That’s where impactful decisions are made.