Build or buy, the honest version

Buying is usually right. If an off-the-shelf product does eighty percent of what you need and you can live with the other twenty, buy it, and put the money you saved into the part of the business that actually differentiates you. I’ll tell you that if it is true, and it frequently is.

Building is right when one of three things holds. The process you run is the advantage, the thing you do differently from competitors, and bending it to fit someone else's software erases exactly what makes you money. Or you’re paying per seat for a product where you use a fraction of the features, and the cost curve gets worse as you grow rather than better. Or the tools genuinely don’t exist, which is more common in specialized trades than most software people assume.

The expensive middle ground. The worst outcome is buying something that nearly fits and then paying for years of workarounds, spreadsheets alongside it, manual steps between systems, a person whose job is to reconcile two tools that should be one. That cost is real and almost never on anyone's budget, because it arrives as staff time rather than as an invoice.

What I actually build

Applications with real users and real permissions

Multiple kinds of user, each seeing different things, with an audit trail of who did what. This sounds routine and is where most of the difficulty lives, permissions are easy to get roughly right and hard to get exactly right, and "roughly right" is how one customer ends up seeing another customer's data.

Systems that talk to other systems

Payments, messaging, scheduling, accounting, whatever your business already runs on. The integration is rarely the hard part; deciding which system is authoritative for each piece of data is, and that decision is much cheaper to make before the build than to discover afterwards when two systems disagree about the same customer.

The work that only shows up later

Backups that have been restored rather than merely configured. Error reporting that tells you what broke before the customer does. Deployments that can be rolled back. Enough automated testing that a change doesn’t become an adventure. None of this is visible in a demo and all of it decides whether the thing is still maintainable in two years.

Why projects fail, in order of frequency

The scope was a wish, not a specification. If nobody wrote down what "done" means, the project can’t finish. It can only run out of money.
Nobody used it until the end. Software validated by demo rather than by someone doing their actual job with it always ships with the wrong priorities. The fix is putting real users in front of it early, when the feedback is still cheap to act on.
The data model was decided in an afternoon. Interfaces are straightforward to change later. How your data is structured isn’t, and almost every "we need to rebuild it" conversation traces back to a decision made in the first fortnight.
Everything was equally important. If everything is a priority, the schedule is fiction, and the parts that mattered get the same attention as the parts that didn’t.

How I work

I start with the narrowest version that’s genuinely useful and ship it to real users, rather than building the complete vision in private for six months. Not because the vision is wrong, but because the first contact with real use always changes it, and it is far cheaper for that to happen in month one than in month eight.

You get direct communication with the person writing the code. There’s no account manager relaying your requirements to someone you never speak to, which is the single biggest source of things being built slightly wrong. When something is harder than estimated, I say so at the time rather than at the deadline.

Fifteen products, not a slide deck

The portfolio is fifteen live products across gyms, bookkeeping, education, field services, retail search, parental controls and local trades. Different industries, different stacks, same job. They’re all reachable. You can click any of them and see the thing running, which is a deliberately higher bar than a case study nobody can check.

Several of them are the direct result of the build-versus-buy conversation above: they exist because the tool the business needed wasn’t for sale.

Related capabilities

If the project needs an assistant to operate it, that is AI integration services or MCP development. If it needs to be on a phone, React Native app development. And if what you really need is to fix how leads move through the system you already own rather than build something new, that is CRM customization, a much smaller project, and often the right one.

Custom software developer