A few weeks back I had dinner with a friend who runs a software company. One product. Good product. A small team that knows it inside out. His biggest challenge these days is figuring out how to allocate the marketing budget.
He looked at what I do at 3S Coding โ different client every few months, different industry, different problem, sometimes a different stack โ and he asked a fair question. "Why? Why keep doing this to yourself? Build one solid product, push sales, let the money compound. Custom dev is a headache factory."
He wasn't being dismissive. He made a real argument. I couldn't disagree with the math.
The case for doing it the easy way
Products scale. Custom development does not โ at least not in the same way. A product company can acquire a thousand customers without adding a thousand times the operational complexity. One codebase, one set of bugs, one backlog. The feedback loop tightens over time. The team gets faster at the same thing. Margins improve.
Custom software works the opposite way. Every new client is a new universe. New domain, new constraints, new stakeholders with strong opinions about why the button should be a different color. You develop expertise, absolutely โ but you're rebuilding context from scratch every engagement. The work doesn't simplify. It diversifies.
From a pure business model perspective, my friend is making the obvious point. Products are the sane choice. Fewer surprises, more predictable revenue, a team that deepens rather than spreads.
The honest answer
I told him: adrenaline.
I get bored fast. That is the actual reason. Not a strategy โ a character trait, and not one I'd necessarily recommend to a business consultant. But custom work keeps throwing things at you that you have never seen before, and that is not a bug in how I've built the business. It is the reason I still show up at full attention instead of running on autopilot.
Every project is uncharted territory. New industry, new rules, sometimes an entirely new stack. There are surprises โ technical ones, human ones, scope ones at 11pm the night before a demo. It is not efficient. It keeps me sharp.
The product route would work. I would probably be fine. I would also be bored inside of a year, and a bored founder is far more dangerous to a business than a complicated one.
What the work actually feels like
There are two moments in custom software work that I have never been able to replicate anywhere else.
The first is the delivery. When you hand over something that did not exist three months ago โ something the client described in fragments, in contradictions, in half-formed wishful thinking โ and they see it working for the first time. The look on their face when the system does exactly what they were told a system cannot do for a company their size. That does not get old.
The second is smaller and harder to explain to people outside the craft. The moment a build comes back clean. Tests pass, no errors, the thing works the way you said it would work when you were pitching it and were not entirely sure you could pull it off. There is a specific physical sensation in that โ something in the gut โ that I have not found anywhere else.
Both require new problems. Neither happens on the tenth iteration of a feature you shipped two years ago.
The work is not for everyone. Neither is the boredom that comes with doing the same thing long enough to stop caring about it.
My friend went back to his product and his marketing budget. I went back to a new project brief. We are both doing exactly what we should be doing โ and that is the only part of this conversation that matters.
The fuel matters. Running out of it is a bigger problem than the operational complexity I sign up for with every new client. If your work stopped feeling like a challenge, the model might not be the issue. The fit might be.
