Skip to content

Start with the problem, not the stack

A first version that people can use beats a perfect architecture document that never ships.

Chelevenild

Most stalled products we see did not fail because the team picked the wrong framework. They failed because the first slice was too big, or because nobody wrote down what “done” meant.

We start with a narrower question: who is this for, what should they be able to do, and what can wait. Then we pick a stack that the team can actually run.

That sounds obvious. It is also the part that gets skipped when a project opens with a shopping list of tools.

If you are about to start something, send the problem. The stack can wait a day.