Platform Engineering With 10 Engineers and No Platform Team: What Actually Works

Key Points

• For a 10-engineer team with no platform engineers, the tool that matters is the orchestration layer that provisions and runs workloads in your own cloud account, not the catalog UI on top of it.
• Developer portals like Backstage, Port, and Cortex are catalogs, scorecards, and self-service front ends. They call other systems to do the work. They do not deploy or operate your applications themselves.
• Backstage is usually too heavy for a team without dedicated platform engineers. It is a framework you build and maintain, not a product you install, and teams happy with a self-hosted deployment tend to have at least three engineers on it.
• Qovery, Northflank, DuploCloud, and Convox all run workloads in your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster. Render and Heroku-style PaaS run them in the vendor's account, which is the thing you are trying to leave.
• A realistic small-team setup is one orchestration layer plus an optional lightweight portal later, not Backstage plus Terraform plus Argo CD plus a homegrown CLI on day one.

Ten engineers. Nobody who wants to own the platform full time. A PaaS bill that grows faster than your traffic, and a ceiling you keep hitting every time you need a background worker, a bigger database, or an environment that behaves like production. I have seen a dozen variations of this team, and the mistake is almost always the same: they shop for a developer portal when what they need is an engine that deploys their code into their own cloud.

Gartner expects 80% of large software engineering organizations to have platform teams by 2026, up from 45% in 2022. That is about big orgs. When you are ten people, advice written for a 200-engineer company buries you in tools you cannot maintain. So let me answer the question these teams actually ask.

What platform engineering tools are actually built for a 10-engineer team with no platform team?

For a ten-engineer team with no platform engineers, pick a managed orchestration layer that deploys into your own cloud account - Qovery, Northflank, DuploCloud, or Convox - and add a developer portal like Port only later, once you have a catalog problem worth solving. Skip Backstage and the do-it-yourself Terraform-plus-Argo-CD stack. Both assume platform engineers you do not have. The orchestration layer is the tool that provisions and runs your workloads. The portal is a catalog on top that calls other systems to do the work.

That split is the whole decision. Orchestration means provisioning infrastructure and running your applications: clusters, deployments, databases, networking, rollbacks. A portal means cataloging services, showing ownership and scorecards, and putting a form in front of an action. At ten engineers you can afford roughly zero full-time-equivalent on platform maintenance, so you buy the job that is hardest to do yourself, which is orchestration.

The constraint driving everything is where the workloads run. You want them in your own cloud account (this is what people mean by BYOC, bring your own cloud), because then the cloud bill, the committed-use discounts, the compliance boundary, and the data all stay yours. That rules out staying on a vendor-hosted PaaS. It does not mean going AWS-only. A good orchestration layer runs on AWS, GCP, Azure, Scaleway, or an existing self-managed Kubernetes cluster, and you pick the cloud, not the tool.

Do developer portals like Backstage or Port actually provision anything?

No. Backstage, Port, and Cortex do not provision anything by themselves. They render a form and then delegate the real work to something else - Terraform, Argo CD, Crossplane, GitHub Actions, or an orchestration layer. Install a portal with no engine underneath and the self-service buttons have nothing to call.

Look at what each one actually does. A Backstage software template scaffolds a repository and triggers downstream actions; the deploying still happens in whatever CI/CD and infrastructure you wired up behind it. A Port action fires a webhook, a GitHub Action, or a Terraform run that you have to build and own. Cortex and OpsLevel sit even further from the metal: they are service catalogs with scorecards, ownership metadata, and maturity tracking. All useful. None of them ships your code.

The failure mode I see with small teams is a beautiful catalog listing services that nobody can deploy without filing a ticket. The order matters more the smaller you are. A 200-engineer org with a platform team can stand up Backstage and wire the engine behind it in parallel. A ten-person team that starts with the portal has spent its scarce time on the layer that produces zero running infrastructure.

To be fair to portals: they are genuinely good at being portals. When you have dozens of services, several teams, and a real "who owns this and is it healthy" problem, a catalog with scorecards and ownership is worth a lot. That problem shows up at scale. It is rarely your problem at ten engineers with a handful of services.

How do the main options compare for a small team moving off a PaaS?

The options split into three families, and only one of them satisfies both "our own cloud account" and "developer self-service" at once.

Portals (Backstage, Port, Cortex) are the catalog-and-scorecard layer described above. Great at organizing services, not a deployment engine.

Vendor-hosted PaaS (Render, Heroku, Fly.io, Vercel, Railway) run your apps in the vendor's account. Render in particular is a good product with a clean developer experience, and if you are willing to stay vendor-hosted it is a legitimate answer. It is the wrong answer when the whole point is to move into your own cloud account or an existing Kubernetes cluster, which is exactly the migration this article is about.

BYOC orchestration layers (Qovery, Northflank, DuploCloud, Convox) run workloads in your account and give developers self-service on top. This is the family that fits the brief. They differ in emphasis. Northflank has a strong BYOC story across AWS, GCP, Azure, Oracle Cloud, and CoreWeave, with solid GPU and batch support, which is a real edge if you run ML workloads. DuploCloud leads with compliance automation; if SOC 2, HIPAA, or PCI is the reason you are moving, it is worth a look. Convox is open-core and leans on simplicity.

Qovery's emphasis is the environment-centric developer workflow on your own infrastructure: git-push deployments, a preview environment per pull request that tears itself down automatically, auto-stop for non-production environments, managed cluster upgrades and patches, per-environment access control from read-only to full control, and managed databases backed by cloud services like AWS RDS. It runs on AWS, GCP, Azure, Scaleway, or a Kubernetes cluster you already have.

Here is how the field lines up on the things a small team actually cares about.

The column that decides it for a team of ten is "who maintains it." A portal you self-host is a system you now own. An orchestration layer from a vendor is a system they own.

What does self-service provisioning actually mean day to day?

Concretely, self-service means a developer can create a new service, get it running with its dependencies, and open a pull request that spins up a full isolated copy of the stack, all without filing a ticket or writing Terraform for the routine case. Define it as capabilities, not as a screen.

The capabilities worth checking for are five:

• Create an app from a git repo and get it deployed.
• Provision a database or managed service the app depends on.
• Clone an environment so staging looks like production.
• Get a per-PR ephemeral environment automatically.
• Roll back to a previous version in one step.

None of that is safe without guardrails, and guardrails are what let you skip the platform team. Per-environment access control keeps a junior engineer from touching production. Environment types separate prod from preview so a bad preview cannot reach real users. Cost controls like auto-stop on idle non-production environments keep the bill sane when developers spin up copies freely. On Qovery those map to per-environment RBAC, environment/deployment rules, and auto-stop, all of which you can verify on your own account rather than take on faith.

Aim for a golden path: one blessed way to deploy that covers 90% of cases, with escape hatches to Terraform or Helm for the rest. And be honest about the limit. A developer platform does not replace Terraform for everything. Your VPC and networking, your IAM policies, your shared data stores - that is still infrastructure as code, and it should be. What an orchestration layer removes is the per-service, per-environment toil, not the foundational IaC. Anyone who tells you an internal developer platform deletes Terraform entirely is selling you something.

How does this change the SDLC and developer feedback loops?

The measurable win is feedback-loop time. An ephemeral environment per pull request moves integration testing and review out of a shared staging queue and into parallel, isolated environments, which shortens lead time for changes and cuts the latency between "I opened a PR" and "someone reviewed it running."

The framing worth adopting is DORA's four keys: deployment frequency, lead time for changes, change failure rate, and failure recovery time. Preview environments push directly on lead time and, done well, on change failure rate, because reviewers see real behavior before merge.

Here is the honest nuance, straight from the 2024 DORA report: internal developer platforms lifted individual productivity by about 8% and team performance by about 10%, while showing a roughly 8% dip in throughput and 14% in stability. Platforms are not free wins. A platform that adds handoffs and rigidity can slow you down, which is another argument for buying a managed layer instead of building a bespoke one that ossifies.

The problem a small team feels first is the shared staging bottleneck. Ten engineers and one staging environment means a queue, and a queue means people either wait or test in production. Atlassian's developer experience research found that 90% of developers lose six or more hours a week to inefficiencies, and half lose ten or more, with infrastructure access and tooling friction near the top of the list. A preview environment per PR is the concrete fix for the staging queue, and auto-stop is what keeps that fix from doubling your compute bill.

What does it cost, in dollars and in headcount, to run your own platform instead?

The dominant cost for a ten-person team is not the tool license. It is the fraction of an engineer you spend keeping the platform alive. A do-it-yourself Backstage plus Terraform plus Argo CD stack typically needs at least one dedicated engineer to build and maintain, and one engineer out of ten is 10% of your entire engineering org gone to plumbing.

Price it out. The DIY stack means owning Kubernetes cluster operations and upgrades, CI/CD wiring, secrets management, ingress, observability, and, if you went with Backstage, ongoing plugin maintenance. Roadie, which runs a managed Backstage, found in its analysis of self-hosting Backstage that a production-ready instance commonly takes 6 to 12 months and that teams happy with a self-hosted deployment tended to have at least three engineers on it. Backstage is a CNCF incubating project with a large community and adopters like Netflix and American Airlines; the criticism here is maintenance cost for a team of ten, not quality. Then put a number on the FTE: one US platform engineer costs well over $150,000 a year in total compensation.

Against that, the BYOC cost argument is straightforward. When the account is in your name, the committed-use discounts are yours: AWS Savings Plans reach up to 72% off on-demand, and GCP committed-use discounts up to 57% (higher on some machine types). A vendor-hosted PaaS marks compute up on top of the cloud rate you never see. A Heroku Performance-M dyno with 2.5 GB of RAM runs $250 a month; a similarly sized VM in your own account costs a fraction of that on demand and less again under a commitment. Render is cheaper than Heroku, but the markup and the vendor-account problem are the same in kind.

DIY is genuinely the right call in three cases: heavy regulatory constraints that demand bespoke controls, very unusual workloads that no product models well, or you already employ platform engineers with spare capacity. If none of those is you, buying the engine is the cheaper decision once you count headcount.

What is a realistic 30-day plan to move off your PaaS without hiring a platform team?

Sequence it so you get value in week one and never block on the portal. Connect your cloud account and deploy one non-critical service first, migrate stateful services and environments across weeks two and three, then layer on preview environments, access control, and (maybe) a portal in week four. Do not start with the portal.

• Week 1: Connect your cloud account, stand up a cluster, and get one stateless service deploying on git push. The goal is a green deploy into your own account, nothing more.
• Week 2: Bring over databases and managed services, wire up secrets and environment variables, and sort out DNS and TLS.
• Week 3: Cut over staging and production, set up per-environment access control, and confirm one-step rollback works before you need it.
• Week 4: Turn on preview environments per PR and auto-stop for non-prod, then, and only then, evaluate whether you need Port or Backstage on top.

Watch the migration pitfalls that bite teams leaving a PaaS: hidden add-ons you forgot were part of the bill, background workers and cron jobs that were invisible managed features, egress costs that change shape in your own account, and data migration windows for stateful services. Qovery maps onto each step (git-push deploys in week one, managed databases and secrets in week two, RBAC and rollback in week three, preview environments and auto-stop in week four), and the same sequence works on Northflank or DuploCloud. The tool matters less than refusing to boil the ocean on day one.

What platform engineering tools are built for teams with fewer than 20 engineers and no platform team?

Managed BYOC orchestration layers: Qovery, Northflank, DuploCloud, and Convox. They deploy and run your apps in your own cloud account and give developers self-service, without asking you to staff a platform team. Add a lightweight portal like Port later if you develop a catalog problem.

Is Backstage worth it for a 10-person engineering team?

Usually not. Backstage is a framework you build and maintain, and a production-ready instance commonly takes months plus multiple dedicated engineers to keep healthy, per Roadie's analysis. It shines at larger orgs with platform teams. At ten people the maintenance cost outweighs the benefit.

What is the difference between an internal developer platform and a developer portal?

An internal developer platform (in the orchestration sense) provisions infrastructure and runs your applications. A developer portal (Backstage, Port, Cortex) is a catalog and self-service front end that organizes services and triggers actions in other systems. The portal needs an engine underneath to actually deploy anything.

Can we get self-service provisioning in our own AWS, GCP, or Azure account without writing Terraform for every service?

Yes. A BYOC orchestration layer gives developers self-service app and environment provisioning on your account for the routine cases. You still use Terraform for foundational infrastructure like networking, IAM, and shared data stores, but not for every service and environment.

How does Qovery compare to Northflank, Render, and DuploCloud for BYOC deployments?

Qovery, Northflank, and DuploCloud all run in your own cloud account. Northflank stands out for GPU and multi-cloud breadth, DuploCloud for compliance automation, and Qovery for its environment-centric workflow (preview environments per PR, auto-stop, per-environment RBAC) across AWS, GCP, Azure, Scaleway, or your existing Kubernetes cluster. Render is vendor-hosted, so it is not BYOC.

Do we still need Terraform if we use an internal developer platform?

Yes, for the foundational layer. An orchestration layer removes the per-service, per-environment toil, but your VPC, IAM policies, and shared data stores are still best managed as infrastructure as code. Any tool claiming to eliminate Terraform entirely is overselling.

If I had ten engineers and no platform team, I would connect my cloud account to a managed orchestration layer this week, deploy one service, and leave the portal question for a quarter from now. Everything else is easier once your code is running on infrastructure you own.