A Practical Stack for Shipping Fast
How I think about choosing a stack that supports speed without creating painful maintenance.
My favorite stack is the one that lets me ship the product and still respect the person who has to maintain it later. Sometimes that person is a teammate. Often it is future me, slightly tired, trying to remember why I made a decision three months ago.
That thought keeps me practical.
I like modern tools. I like clean architecture. I like trying new things. But I care most about whether the stack helps the product move without turning every change into a negotiation with complexity.
The stack has a job
For most products I build, the stack needs to do a few things well:
- Make common features easy
- Keep deployment understandable
- Let the team debug production issues
- Leave room for AI workflows without making everything fragile
- Stay boring enough that hiring and handoff are not painful
That is why I often end up around TypeScript, React or Next.js, Laravel or Node.js, PostgreSQL, queues, Docker, and cloud services that do not need a heroic setup.
It is not because those tools are perfect. It is because they are familiar, capable, and easy to reason about under pressure.
Speed without cleanup is debt
Shipping fast is not the same as rushing.
Rushing is when you ignore the shape of the system because the deadline is close. Shipping fast is when the system is already simple enough to let you move.
There is a big difference.
I try to keep the first version small, but not careless. That means naming things clearly, keeping boundaries visible, writing the tests that protect the risky paths, and documenting the decisions that future me will probably forget.
You do not need a huge architecture document. Sometimes a few clear notes are enough.
AI changed my defaults a little
AI features add new pressure to the stack. You need jobs for long-running work, storage for traces and outputs, policies around data access, and a way to evaluate behavior that is not fully deterministic.
Because of that, I now think about observability and background processing earlier than I used to.
Even in a small product, I want to know what the AI is doing, what it costs, where it fails, and how users recover.
The goal is momentum
A practical stack does not try to impress anyone. It gives the product momentum.
That is the kind of stack I trust most.