ยท 6 min read
The SME that became a software company by accident.
Most owner-led SMEs I get called into never decided to become software companies. They became one the day a single internal system, built by two people and an agency, became the thing the business could not run a day without. That is the accident: software risk without software leadership. The fix is not to turn into a tech company. It is to give the software one owner and put an adult in the room with the supplier.
How does an SME become a software company without deciding to?
In small, reasonable steps. A spreadsheet becomes a tool. The tool gets a database. An agency is hired for the parts nobody internal can build. One or two self-taught people, usually the ones who started the spreadsheet, end up holding the whole thing in their heads. Five years on, the order flow, the pricing engine, the customer portal, or the plant scheduling runs on custom code, and a company that sells furniture, insurance, or logistics is quietly a software company that never hired anyone to lead software. Nobody chose this. Every individual decision was correct. The sum is a business-critical system with no owner, no roadmap, and a supplier nobody in the building can grade.
The shape is remarkably consistent. In Belgium and the Netherlands I see it most in profitable companies with 40 to 400 staff, often family-owned or owner-led, in a sector that has nothing to do with software: manufacturing, distribution, professional services, a wholesaler with a portal. The revenue is real and the margins are fine. What is missing is anyone whose job is to look at the software as a system rather than a series of tickets.
What it actually means
It means you carry software risk without software leadership, and that risk shows up in two places. The first is concentration: the system that runs the business lives in one or two people's heads, so their notice period is now your largest operational exposure and nobody has written down why anything is the way it is. The second is oversight: you cannot tell whether the agency invoice is fair, because nobody internal can read the work well enough to accept it or reject it. You are paying for capacity you cannot judge and depending on knowledge you do not hold.
The pattern repeats across engagements. In one case I wrote up, a customer portal had been "three months away" for 18 months, the agency invoiced against a contract nobody could technically assess, and the internal lead spent his weeks reviewing work he had no authority to reject. The blocker was not code. It was that no one owned the decisions, and no one had the mandate to say no.
What to do about it
Start by naming it out loud. In the part of the business that matters, you are a software company now, and the org chart should admit it. Then three moves, in order.
- Give the system one owner with the mandate to say no. Often that person already exists: the self-taught lead who built the thing and understands both the code and the customers. Promote them into the role, with the title, the pay step, and the authority to reject a supplier's work. A capable insider with a mandate beats an outside hire who has to learn the business first.
- Put the supplier under adult supervision. Someone has to read the contract and the codebase in the same week, decide whether the blocker is code or decisions the company never made, and rewrite the agency scope to pay for outcomes instead of named profiles. This is the work, and it is the fastest money you will find.
- Get a roadmap the owner can read. Not a backlog. A short list of what the software must do in the next two quarters, what it must stop doing, and what it costs. Once that exists, most of the panic goes away, because the risk becomes a plan.
None of this requires becoming a tech company. It requires a few days a month of oversight from someone who has run software before, which is exactly the shape of work the SME practice is built for. Most owner-led companies in this position are one promotion and one renegotiation away from unblocking themselves.
When this is fine, and when not to overcorrect
Not every SME with software has this problem. If a single competent person owns the system, the knowledge is written down, and the supplier is graded against outcomes, you are in good shape and you do not need me. If your software is a public website and an off-the-shelf ERP you do not modify, you are not a software company and should not pretend to be one.
The failure mode in the other direction is just as expensive. An owner who has just realised software is critical will sometimes overcorrect and hire a VP of Engineering, stand up a platform team, and start a rebuild for a problem that needed one owner and a better contract. Right-sizing cuts both ways: the same discipline that says when to shrink an over-hired team says do not build a software organisation you do not need. Match the leadership to the risk, not to the fashion.
Frequently asked
How does a company become a software company by accident?
In small, reasonable steps that nobody costed as a strategy. A spreadsheet becomes a tool, the tool gets a database, an agency is hired for the parts nobody internal can build, and one or two self-taught people end up holding the whole thing in their heads. Five years on, the order flow, the pricing, the customer portal, or the plant scheduling runs on custom code, and a company that sells furniture, insurance, or logistics is quietly a software company that never hired anyone to lead software. Every single decision was correct. The sum is a business-critical system with no owner, no roadmap, and a supplier nobody in the building can grade.
Does an SME that depends on custom software need a CTO?
Usually it needs one owner and adult supervision of the supplier, not a full-time CTO. If a single system is business-critical, one named person should own its roadmap and have the mandate to reject an agency's work, and that person often already exists inside as the lead who built it. A few days a month of fractional oversight is enough to grade the contract, force the open decisions, and back the insider. A full-time hire is right only when the software is the product and the roadmap is large enough to keep a leader busy.
What are the signs your business has become a software company?
Two signs settle it. First, a system the business cannot run a day without lives in one or two people's heads, so their notice period is your biggest operational risk. Second, you cannot tell whether the agency invoice is fair, because nobody in the building can read the work well enough to accept or reject it. If both are true, you are already a software company in the part that matters, and the only question left is who owns it.
Does this call for a fractional CTO or an interim CTO?
Most of the time it does not. A few days a month of fractional oversight, described above, is enough. An interim CTO, full authority for a defined period with an exit planned from day one, fits a narrower case: the internal lead who built the system is about to leave, delivery has already stopped, or a restructuring is coming and the board wants it run by someone without history in the building. That is the same seat in Belgium and in the Netherlands, taken for as long as the situation needs it and not a week longer.
Written from patterns I've seen across engagements. If any of it sounds too specific to be general, that's why.