How a Small Business Becomes a Platform
Last updated:
The path that actually happens
Very few software businesses started as software businesses. Most started as an operating company that built something for itself, discovered other people wanted it, and gradually turned the tool into a product.
That path has four stages, and the transition between each is a genuine business decision rather than a technical one.
Stage 1: the internal tool
Built for your own staff to solve your own problem. It works, it is ugly, it assumes a great deal of context and it is enormously valuable exactly because it fits your business precisely.
The mistake at this stage is building it as if it might become a product one day. Generalising software before you have one real user is how you get an abstraction that fits nobody. Build it specifically. Generalise later, if ever.
Stage 2: customers touch it
You expose a slice to customers — order status, a booking form, a document portal. This is the highest-return step for most businesses and where most should stop.
It changes your obligations: uptime, design, support, security. The engineering cost of the same functionality roughly doubles when a customer can see it, and the operational cost rises too because confused customers contact you.
- Self-serve status, so people stop phoning to ask
- Document exchange, which removes the email attachment problem
- Booking or ordering, if your process is standard enough
- A simple account area — history, invoices, details
Stage 3: suppliers and partners
Now people outside your company do work inside your system: suppliers updating lead times, subcontractors submitting timesheets, partners entering their own data.
The hard part here is not technical, it is incentive. External parties will only use your system if it is easier than what they do now. Portals that make life better for you and worse for a supplier get quietly ignored, and you end up maintaining a system nobody outside your walls logs into.
Every failed supplier portal we have been asked to rescue had the same root cause: it was designed around the buyer's convenience and gave the supplier one more login to remember.
Stage 4: it becomes a product
Someone in your industry asks whether they can use your system. That question, unprompted and repeated, is the only reliable signal that stage four is real.
What changes is almost everything except the code: multi-tenancy, per-customer configuration, onboarding, support, billing, a roadmap serving strangers, and a sales motion your operating business has never needed. The software is perhaps 30% of the work.
- Multi-tenant data isolation, done properly, from the start
- Configuration where you previously hard-coded your own rules
- Self-serve onboarding, because you cannot hand-hold every customer
- Billing, dunning and plan management
- A support function, which is a hiring decision more than a technical one
Should you?
Usually not, and that is not a discouraging answer. A tool that gives your operating business an advantage is worth more than a small software product that distracts it — and the operating business is often the more profitable of the two.
The cases where it is worth it: a genuinely underserved niche you understand from the inside, repeated unprompted demand, and enough capital to fund two years of a product business that will not pay for itself quickly. If two of those three are missing, licensing the idea or staying at stage two is the better trade.
Frequently asked questions
How much does turning an internal tool into a product cost?
Can we do it gradually?
Will our internal version have to change?
Do you help with this transition?
Building a product rather than a project?
We build first versions that an in-house team can take over. Tell us where you are and we will tell you what the first three months should contain.
Related services
What we build for problems like this one