Building an app before deciding its tech stack

It is tempting to choose the stack first. A new framework gives the project a shape before the idea has earned one.

I have done this more times than I can count. The repository looks tidy. The architecture has opinions. The actual product is still a sentence.

Start with the awkward part

Before choosing tools, I try to build the riskiest interaction as plainly as possible. Not the sign-in screen. Not settings. The thing that makes the app worth opening.

For a voice-notes app, that might be the moment a recording becomes organised text. For a reading tracker, it might be adding a book in a few seconds.

The prototype tells me what the project needs:

• Is the experience mostly local?
• Does it need to work offline?
• Where does speed actually matter?
• Which parts are likely to change?

Those answers are more useful than a favourite-tools list.

Boring is often a feature

Once the problem is clearer, the stack choice usually becomes less exciting. That is good. Familiar tools leave more attention for the product.

I still enjoy trying new technology. I just try not to make a user carry the cost of my curiosity.

The best stack is not the one I am most excited to announce. It is the one that quietly lets me finish.