Stacks

The stack you choose is a bet on who maintains it

Every stack decision is really a staffing decision. Here’s how I pick platforms by who has to live with them after launch.

The stack you choose is a bet on who maintains it

In short: choose a stack by who answers the 2am call, not by what demos best. The most durable choice is the one your actual team can hold in their head two years from now, which is a people question long before it’s a technology question.

The 2am call

Six months after launch, something breaks at 2am. The person who picks up has never seen the code. The developer who built it has moved on, or moved teams, or is simply asleep and off the project. What was an elegant stack in the pitch is now a black box with a paying customer staring at an error. Nobody chose this moment. It was chosen for them, months earlier, by a decision that felt like it was only about technology.

That’s the moment I try to design backward from. Not the demo. The 2am call.

Start with the maintainer, not the framework

Most stack debates argue performance and developer experience. Both matter, but they sit downstream of a harder question I ask early: who keeps this running two years from now, and what do they already know? A stack a solo founder maintains is a different animal from one a rotating agency team maintains. My team and I have shipped both, and the failures were rarely technical. They were almost always handoffs.

The best stack is often the one your team can still reason about at 2am, months after the people who built it have moved on.

Three questions before the first commit

  • Who edits the content, and do they need a developer to do it?
  • Who fixes it when it breaks, and how quickly can they get up to speed?
  • What happens when the original builder moves on?

For a content-led site with non-technical editors, the answers usually point toward Webflow or WordPress long before a bespoke build. Not because the code is better, but because the maintenance surface is smaller and kinder to whoever is left holding it.

When custom is the honest answer

Sometimes the product genuinely needs it. Real-time state, complex auth, heavy data. Then you take on the staffing cost with open eyes and budget for it, including the 2am coverage. The trap is reaching for a serious-sounding custom framework because it feels impressive, and then handing it to a client who only wanted to change a headline.

What this means for your next build

Before you fall for the most impressive option, picture the 2am call and ask who answers it. Choose the stack that person can hold in their head. Most other things are negotiable. This one quietly decides how the next two years feel.

This is exactly the kind of decision I like helping clients make at Dthree Digital, before it gets expensive to undo.

Related reading

Keep reading

Have a project in mind?

Let's build something that lasts

Get in touch

Based in Manila, working with teams across time zones.