Choosing a Stack You Will Not Regret: The Decisions That Are Cheap Now and Brutal at Scale

Nobody plans to migrate a database. Ask a team that has been through one what it cost and you hear the same list: schema rewrites, data transfers that choke on real records, connection strings buried across services, every query retested, a roadmap frozen for months. The decision that caused all of it usually took an afternoon. It was made early, made casually, and made because a tutorial happened to use that tool.

That is the defining pattern of stack regret. The choices that hurt at scale are rarely the ones teams agonise over. They are the ones that felt free at the time.

Sort every choice by the cost of reversing it

Most stack debates burn energy on the wrong questions. Tailwind or vanilla CSS, REST route naming, monorepo or not: these are loud arguments about cheap decisions. If you change your mind later, you refactor and move on.

A small set of decisions behaves differently. They are trivial to make on day one and brutal to unmake once real data, real users and real integrations sit on top of them:

• The database engine, and whether it is a portable standard or a proprietary platform
• The auth provider, because identity touches every session, token and permission check
• Where files live: in the database or in object storage
• The shape of your API contract, and whether it is versioned
• Anything that hard-couples your data to one vendor's query language

The discipline is simple. Spend your deliberation where reversal is expensive. Decide the cheap things fast and the sticky things slowly.

Choose the database for the workload, and keep the exit open

The brand of your database matters far less than the shape of your traffic. Most applications are read-heavy: users load dashboards, lists and profiles constantly and write occasionally. A read-heavy app wants fast reads served close to users. A write-heavy app with serious concurrency wants an engine and an architecture built for write contention. Start with your read/write ratio, not with whichever product is trending this quarter.

Then ask the question most teams skip: are you choosing a database or a platform? A tightly integrated stack, where the database, functions, storage and cache all come from one vendor, is genuinely powerful. It is also a commitment. Standard Postgres or MySQL will run anywhere: managed, serverless, or on your own hardware. Document stores that are effortless to prototype on become painful the day you need real joins and multi-condition filters, and painful again the day you want to leave. Relational engines with plain SQL give you a door out. You may never use it. Having it changes every future negotiation.

Three questions before you commit

• How does this platform handle schema changes under live traffic? Platforms that can branch a production database, test a migration and merge it back remove a whole class of downtime.
• What does behaviour look like under real load, not on the free tier? Cold starts, connection models and scaling behaviour differ sharply between providers.
• Does my team already know this engine? Abandoning the engine your team understands because of marketing is a tax with no refund.

Buy the commodity, build the differentiator

The build-versus-buy mistake usually runs in the wrong direction. Teams buy the thing that makes them different, then spend years fighting a vendor's opinions, while hand-rolling things the market solved long ago.

Auth is the sharpest example. A login form looks like a weekend of work. The real surface is password resets, email verification, session management, token rotation, multi-factor, account recovery, and the security edge cases hiding inside each one. This is infrastructure where a single bug can end a company, and building it yourself earns you nothing competitively. Buy it.

But buy it deliberately, because switching identity providers after launch is one of the most painful migrations in software. Match the provider to the business you are building: enterprise buyers will demand SAML and directory integration, a modern SaaS may want polished drop-in components, and some teams will rightly choose self-hosting to own their auth data and remove vendor pricing risk. Pick once, on purpose.

For everything else, apply a hard test before building. Does the off-the-shelf option genuinely fail your use case, rather than mildly annoy you? Could you build something ten times better, not slightly better? Does owning it create an advantage that compounds? Unless all three answers are yes, buy, and put your engineering hours into the thing customers actually pay you for.

Put files, vectors and heavy traffic where they belong

Some regret is not about which vendor you chose but about asking one component to do another component's job.

Files are the classic case. Storing images, PDFs and video in database columns forces the database to do work it was never designed for, and you pay for that mismatch in performance and in your bill. The pattern that survives is boring: files go in object storage, the database stores the URL, and a CDN serves the file from an edge node near the user instead of hammering your origin on every request.

Vectors are the newer version of the same trap. Teams adding AI features reach for a dedicated vector database by default. In most cases the embeddings can live inside Postgres, next to the relational data they describe, covered by the same backups, the same access controls and the same operational habits your team already has. A specialist vector store earns its place only when vector search at enormous scale is the product itself. Every additional datastore is another thing to back up, monitor, secure and explain at three in the morning.

Match the platform to your stage

Hosting follows the same logic. Edge-focused platforms are superb for front-ends and fight you on long-running processes and persistent connections. Managed full-stack platforms trade money for time, and for an early team that trade is usually correct: you are paying someone else to handle patches, backups and incidents while you ship. Self-hosting trades time for control and makes you the infrastructure team. Neither is wrong. What is wrong is choosing based on last week's tutorial instead of the stage your business is actually at, or staying put long after the cost of workarounds exceeds the cost of moving.

Make the API a contract from day one

The quietest expensive decision is treating your API as an internal detail. The moment anything external consumes an endpoint (a customer integration, a mobile app, a partner, an AI agent) its shape becomes a promise.

Three habits cost almost nothing now and save you a rewrite later:

• Write the contract down. Every endpoint has a defined shape for what it accepts, returns and rejects, enforced in the schema rather than remembered in someone's head.
• Version from the first release. Ship v1, not an unversioned default. When a response shape must change, it becomes v2 and existing consumers keep working.
• Announce changes before they ship, with deprecation notices and migration paths. A surprise breaking change tells everyone building on you that they should not.

This matters more, not less, in the AI era. Systems built for humans clicking screens force AI integrations into scrapers and brittle workarounds. If every feature begins as an endpoint, the human interface and the machine consumer are both just clients of the same contract, with the same security and the same data. That one architectural habit keeps your product open to consumers you have not imagined yet.

Get the playbook

We have condensed these decisions into a free PDF: the reversal-cost checklist, the database and auth selection questions, and the build-versus-buy test in one reference you can run against your own stack. Download Choosing Your Stack and pressure-test your next architecture call before it becomes permanent. It is part of our full engineering playbook series at /resources.