A farmers’ market is a platform. That observation opens most good conversations about PlatformOps, because everyone has seen one work: shared stalls, shared footfall, one payment counter, posted hours — and every vendor still baking their own bread. The market operator builds nothing anyone sells; they run the shared machinery so that sellers can sell. Software companies build an internal equivalent for their engineers, and running it well — as a product, with service levels and honest retirements — is the discipline called PlatformOps. The expensive mistakes happen when a company builds the market before checking whether enough vendors show up. So before anyone writes a platform proposal, run the audit below. Twelve questions, scored honestly, will tell you whether you need a platform team, a thin shared setup, or simply a better wiki page.
PlatformOps readiness: what we are actually auditing
PlatformOps readiness: what we are actually auditing
The audit measures repetition and appetite, not ambition. Platforms pay for themselves by absorbing work that many teams would otherwise each do badly and separately. Where repetition is thin, a platform is overhead wearing a strategy document. Where it is thick, the platform becomes the best hire the company never made. Keep that lens while scoring; the questions only work when the answers are unflattering.
The twelve-point audit
- How many distinct teams would share this? Field guidance puts the floor at roughly three teams. Below that, shared tooling is usually a script with ambitions — and one person’s unpaid second job.
- Do the needs repeat, or merely rhyme? Three teams needing the identical deploy pipeline is repetition. Three teams needing three different things is a conversation, not a platform.
- Is there funding for two years? The common advice is blunt: do not start a platform without committed money for at least a couple of annual cycles. Platforms die of budget surprises, not technical debt.
- Who is the first customer? Name the team. If no team volunteers, the demand is theoretical, and theory makes expensive software.
- What is the one shared route you would run first? A platform worth building has an obvious golden path candidate — the task everyone repeats weekly. If you cannot name it, stop.
- Could a maintained wiki page do the job today? For small organisations, the honest answer is often yes. A single documented way to ship, with a named person behind it, beats an unmaintained portal every time.
- Is anyone already doing this work unofficially? There is usually a helpful engineer everyone emails first. That person is your founding platform team — or proof you only need to protect their time, not build a department.
- Do you know what you would stop doing? A platform that adds capability without retiring anything is a museum. Audit questions include the exits: which private scripts would be turned off once the shared route exists?
- Can adoption be earned rather than ordered? Platforms succeed when they are pulled — compelling enough that teams switch voluntarily. If your plan’s first draft contains the word “mandate”, the plan is not ready.
- Does each capability have a plausible owner? Every stall at the market has a caretaker. Every shared capability needs a name attached before it exists, not after it breaks.
- What promise would you publish? A service level — “a new service runs within an hour,” say — is what separates an operation from a hope. If no promise is worth making, the capability may not be worth building.
- Will you still measure it next quarter? Template coverage, time-to-first-deploy, the share of requests served without a human. Teams that track pull keep platforms honest; teams that stop measuring start decorating.
What the audit looks like on a real Tuesday
Consider a forty-person software company — call it Cobble Works — that builds a booking tool for independent shops. Three product squads, one data analyst, two contractors, and a support desk that has learned to fear deployments. Walk Cobble Works through three audit questions and watch the audit earn its keep. Question three (two years of funding?): no — the platform idea lives in one director’s enthusiasm and zero budget lines. Question one (three teams sharing?): yes, barely, if you count the contractors. Question five (the one shared route?): deploying the booking engine, which each squad does differently and everyone privately regrets. The verdict writes itself: fund nothing yet; document the deployment route; name the person behind it; revisit next quarter. Total cost, one afternoon and a sandwich. That is PlatformOps judgement doing its job — which, most of the time, is telling people they are not ready.
Flip the scenario. Five squads now, every onboarding turning into the same missing-database dance, and a finance director asking why engineers spend Fridays on plumbing. Now the twelve points start answering yes, the golden path has a name, and the first customer team is volunteering. The same audit, honestly scored twice, protects the company from both failure modes: building too early and building too late.
Scoring the audit without fooling yourself
Count the honest yeses. Ten or more: you likely have real repetition and appetite — start thin, with one route and one design-partner team, and let their experience write your marketing. Six to nine: build the shared foundation in miniature — the wiki page, one template, one named owner — and revisit in six months; you are not late. Five or fewer: spend the money elsewhere and feel no regret. A company that ships happily on modest shared tooling has not failed at PlatformOps; it has passed the audit’s real test, which is knowing the difference between a need and a mood. The market operator who opens three stalls for two vendors learns the same lesson at lower cost.
If the audit passes: your first month, in four moves
Passing teams should still start embarrassingly small. Write a one-page charter naming the platform’s first customer and its single golden path. Pick one design-partner team and sit with them weekly while they use the route. Publish one measurable promise — how long the standard deployment takes — and meet it for eight straight weeks before adding anything. Then, and only then, take the second request from the backlog. Every one of those moves is reversible; every one produces evidence; and together they turn a passing audit into a platform with a reputation instead of a launch date.
One warning deserves its own paragraph. Somewhere around month three, the platform effort will produce a dip — the old scripts still worked, the new route is half-documented, and everyone is irritable. That dip is normal and survivable, but only if leadership heard about it in advance. Teams that promise a smooth glide disappoint their sponsors; teams that forecast a climb with a valley in the middle usually get the patience they need.
PlatformOps habits that cost nothing yet
Even before any build decision, three zero-cost practices prepare the ground, and each fits inside a quiet Friday afternoon. First, write down how software actually ships today — not the process diagram, the truth. Second, name an owner for each shared thing you already have; clear ownership costs nothing until it is missing, and then it costs everything. Third, keep every future promise measurable, because the day a shared route exists, someone will ask how fast it is, and “depends” is not an answer. Companies that practise these three find any later platform decision arrives with evidence attached instead of anecdotes.
Small-business readers will recognise the pattern from commerce: shared infrastructure works when the vendors are many and the needs overlap — the argument our comparison of local and large marketplaces makes from the seller’s side. The same blueprint for local sellers going online starts, sensibly, with one product and one channel — which is exactly the thinnest-viable instinct the platform field preaches. For the full discipline, including lifecycle stages and reference architecture, the Ops Atlas PlatformOps entry collects what the practitioners agree on; and if your team does grow into selling online for real, our guide to local e-commerce for small businesses covers the commercial layer this audit deliberately ignores.
