Most early products don't need the database yet

There's a moment in every early product where someone says "we'll need this later": a database, an admin panel, a message queue, a role system. It's almost always true. It's almost never true now. And the gap between those two facts is where early products go to die.

We recently rebuilt our own studio site and deleted, in one afternoon: a database, an authentication system, a twelve-section admin dashboard, a client portal, and a chatbot. The site's actual job, convincing a visitor that we can help and starting a conversation, needed none of it. What it needed was better writing and a contact form that reliably lands in our inbox.

The real cost isn't building it

Building the admin panel takes a weekend. That's not the cost. The cost is everything downstream:

• Security surface. An auth system on a marketing site is a locked door on a building with no walls. It can only ever be a liability.
• Maintenance gravity. Every dependency update, every migration, every "why is this query slow" now belongs to you, forever.
• Decision drag. Infrastructure creates categories, and categories shape thinking. Once you have a CMS, every content change becomes a CMS feature request.

What "later" should actually look like

Deferring infrastructure isn't the same as ignoring it. The trick is choosing structures that upgrade cleanly:

• Content in files. Markdown in a git repository is a real CMS: versioned, reviewable, backed up, and free. When you genuinely need an editor UI, your content is already structured and portable.
• Forms into email. A contact form that hits a transactional email API needs no table. When volume justifies a pipeline, you'll know, because you'll be drowning in leads, which is the good problem.
• Static by default. Pages rendered at build time are fast, cheap, and unhackable in ways dynamic pages have to work hard for. Reach for runtime rendering when a page truly differs per visitor.

The heuristic

Before adding a piece of infrastructure, ask: what breaks this week if we don't? If the answer involves a hypothetical future user, defer it. If the answer involves a real person hitting a real wall, build it properly.

The discipline compounds. Every subsystem you don't build is code review you don't do, incidents you don't have, and attention you can spend on the only early-stage question that matters: does anyone want this?