From Scratch to Production: Choosing the Right Stack

I build things end to end, from scratch to production. You talk to the one person who writes the code. That means the stack is my decision, and I try to make it for the job, not for fashion.

I have no favourite tool to defend. A tool is good when it fits the work.

The short list

Here is how I think about it, as plain pseudocode.

IF the job IS a content site THEN use vanilla PHP
IF the job NEEDS live updates THEN add Node.js with WebSocket
IF the job IS data or AI work THEN use Python where it fits
IF people NEED it as an app on phones THEN add React Native
IF AI does NOT save time or answer a real question THEN leave it out
BUILD it boring and reliable first, THEN add the fun

It is short on purpose. Each line is a question about the job, not about the tool.

Vanilla PHP when it is the lightest

A lot of work is pages: a site, a form, a small tool. For that, plain PHP is often the lightest thing that does the job. There is little to install and little to break. I come back to the same habit I wrote about in what the DOS era taught me: write the least code that does the job.

Node.js and WebSocket for real-time

Some work has to feel live. People in the same room, a map that moves, a message that arrives as it is sent. For that I use Node.js with WebSocket. The connection stays open, and the server can push updates. You can see this kind of work on my real-time and backend service page.

Python where it fits

Data work and AI work often sit well in Python. I use it where it fits, and I do not force it where it does not.

React Native when it must be an app

If people need the product as an app on their phones, I build a real app with React Native. The same thinking applies: build the app when the job needs one. The mobile app service page has more, and NativePress is a public example.

AI only where it helps

AI is a tool like any other. I add it where it saves time or answers a real question. If it does neither, it stays out.

Boring first, fun after

The first version should be boring and reliable. It should start, work and not get in the way. Once it works, there is room for the fun parts. A stack that is easy to understand also helps the person who takes it over later, which is why every project of mine ends with a handover and a rollback plan.

Try it

Here is a small toy. Answer three questions and see a suggested stack with one reason for each part. It is a toy, not a verdict. Every real job has details that three questions cannot hold.

More small toys live in the widgets, and more essays are in the notes.

Want to talk it through?

My process starts with a free tech-stack consult. After it you get a one-page written recommendation. Nothing is built before the scope is agreed in writing. If you are choosing a stack for something new, I am happy to help.

Book a free consult

Where this comes from

The decision list is my own way of working. The service areas and the NativePress example are described on the public services and work pages.