Tech Stack Decisions

Tech Stack Decisions

You have made dozens of tech stack decisions already: Next.js for most of your web projects, Supabase for your databases, Vercel for hosting, Railway for background services. These are good choices. But as your platforms grow and clients depend on them, the consequences of stack decisions compound — which means understanding why you made those choices (and when to reconsider) becomes a real leadership skill.

The Build vs. Buy vs. Subscribe Framework

The default instinct for most technical founders is to build. Building is satisfying, gives you complete control, and avoids subscription costs. But the hidden cost of building is everything that happens after launch: maintenance, security updates, scaling, debugging, and upgrading. Before building anything, ask: is this differentiated enough from what exists that the custom build creates value that justifies its ongoing cost?

Build when:

• The capability is your core competitive advantage (the thing clients pay you for)
• No existing solution fits your use case closely enough that customization would cost as much as a build
• You need proprietary data or behavior that cannot exist in a shared vendor environment

Buy (open-source, self-hosted) when:

• The capability is not differentiated, but you need full control over the data
• You have the engineering capacity to maintain and upgrade it
• The licensing model allows it at your scale

Subscribe (SaaS/API) when:

• The capability is commodity infrastructure (email delivery, payments, SMS, authentication)
• The vendor invests significantly in keeping it reliable and secure
• Switching cost is manageable if the vendor changes pricing or goes down

Most of your stack is correctly "subscribe" — Resend for email, Stripe for payments, Clerk for auth, Twilio for SMS. These are not your competitive advantage. They are table stakes. Subscribing to them lets you invest engineering time in what actually differentiates you.

Evaluating New Technology Choices

When a developer recommends a new framework, library, or service, the right questions are not technical — they are strategic:

• How mature is it? A framework with 3 years of production use has solved problems a 6-month-old framework has not encountered yet.
• What does the vendor's business model look like? Free tools with no clear monetization path tend to die or pivot to paid unexpectedly. Understand who funds the tool.
• How hard is it to migrate away from? If the vendor changes pricing or the project is abandoned, what is the replacement cost?
• Is your team already proficient in it? Context-switching between technologies has a real cost in developer time and bug rate.

Avoiding the Over-Engineering Trap

Technical teams left to their own priorities will often reach for more sophisticated tools than the current scale requires. A system serving 500 users does not need Kubernetes. A database with 10,000 rows does not need a caching layer. A team of 2 developers does not need a microservices architecture.

The principle: match infrastructure complexity to current scale, with a one-phase look-ahead. Build for where you are and what you will need in 12 months — not for the architecture a 500-person engineering team would use.

Over-engineering has a real cost beyond the initial build: more complex systems are harder to debug, harder to onboard new developers into, and have more potential failure points. Simple systems that handle current load are worth more than elegant architectures that require specialists to operate.

Understanding Lock-In in Your Current Stack

You are locked into Vercel for hosting, Supabase for databases, and Clerk for auth across most of your platforms. Here is how to think about each:

Vercel: Moderate lock-in. Next.js works elsewhere, but Vercel's Edge Functions and deployment config are proprietary. The lock-in is manageable because the alternative (self-hosted Next.js on a VPS) is always available.

Supabase: Low lock-in. It's Postgres underneath. If Supabase changed pricing dramatically, migrating to a managed Postgres alternative (Neon, Railway Postgres, AWS RDS) would be a 1-2 week engineering effort, not a rewrite.

Clerk: Medium lock-in. Authentication is deeply integrated into user data and session management. Migrating auth providers is painful but doable. The real lock-in is the time cost, not technical impossibility.

Understanding the migration cost of your current dependencies is the basis for making good vendor negotiation decisions — and for knowing which vendor relationships are worth investing in versus which you should architect away from over time.