./i-dont-know-the-stack
The right stack, no guesswork.
One person says React Native. Another says native or nothing. A no-code consultant promises you'll never write code at all. Everyone sounds certain, and everyone has an incentive.
Here's what a decade of shipping teaches: for most early products, the framework matters far less than the data model underneath it. That's the decision worth agonising over, and it's the one we'll get right.
How this works
A short engagement: a call, sometimes two, plus a written recommendation. I look at what you're building, who it's for, how fast it needs to move, and your realistic budget. You get a specific answer, tailored to your product.
Zero reseller relationships, zero vendor partnerships. Sometimes the honest answer is "start on Bubble, you'll know within six months whether you've outgrown it."
The questions that actually decide it
Offline requirements? This narrows things fast.
Heavy on-device work? Camera, audio, real-time. This is where cross-platform starts costing more than it saves.
How many platforms on day one? One is usually the right answer.
Who can you hire later? A stack you can staff beats a stack that benchmarks well.
What's reversible? The frontend, mostly. The data model, no. Spend your worry there.
My default, and when I break it
For most products: TypeScript, Next.js on the web, React Native or Expo on mobile, Postgres via Supabase. Fast, staffable, and almost every door stays open.
I break it for heavy on-device work, serious offline requirements, and teams that already know something else well. A team's existing knowledge usually beats a marginally better tool.
FAQ
- Is React Native good enough for a real product?
- For most products, yes. My own app does real-time photo analysis on React Native and runs beautifully. The line where native becomes necessary sits further out than most people assume.
- Supabase or Firebase?
- Supabase for SQL, relational data and a clean exit path. Firebase if you're deep in Google's ecosystem and your data is genuinely document-shaped. Most products turn out relational, and it pays to know that early.
- Can I start with no-code and migrate later?
- Yes, and it's often the right call. The migration cost is real, but you pay it later with better information. Plenty of products never need to migrate at all.
- What's the most expensive mistake at this stage?
- A data model that only fits version one. Changing the frontend is a project. Changing the data model with real users on it is surgery. Getting it right early is the whole game.