Platform Engineering for Mid-Size SaaS: An Internal Developer Platform Without the Kubernetes Complexity

Most writing about platform engineering assumes you have a platform team of ten and a Kubernetes cluster already humming in production. If you run a SaaS with 5-20 engineers, that literature is worse than useless: it convinces you that platform engineering for a small team means either hiring specialists you cannot afford or skipping the discipline entirely. Both conclusions are wrong.

An internal developer platform (IDP) at small scale is not a GUI, a service catalog, or an API. It is a set of conventions, a handful of Makefile targets, a deployment pipeline template, and documented runbooks that make the golden path the easy path. Teams that make these investments see the same benefits the big players advertise, such as self-service environments, fast onboarding, and fewer "how do I deploy this?" interruptions, without operating a container orchestrator they do not need.

This post covers what an IDP actually is at small scale, the three highest-ROI investments, how Kamal and Docker Compose can serve as the infrastructure layer instead of Kubernetes, and the point at which a real platform team pays for itself.

What Platform Engineering Means for a Small Team

Strip away the vendor landscape and platform engineering is one idea: reduce the cognitive load on product engineers by making infrastructure decisions once, centrally, and encoding them so nobody has to re-decide them per project.

At a 200-engineer company, that encoding takes the form of a developer portal like Backstage, a Kubernetes platform, and a team that operates both. At a 10-engineer company, the same idea looks like this:

• A Makefile (or justfile) with identical targets in every repository: make setup, make dev, make test, make deploy
• One documented way to create a new service, with a template repository that already contains CI, linting, logging, and deployment configuration
• Runbooks stored next to the code they describe, so the person on call at 2 a.m. is reading instructions, not reverse-engineering intent
• A single deployment tool with a single configuration pattern across all apps

Notice what is absent: no GUI, no internal API, no dedicated headcount. The platform is a set of agreements plus the automation that enforces them. That is not a lesser version of platform engineering. It is the version that fits the scale.

The test for whether you have a platform is simple: can a new engineer clone a repository they have never seen and have it running locally within 30 minutes, without asking anyone? Can any engineer deploy any service without a senior colleague reviewing the mechanics? If yes, you have an IDP, whatever it is built from.

The Three Highest-ROI Platform Investments for a Small Team

You cannot do everything, and you should not try. Three investments consistently return more than they cost for teams in the 5-20 engineer range.

1. Standardized local development setup

Divergent local setups are the silent tax on small teams. One engineer runs PHP natively, another uses Docker, a third has a broken Node version manager. Every difference eventually becomes a "works on my machine" bug or an afternoon lost to environment debugging.

The fix is one docker-compose.yaml per repository plus a make setup target that goes from fresh clone to running application: copies the env template, builds containers, installs dependencies, runs migrations, seeds data. The target must be idempotent, so running it twice never breaks anything.

The discipline that keeps this alive: when setup breaks for anyone, fixing the setup script is the highest-priority task, not a workaround note in Slack. The moment the documented path stops working, people build private workarounds and the platform decays.

2. A deployment pipeline template

The second investment is a CI/CD pipeline defined once and copied (or referenced as a reusable workflow) into every repository. Build, test, lint, static analysis, image build, deploy. Same stages, same naming, same secrets pattern.

The payoff is symmetry: any engineer can debug any pipeline because it is the same pipeline. When you add a stage centrally, such as a dependency audit or a link-checking gate for content, every service inherits it in one pull request instead of ten inconsistent ones.

A pipeline template also forces the question every team should answer once, not per project: what must be true before code reaches production? Encoding the answer in a template turns a policy debate into infrastructure.

3. A secrets rotation workflow

Secrets management is where small teams accumulate silent risk. The database password set two years ago, the API key in three CI configurations and one engineer's shell profile, the SMTP credential nobody dares touch. None of it hurts until the day it does, either through a leak or through the paralysis of being unable to rotate anything without fear.

You do not need a Vault cluster. You need a documented, rehearsed workflow: an inventory of which secrets exist and where they are injected, one command or short runbook per secret to rotate it, and a calendar reminder for rotation. Kamal's secrets handling and encrypted env patterns like SOPS cover the mechanics for a team this size. We covered the details in secrets rotation without a Vault cluster.

The rotation workflow earns its place in the top three because it is the investment nobody makes until an incident forces it, at which point it costs ten times more under pressure.

Kamal and Docker Compose Instead of Kubernetes

The reflex that keeps small teams from platform engineering is the belief that an IDP requires Kubernetes underneath. It does not. The infrastructure layer of a small-scale platform needs to do four things: run containers, deploy them with zero downtime, inject secrets, and roll back. Kamal does all four against plain servers, and Docker Compose covers local development with the same container images.

The pairing works because it keeps one mental model from laptop to production. The same Dockerfile builds the image an engineer runs locally via Compose and the image Kamal ships to the server. There is no translation step between "how it runs on my machine" and "how it runs in production," which is precisely the gap where deployment knowledge becomes tribal.

What you give up against Kubernetes is horizontal autoscaling, sophisticated scheduling, and the ecosystem of operators. What you gain is an infrastructure layer that one engineer can understand completely in a week. For a typical B2B SaaS doing thousands of requests per minute on a handful of servers, that trade is heavily in your favor. We have written a detailed comparison in Kamal vs Kubernetes for indie SaaS, and if you prefer a UI-driven alternative, Coolify and Dokploy are worth a look.

The platform framing changes how you configure these tools. Instead of each app having a hand-crafted deploy.yml, you define one canonical Kamal configuration pattern with the same health check approach, the same secrets source, and the same rollback procedure, and every app follows it. The tool is Kamal; the platform is the convention.

When a Real Platform Team Pays for Itself

Conventions and templates scale further than most teams expect, but not forever. The signals that you are outgrowing the convention-based platform are concrete:

• Engineers spend a measurable share of their week, say 15 percent or more, on infrastructure work that is not product work
• The number of services has grown past roughly 15-20, and template drift means "the same pipeline everywhere" is no longer true
• You genuinely need capabilities that plain servers cannot give you: autoscaling for spiky load, multi-region failover, per-tenant isolation at the scheduler level
• Onboarding time is creeping back up because the conventions live in more heads than documents

At that point, a first platform hire (not a team, a hire) pays for itself by reclaiming the product engineering time currently leaking into infrastructure. Until those signals appear, a dedicated platform team is overhead wearing a fashionable name. Making that call honestly is a tech stack strategy question: the answer depends on your growth curve, not on what conference talks recommend.

A Concrete Example: Onboarding From 3 Days to 4 Hours

A Symfony and Next.js shop we worked with had the standard pre-platform profile: four repositories, four different local setups, deployments run by the two engineers who knew the incantations, and new-hire onboarding that took three days of pairing before the first local environment ran.

The intervention was exactly the three investments above, implemented over about three weeks alongside normal product work:

1. Every repository received the same make setup / make dev / make test targets backed by Docker Compose, with the Symfony API and the Next.js frontend sharing one Compose network so the full stack ran with two commands.
2. A reusable CI workflow replaced four divergent pipelines; deploys went through Kamal with one configuration pattern and a documented one-command rollback.
3. Secrets moved out of scattered CI settings into Kamal's secrets flow with a one-page rotation runbook per credential.

The next hire cloned, ran make setup twice (once per stack), and had the full product running locally before lunch: roughly four hours from laptop handover to first local commit, against three days previously. The deploy bottleneck disappeared as a side effect, because deploying stopped requiring the two engineers who held the knowledge.

None of this required new infrastructure. The servers were the same. What changed was that decisions previously made per-project and stored in heads were made once and stored in code.

Where to Start

If you start from zero, sequence the work by frequency of pain: local setup first because everyone touches it daily, the pipeline template second because every merge touches it, secrets rotation third because the cost of skipping it arrives all at once. Resist the temptation to begin by evaluating platform products; at this scale the platform is written in your repositories, not bought.

If you want an experienced outside eye on that sequencing, or hands-on help building the templates and runbooks against a Symfony or Next.js stack, that is the kind of engagement we do regularly as part of custom software development and platform modernization work. Reach out at hello@wolf-tech.io or via wolf-tech.io, and we can look at where your team loses the most time.

FAQ

Is platform engineering worth it for a team of five? Yes, in the convention-based form described here. A team of five benefits from a standardized local setup and one deployment pattern just as much as a larger team, and the investment is days, not months. What a team of five should not do is adopt Kubernetes or hire platform specialists.

Do we need Backstage or another developer portal? Below roughly 20 engineers and 15 services, a portal catalogs things you can hold in your head. A well-maintained README index and consistent repository structure deliver the discoverability without the operating cost.

Can Kamal really replace Kubernetes for production SaaS? For single-region workloads on a handful of servers, yes: zero-downtime deploys, health checks, secrets, and rollbacks are covered. If you need autoscaling, multi-region scheduling, or per-tenant workload isolation, Kubernetes starts earning its complexity.

What is the first sign we need a dedicated platform hire? Track how much product engineering time leaks into infrastructure work each sprint. When that share stays above 15 percent for a quarter despite good conventions, a platform hire reclaims more time than they cost.