Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
SaaS & Product

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.

  1. Multi-tenant data isolation, done properly, from the start
  2. Configuration where you previously hard-coded your own rules
  3. Self-serve onboarding, because you cannot hand-hold every customer
  4. Billing, dunning and plan management
  5. 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?

Typically 1.5–3× what the internal tool cost, and that is the software alone — before support, sales and onboarding.

Can we do it gradually?

Yes, and it is the sensible route: one friendly external customer on a manual arrangement, then a second, and only then build the self-serve machinery.

Will our internal version have to change?

Some. Multi-tenancy and configuration usually touch the data model, which is why building for one tenant properly first is still the right call — you refactor with knowledge instead of guessing.

Do you help with this transition?

Yes, and it is one of our favourite kinds of project — the requirements are unusually well understood, because a real business has been using the thing for years.

Keep reading

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.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

SaaS DevelopmentCustom Software Development