Hien Phan
Hien Phan
WorkAI craftWritingAbout
WorkAI craftWritingAbout

Apps

SpeakEn
Back to Writing

How I Choose Tech That Ships Fast

As a solo founder, every tech decision feels critical, and I've definitely made choices that slowed me down. This post reveals my evolving philosophy for choosing a 'Minimum Viable Stack' – focusing on familiarity, speed, and cost-effectiveness over shiny new tech. I'll share specific lessons learned from past tech stack experiments (both good and bad) and a simple decision-making framework to help you pick the right tools to ship your MVPs faster.

November 20, 2024•4 min read•Hien Phan
Indie Hacking
indie-maker
mvp
technology
learning
mistakes

My 'Minimum Viable Stack' - How I Choose Tech That Ships (Not Stalls) My Products

The Allure of the New and the Pain of Delay

I remember the early days of my 52-product challenge. The excitement was palpable, and with it came the shiny object syndrome.

Every new JavaScript framework, every novel database, every cool new tool felt like a potential secret weapon. I’d dive headfirst into learning them, spending weeks mastering a new technology for a single product.

The problem? This often led to significant delays.

I’d spend so much time on the "how" that the "what" (actually getting the product to users) got pushed back. That was a costly lesson, learned the hard way.

A developer looking overwhelmed by a wall of different technology logos.

The Paradox of Choice: Shiny vs. Shipping

As solo founders, we face a unique challenge: the paradox of choice in tech stacks. The sheer abundance of amazing tools available today is a blessing, but it can also be a curse. It’s easy to get caught in analysis paralysis, chasing what seems like the "perfect" stack instead of what's fastest to ship.

This often leads to over-engineering and, ultimately, delayed launches. We convince ourselves that learning that cutting-edge new framework will save us time in the long run, but more often than not, it introduces new bugs, steeper learning curves, and more time spent debugging than building core features.

My 'Minimum Viable Stack' Decision Framework

Over time, I’ve developed a philosophy I call the 'Minimum Viable Stack' (MVS). It’s not about using the absolute cheapest or easiest tools, but the ones that allow me to ship the fastest, learn the quickest, and iterate effectively. Here’s how I approach it:

  1. Prioritize Familiarity Over Novelty: If a technology you already know well can get the job done for your MVP, use it. Speed of development trumps learning a new, potentially better, tool for the initial launch.
  2. Focus on Integrated Solutions: Look for platforms that handle multiple aspects of your stack.

Think Supabase instead of separate PostgreSQL, Auth0, and S3. Integration means less glue code and faster setup.

  1. Cost-Effectiveness for Early Stages: As a solo founder, every dollar counts. Choose tools with generous free tiers or low monthly costs that scale with your growth.
  2. Community Support and Documentation: When you hit roadblocks (and you'll), a strong community and clear documentation are lifesavers. This can drastically reduce debugging time.
  3. "Good Enough" is Better Than "Perfect": For an MVP, the goal is to validate an idea, not to build a flawless, infinitely scalable masterpiece. Embrace "good enough" to get feedback.

A simple flowchart illustrating the MVS decision-making process.

Real-World Examples: What Worked and What Didn't

Let me share some concrete examples from my journey.

For one product, I decided to go with a complex GraphQL setup for what was essentially a simple CRUD (Create, Read, Update, Delete) application. I spent weeks wrestling with schema design, resolvers, and client-side caching.

By the time I finished, the core functionality was there, but the development time was significantly longer than it needed to be. The "fancy" tech choice backfired.

On the flip side, for a recent project, I stuck with my tried-and-true Next.js and Supabase combo. I knew Next.js inside and out, and Supabase provided database, authentication, and storage in one package.

I was able to build and deploy the MVP in just a few days. The familiar stack allowed me to focus entirely on the product features and user experience, not on fighting with new tools.

The tech stack for that recently launched product?

  • Frontend: Next.js (React framework)
  • Backend/Database: Supabase (PostgreSQL, Auth, Storage)
  • Deployment: Vercel

This combination allowed for incredibly rapid development and iteration.

Stop Overthinking, Start Shipping

The biggest takeaway for me has been to stop overthinking the tech stack. Your goal as a solo founder is to get your Minimum Viable Product into the hands of users as quickly as possible.

Choose tools that leverage your existing skills, offer integrated solutions, are cost-effective, and have strong community support. Embrace "good enough" for your MVP. This approach will help you ship faster, learn from real users sooner, and build a sustainable business without unnecessary delays or steep learning curves.

Your next product is waiting. What will your Minimum Viable Stack be?

A graphic showing a product being shipped out of a factory quickly and efficiently.

Previous

How I Prototype Fast with Next.js and Supabase

Next

How I Kill Bad Ideas Before They Waste My Time

Hien Phan
Hien Phan

Full-stack engineer shipping production-grade web systems. Real apps, real stack.

Navigate

  • Work
  • Writing
  • About
  • Contact

Live apps

  • SpeakEn

Reach out

harrisonphan5@gmail.com

Saigon, Vietnam
Product-minded teams. AI-native product work welcome. Remote-friendly. Based in Vietnam (GMT+7).

© 2026 Hien Phan. All rights reserved.

Built with Next.js · TypeScript · SQLite · self-hosted KVM