Every founder eventually faces the stack decision. And almost every founder gets advice that treats the answer as universal: “Use Rails, it’s proven.” “Go with Next.js, everyone knows it.” “Invest in Go early, you’ll thank yourself at scale.”
The advice isn’t wrong, exactly. It’s just aimed at a different market.
If you’re building in Southeast Asia — with local talent markets, local infra costs, local investor timelines, and local users with local internet conditions — you’re making a different set of tradeoffs than a team in San Francisco. The framework debate is mostly noise. What actually matters is whether your stack lets you hire, iterate, and hand things off.
The Real Questions Behind the Stack Decision
Before arguing about React versus Vue or Postgres versus MongoDB, get specific about three things:
Who will maintain this in 18 months?
In Jakarta, Kuala Lumpur, and Ho Chi Minh City, the talent pool for certain stacks is materially thinner than others. Ruby on Rails engineers are rare. Go engineers with production experience are scarce. React developers are everywhere. Laravel developers are plentiful and underpriced relative to their quality.
Your stack choice is also a hiring choice. A codebase in a language with a thin local talent pool will be expensive to staff and fragile to maintain. If your technical cofounder leaves — and some will — your stack needs to be one that the next hire can pick up without a six-month ramp.
How fast do you need to change it?
A regulated fintech product needs a different iteration pace than a social app or a marketplace. Regulation forces deliberate change cycles. Consumer products demand velocity. The right stack for each is different.
Strongly-typed systems (Go, TypeScript, Rust) give you refactoring confidence as codebases grow. Dynamically-typed systems (Python, Ruby, PHP) give you faster initial iteration. Neither is universally better. The wrong choice is picking the one that sounds more impressive rather than the one that matches your actual change rate.
What does your infrastructure budget look like?
Not every startup in the region has AWS credits from a top-tier accelerator. Efficient runtimes matter when you’re paying rack by rack. Go and Rust are dramatically cheaper to run at the same throughput than Node or Python. But that difference only matters at scale — and most startups don’t reach the scale where it changes the unit economics.
What We’ve Seen Work
Over the projects we’ve shipped in the region, a few patterns have proven durable:
Go + PostgreSQL + React/Next.js works well for products where reliability and performance are table stakes — fintech backends, data-intensive platforms, anything that processes money or sensitive records. The stack is verbose but predictable, and junior engineers can reason about it without deep expertise in any particular paradigm.
Laravel + MySQL is still the workhorse of practical Southeast Asian web product. The developer ecosystem is deep, tutorials and Stack Overflow coverage are extensive, hosting is cheap, and a good Laravel engineer is much easier to find locally than a comparable Go or Rust engineer. For marketplaces, SaaS dashboards, and internal tools, we’ve seen Laravel codebases survive years of product iteration without becoming a maintenance crisis.
Python + FastAPI for anything AI-adjacent. The data ecosystem in Python is unmatched, and if your product involves any machine learning inference, document processing, or natural language work, the cost of not being in Python eventually shows up as integration friction.
React Native for mobile when the product truly needs both iOS and Android from day one and the budget doesn’t support two native teams. The tradeoffs are real — performance ceilings, platform-specific bugs that take disproportionate time to fix — but for most B2B or utility apps, the shared codebase wins the resource argument.
What We’ve Seen Fail
Microservices from day one. It’s a seductive architecture. It sounds like you’re building for scale. In practice, a three-person team trying to coordinate across six services produces the complexity of a large system with none of the throughput to justify it. Start with a well-structured monolith. You’ll know when you need to extract something; the data will tell you.
Exotic stacks for the sake of technical credibility. Founders sometimes choose stacks they’ve read about in Hacker News threads rather than stacks their team knows. A great engineer in a familiar language will outperform a mediocre engineer in a fashionable one every time.
Skipping TypeScript because “it slows us down.” This argument sounds reasonable in week two and catastrophic in month twelve. Every JavaScript project of any meaningful size either adopts TypeScript eventually or becomes a maintenance burden that drains engineering hours. Add it at the start.
The Handover Dimension
This one is specific to how we think about stack choice: whatever you choose, it needs to be something your team can own without us after we leave.
We’ve worked with founders who fell in love with clever technical choices during the build — custom DSLs, unusual ORMs, bespoke deployment setups — that became a dependency on the original engineers. Two years after launch, they couldn’t hire into the codebase because it required institutional knowledge to navigate.
Boring stacks are underrated. A codebase that any competent engineer can navigate on day one has compounding value over years. The cleverness pays off once, during the build. The boringness pays off continuously, in every hire, every review, every incident at 3am.
A Practical Framework
Here’s how we think through the stack decision with new clients:
-
List the five engineers you’d realistically hire in the next 12 months. What do they know? Build for them, not for the imaginary team you might have someday.
-
Identify your change rate. Weekly deployments? Monthly? Quarterly? Match your stack’s verbosity to your change cadence.
-
Establish your infra budget. If you’re bootstrapped or pre-seed, start with managed services. Heroku-equivalent, managed databases, simple deployment targets. Optimise infrastructure later when the product has traction.
-
Lock in observability from day one. Whatever you build, add logging, error tracking, and performance monitoring before you launch. The stack choice matters less than your ability to see what it’s doing in production.
The framework debate will continue on the internet. Meanwhile, the products that succeed are usually the ones built on something their team could actually ship and maintain — not the ones built on the stack that won the argument.
Choose accordingly.