Stack for Small, Medium, Large Projects: Honest Picks

The Wrong Stack Kills More Projects Than Bad Ideas

I've watched a founder spend six months on a microservices architecture for a project that needed a spreadsheet and a script. I've also seen a business outgrow a cobbled-together solution in three months because it was never built to scale. Both hurt. The difference between success and burnout often comes down to matching your tools to your actual stage.

Let me walk you through what I actually recommend—no hype, just what works.

Small Projects: Spreadsheet + Automation First

If you're validating an idea, testing a market, or running a small operation (under 50 transactions a day, one or two people), start with a spreadsheet and glue it together with automation.

• Google Sheets + Zapier or Make: Connect your Sheets to WhatsApp, email, Stripe, or whatever you're using. Takes hours, not weeks. Cost is maybe $20–50/month.
• Airtable: Slightly more structured than Sheets, still low-code. Better if you need custom fields or light reporting.
• Why this works: You learn what your customers actually need before you code anything. You can change the workflow in minutes. You're not maintaining infrastructure.

I've seen one-person businesses run 10k/month in revenue on nothing but Sheets + Zapier. The moment you feel friction—manual data entry, repeated steps, mistakes—that's your signal to build.

Medium Projects: Next.js + Supabase (or Equivalent)

When you've validated the idea and you have real users (50–500 transactions a day, 3–10 people), you need something faster and more reliable than automation glue, but you don't need enterprise complexity.

My honest stack for this stage:

• Next.js + Supabase: Full-stack JavaScript, PostgreSQL database, built-in auth, real-time features. You deploy on Vercel, database scales painlessly. One developer can ship features in days.
• Alternative: Django + PostgreSQL if your team knows Python. Same principle—boring, proven, fast to build.
• Add a simple job queue: Bull or Inngest if you need background tasks (sending emails, processing images). Don't overcomplicate; add it when you actually need it.

Why this works: You own your data. You can customize anything. You're not locked into a SaaS pricing model. A single developer or small team can maintain it without burning out.

Cost reality: Hosting runs $20–100/month. You're paying for your own time, which is the real cost.

Large Projects: Queues, Async Work, and Microservices (Only When You Earn It)

If you're doing 5,000+ transactions a day, managing complex workflows (payments, fulfillment, notifications), or your team is 10+ people, then you think about:

• Message queues: RabbitMQ, Redis, or Kafka to decouple services and handle spikes.
• Microservices: Only if you have different teams owning different parts (payments team, logistics team, etc.).
• Caching layers: Redis for fast reads on hot data.
• Proper monitoring and logging: DataDog, Sentry, structured logs.

This complexity buys you: handling traffic spikes without crashes, independent scaling, teams working without stepping on each other.

But here's the honest part: If you build this way too early, you'll spend 80% of your energy managing infrastructure and 20% building features. Your startup dies of complexity, not bad ideas.

The Real Rule: Match Scale to Reality

Over-engineering wastes time you don't have. Under-engineering wastes time later. The trick is honest self-assessment:

• Are you still learning what customers want? Use a spreadsheet.
• Do you have product-market fit and real users? Build a simple, maintainable app.
• Are you running a stable, high-volume operation? Invest in architecture.

When I build systems with Hailan—custom software for real processes like WhatsApp + CRM, POS, e-commerce, or supplier connectors—I start by asking what you're actually doing today. Usually, the answer isn't 'we need microservices.' It's 'we're copying data between three systems by hand, and it's killing us.' That tells me exactly what to build and how.

Pick the stack that solves your problem today, not the one that might impress someone tomorrow.