- Get It Dunn
- Posts
- You Don't Decide to Build Software
You Don't Decide to Build Software
Three software companies, and not one of them started as an idea.
September 27, 2026
Read Time: 8 minutes
Building a really good consulting deck used to take us ten hours or more.
Not the audit. Not the interviews or the workflow mapping. Just the deck. Laying it out properly, building the diagrams and the charts, getting the story to actually hold together from the first slide to the last.
Ten hours, every single time, on the part of the job the client never sees us do.
That is not a product idea. That is a bottleneck, and it was the biggest one in our business.
Consultix came out of that. Not out of a whiteboard session about what the market needs. Out of being annoyed at the same ten hours, over and over, until building something to kill it became the obvious move.
I now own three software businesses and every one of them arrived the same way. Which is worth writing about, because almost everybody I speak to is trying to do it backwards.
Productisation Is Not an Idea You Have
The version most people run is this. They are three engagements in, they are tired of custom work, and they decide they should build a platform.
Then six months goes into something nobody wants, because at engagement three you have not seen enough to know what is actually the same across businesses and what only looked the same.
The real sequence is the other way around. You do the work by hand, a lot of times, and at some point the repetition stops feeling like inefficiency and starts looking like a specification.
By the time we built Consultix we had done thirty or so audits. At that point you could already get a model to help with parts of it. Finding solutions, identifying bottlenecks, that sort of thing. What no model could do was build a proper consulting deck with the diagrams, the charts, the layout and the storytelling all holding together. That gap was only visible because we had spent ten hours filling it thirty times.
You cannot see the product until you have been the product for a while.
Thirty Is the Number
I get asked how many engagements it takes and I think thirty is genuinely the answer.
By ten you will already know most of it. You will have a decent feel for what businesses of a certain size keep getting wrong.
By thirty you have undeniable proof. Not a hunch, not a pattern you think you might be seeing. The same core issues turning up again and again with different company names on the front.
And here is the part that makes this easier than it sounds. You do not need a special process for capturing it.
You are already recording everything. The interviews, the workflow maps, the bottlenecks, the bits that never got fixed. It is all in your audit files because that is the job. You are not being asked to run a research project on the side.
There are only ever going to be ten or twenty things. That is the whole list. Once you have done enough of these, the same ten or twenty come up so relentlessly that you could not miss them if you tried.
So the answer to "what should I be recording from engagement one" is nothing extra. Just do thirty of them and pay attention.
Side Guide Came Out of a Time Zone
The second one is a different flavour of the same mechanic.
I am in the Gulf. A lot of the consultants I work with are in North America, working on their businesses in their evenings, which is the middle of my night.
So they would hit something, ask a question, and wait. Sometimes a full day for an answer that would have taken me ninety seconds if I had been awake.
That was my problem before it was anybody else's. And the second part of it was that the answer they usually needed was not new information. It was my existing material applied to their specific situation, which is a translation job rather than a thinking job.
Side Guide came out of that. An AI version of me inside the community, so people get fast, accurate answers whenever they happen to be working rather than whenever I happen to be conscious.
It is now its own software business, serving community owners who have exactly the same problem I did.
Again, not an idea. A thing that was annoying me, solved, and then it turned out several thousand other people had the same annoyance.
You Are Not Productising the Offer
This is the bit I think almost everyone misunderstands, and it changes the risk completely.
When I say productise, I do not mean change what you sell or what you charge. The client is buying the same outcome at the same price. Nothing on the invoice moves.
What changes is delivery.
Instead of building the same custom thing again in Claude, or wiring it up again in n8n or Make for the fourth time this quarter, you are deploying your own solution. Same fee, dramatically less labour to earn it.
That is arbitrage, and it is the entire point. Your margin goes up because your delivery cost goes down, not because you found a way to charge more.
Which also means the downside is much smaller than people assume. You are not betting the business on a new market. You are building a tool for work you are already being paid to do. Worst case, it makes your own delivery faster and nobody else ever touches it.
That is a very different risk profile to "I am going to build a SaaS."
Do Not Do This Without a Technical Partner
Now the honest part, because this is where it goes wrong.
Alex Hormozi has talked publicly about a software company of his that failed, and his read on why is the one that stuck with me. He paid a development shop a great deal of money to build it. They were competent. They just had no skin in the game.
So when something broke on a Saturday, nobody cared. It got fixed on Monday, because Monday is when they worked. That gap, repeated, is what killed it.
Software is not a project you commission. It is a thing that breaks at inconvenient times forever, and somebody has to want it to work as much as you do.
So with anything software, you need one of two things. Either you are deeply technical yourself, or you have a technical co-founder with real ownership. Paying a contractor to build your platform and hoping is not a third option, however good the quote looks.
That is the honest cost of this route and it is why route seven sits at the end of the list rather than the beginning.
Does the Consulting Stop?
Totally personal, and I do not think there is a right answer.
It depends whether you enjoy the work, whether you want to keep expanding into new industries, whether you would rather be in rooms with owners or in a product.
I have kept doing it, because the audits are where the next pattern comes from. Three software companies came out of client work, and I do not think the fourth one appears if I stop.
The Third One
Which brings me to what I am actually building at the moment.
It has come out of the local business side. Hundreds of local business clients over the course of my career, a lot of audits, and the same bottlenecks appearing so often that they stopped being individual problems and started being a category.
So we have built a platform that solves several of them in a couple of clicks. Real, measurable improvement for the business, without anybody having to wire anything together from scratch.
We are releasing it shortly, and not just for people to use. For people to resell.
If you are working with local businesses, that is worth paying attention to over the next few weeks. I will go into it properly when it is ready.
The Real Point
Nobody sits down and invents a useful piece of software. They get irritated by the same ten hours thirty times and eventually do something about it.
Do the work by hand. Thirty engagements, and you will have undeniable proof of the ten or twenty things every business in your niche gets wrong.
Then productise the delivery rather than the offer, find someone technical who actually owns a piece of it, and keep taking clients so the next pattern has somewhere to come from.
That is how you end up with software. Not by deciding to.
See you next week,
– Andrew

How did you like today's newsletter? |