Backstage vs Port for a Small Cloud Consultancy

Backstage's appeal is real: no subscription fee, full control over the source, and a plugin ecosystem that covers most standard infrastructure. For a consultancy of three or four engineers, though, the true cost isn't the software, it's the person who has to become the de facto Backstage administrator on top of their billable work. That role doesn't scale down gracefully the way it might at a larger company with a dedicated platform hire.

Port removes that administrator role by taking on hosting, upgrades, and plugin compatibility as the vendor's job. What you pay for instead is a subscription that scales with your team size, which for a small shop is usually easier to price into client rates than an unpredictable amount of internal engineering time. Median DevOps spend at private B2B SaaS companies runs around 4% of ARR, and a useful gut check for a small consultancy is whether your internal tooling spend, subscription plus the hours it still takes to run, sits anywhere near that line relative to your own revenue, or well past it¹.

If your consultancy's whole value proposition is deep platform engineering expertise, running Backstage yourself can double as a credibility signal and a training ground, since it's the same tool many of your enterprise clients already use internally. In that case, the maintenance burden is arguably part of the product you're selling: the expertise your team builds running it becomes something you can bill clients to help them run their own instance.

That argument doesn't hold for a consultancy whose value is elsewhere, in cloud migrations, DevOps process work, or security hardening, where the internal portal is purely a back-office tool and the maintenance time is pure overhead. Be honest with yourself about which category you're actually in before letting the first argument justify a decision the second category doesn't support.

Ask whether losing your most senior engineer for a week, unexpectedly, to fix a broken Backstage upgrade would meaningfully hurt a client deliverable that week. If the honest answer is yes, that risk alone is a reason to prefer Port's hosted model, where an outage or bug is the vendor's incident to resolve, not yours.

Ask the same question about vulnerability patching specifically, since it's the maintenance task most likely to arrive without warning. A critical vulnerability disclosed in a dependency your self-hosted instance relies on doesn't wait for a convenient week between client engagements, and patching it promptly is exactly the kind of unscheduled work a small team feels hardest.

Ask these questions before choosing a tool:

• Would losing your most senior engineer for a week to a broken Backstage upgrade hurt a client deliverable that week?
• Who patches vulnerabilities in a self-hosted portal when one lands in the middle of a client engagement?
• Does your internal tooling spend, subscription plus the hours it takes to run, sit near the median DevOps spend line or well past it?
• Does running Backstage yourself double as a credibility signal or training ground that your clients would actually value?

If you do choose Port, resist the urge to model everything on day one. Start with the client engagements currently active, plus whatever internal services your own consultancy depends on to operate, and treat everything else as backlog. A small team that tries to fully populate a catalog before using it for real work tends to lose momentum halfway through and never finishes, which leaves you paying for a tool nobody actually opens. Consultancies that deliver infrastructure changes for clients on a standardized, catalog-aware path also tend to post a higher deployment frequency, landing in DORA's faster-shipping clusters rather than the slowest one, where months can pass between releases, and that shipping speed is a real selling point when a prospective client asks how fast you move².

If you choose to self-host Backstage instead, apply the same discipline to plugins: install only what you need for your current client mix, and resist adding a plugin for a capability you might need someday. Every additional plugin is one more thing that can break on the next upgrade, and a small team feels that cost more acutely than a larger one would.

The most common failure at this scale isn't picking the wrong tool, it's picking either tool and running out of momentum a third of the way through. A three-person shop signs up for Port, models their two biggest active clients in an afternoon of enthusiasm, then the next fire drill hits and the catalog sits untouched for two months. When a new client engagement starts, nobody remembers to add it, because adding to the catalog was never actually built into the engagement kickoff, it was just a thing that happened once.

The fix is smaller than it sounds: put "add this engagement to the catalog" as a literal checklist item in whatever kickoff process you already run for a new client, right next to setting up their repo access and their invoicing. A half-finished catalog that covers two clients out of eight isn't a stepping stone toward a complete one, it's a trap that makes the tool look unreliable to the next person who checks it and finds nothing there, which is worse for adoption than never having started.