You do not need a platform team of fifteen to get most of the benefits of an internal developer platform. The IDP conversation has been colonised by Spotify-scale case studies and vendor marketing decks that assume you have a dedicated platform tribe, a golden path committee, and a budget for Backstage customisation work. Most engineering organisations don't. Most don't need that, either.
I've helped a handful of 20-to-50-person engineering organisations build internal platforms that materially improved developer velocity and operational reliability. None of them required a dedicated platform team larger than two or three engineers. The key insight is that most of the value of a platform comes from a small set of well-chosen investments — and most platform programs fail not because they're under-resourced, but because they're trying to build the wrong thing.
What an IDP Actually Is (and Isn't)
An Internal Developer Platform is the set of tools, services, and conventions that let your product engineers ship without becoming infrastructure engineers. It abstracts away the undifferentiated complexity — provisioning environments, deploying services, managing secrets, observing production — so that the people building the product spend their time on the product, not on Terraform and Helm charts.
What it is not: a company-wide developer portal. Not Backstage unless you have a very specific reason to need a software catalogue. Not a fully automated self-service portal on day one. Not a platform engineering org that rivals the size of your product engineering team.
The mistake I see most often is scope inflation. A startup with 25 engineers decides to "build a platform" and designs something that would take 18 months and a dedicated team of six to deliver. By month three, the initiative has delivered a partially working developer portal that nobody uses, and the two engineers assigned to it are demoralised. Meanwhile, the product engineers are still copy-pasting Terraform modules and manually configuring their staging environments.
The alternative is constraint-driven design. You build the smallest platform that delivers the largest fraction of the value — and you maintain the discipline to not add scope until the existing foundations are stable and adopted.
The Four Capabilities That Deliver 70% of the Value
If I could give a 30-person engineering team only four platform investments, these are the ones I'd choose.
The platform is not a product until engineers choose to use it
The most common IDP failure I see is a technically sound platform that gets ignored. Engineers will always find a workaround if the platform path is harder than the manual path. Every investment you make should make the right thing the easy thing — or it will not be adopted, and an unadopted platform is pure cost.
1. Standardised CI/CD Pipeline Templates
This is the highest-leverage platform investment at small scale. A set of reusable pipeline templates — GitHub Actions workflows, GitLab CI templates, or Bitbucket Pipelines — that encode your organisation's standards for linting, testing, building, scanning, and deploying.
Without this: every service has a slightly different pipeline. Some run security scanning, some don't. Some have a proper staging promotion gate, some deploy directly to production from any branch. Onboarding a new engineer means understanding six different pipeline conventions. When a CVE is discovered and you need to add a dependency scanning step, you're updating twelve pipelines individually.
With this: new services inherit the standard template. Security requirements are enforced at the pipeline layer, not as a convention that depends on individual discipline. A change to the standard propagates automatically on the next pipeline run. The platform team can upgrade the toolchain (say, rotating from an older SAST tool to a newer one) in one place.
The initial investment is two to four weeks of a senior engineer's time. The ongoing maintenance is minimal. The operational return is immediate.
2. Infrastructure Abstractions (Not Full Self-Service)
At 30 engineers, you don't need a fully automated self-service environment provisioner. You need Terraform modules that encode sensible, opinionated defaults for your common infrastructure patterns — a web service, a background worker, a Postgres database, a Redis cache, an event consumer.
The difference between a good module and a bad one: a good module makes the right configuration the default. Encryption at rest is on by default. Private networking is the default. Sensible resource sizing for your workload types is pre-set. An engineer using the module gets a well-configured resource without needing to know which Terraform arguments to set.
This does not require a self-service portal. A well-written module in a shared Terraform registry, with documentation and examples, is sufficient. Engineers copy the module invocation, change the name and size parameters, open a PR, and a human reviews and applies it. The review step is not a bottleneck at this scale — it's a quality gate. Full self-service automation, with automated terraform apply on PR merge, can come later when the team has grown to the point where the human review becomes the bottleneck.
3. Observability Stack as a Shared Service
Every product service should be observable out of the box. Logs, metrics, and traces should flow to a central place without requiring each service team to configure instrumentation independently. This means: a standard logging format (structured JSON, with agreed field names), an auto-instrumented metrics collection pipeline, and distributed tracing configured at the platform layer rather than the application layer.
The practical implementation for a 30-person team: a single observability stack — Grafana + Loki + Tempo, or a managed equivalent like Datadog or Grafana Cloud — with SDKs and deployment conventions that make the right instrumentation the default. If your deployment template includes a sidecar that ships logs in the right format, engineers get observability for free. If they have to opt in, some services won't be observable, and you'll find out at 2am during an incident.
The platform team's job here is not to maintain dashboards for every team. It's to maintain the platform that lets every team maintain their own dashboards without infrastructure work.
4. Secrets and Configuration Management
Hardcoded credentials and ad hoc configuration management are among the highest-risk, lowest-visibility problems in early-stage engineering organisations. A centralised secrets management system — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — with standardised application integration patterns is a platform capability that prevents entire categories of security incidents.
The platform provides: a standard way for services to authenticate and retrieve secrets at startup; rotation policies for common credential types; audit logs for who accessed what and when. The application engineer's experience: inject a Vault agent sidecar in the deployment template, reference secrets by name, and the platform handles the rest.
This is also where you codify environment-specific configuration — the distinction between what's a secret and what's non-sensitive configuration that can live in a config map or parameter store.
What to Build in What Order
Sequence matters. Building the observability stack before you have standardised CI/CD means you're observing systems that deploy inconsistently. Building self-service environment provisioning before you have infrastructure modules means you're automating a bad process.
The phased build order reflects dependency — each layer stabilises before the next is introduced:
Start here. Audit the existing pipelines across all your services and identify the common patterns and the divergences. Build three to five reusable templates that cover your most common service types. Migrate the highest-traffic services first — they're the ones where the investment pays off fastest and where you'll learn the most about what the templates actually need to handle.
Overlap with pipeline work once the first templates are stable. Identify the five to eight most common infrastructure patterns your teams provision. Build Terraform modules for each. Write documentation that an engineer who has never touched Terraform before can follow to provision a new service. The documentation quality is as important as the module quality.
Deploy the central observability platform and integrate it with the pipeline templates so that new services get instrumentation by default. Provide one or two reference dashboards per common service type that teams can fork and extend. Don't build custom dashboards for every team — teach teams to build their own.
Introduce centralised secrets management after the other three foundations are in place. Migrate the highest-risk credentials first — database passwords, API keys for external services. Establish rotation schedules. Audit the existing codebase for hardcoded credentials — there will be some. Treat the migration as a security improvement, not a platform migration, so it gets appropriate priority.
The Staffing Model
A 30-person engineering organisation does not need a dedicated platform team. It needs one or two engineers who have explicit ownership of the platform — who are accountable for its reliability, adoption, and evolution — while primarily working alongside product teams.
The model I recommend: a senior engineer who is 50-70% "platform embedded in product teams" and 30-50% "platform investment." This person spends enough time in product team sprints to know what's actually painful, and enough focused time on platform work to make meaningful progress on the investments. A second engineer at the same split accelerates delivery significantly and provides continuity.
What you explicitly do not need: a full-time platform product manager, a platform roadmap planning process with quarterly OKRs, a platform documentation site, or a developer experience survey cycle. These are correct investments at 150 engineers. At 30, they are overhead that will kill the initiative's momentum before it delivers value.
The platform team trap: building for engineers you don't have yet
The failure mode I see most often in small-org platform initiatives is designing for the team you imagine you'll have in two years rather than the team you have today. A 30-person team does not need a multi-tenant environment provisioning system with RBAC and a web UI. It needs well-documented modules and templates. Build for today. The abstraction you add for future scale is complexity you're paying for now, and future-you will have different requirements than present-you is guessing.
The Build-vs-Buy Decision for Platform Components
Almost every platform component I've described has a managed alternative. The decision framework:
| Component | Build | Buy/Managed |
|---|---|---|
| CI/CD pipeline templates | Always build (your organisation's conventions, not a product) | N/A — the runner is managed, the templates are yours |
| Infrastructure modules | Always build (your cloud account, your security policies) | N/A |
| Observability platform | Build only if you have compliance reasons not to use SaaS | Datadog, Grafana Cloud, Honeycomb — default to managed |
| Secrets management | Rarely — managed services are mature and secure | AWS Secrets Manager, Azure Key Vault, HashiCorp Vault Cloud |
| Developer portal / software catalogue | Almost never at this scale | Backstage if you genuinely need it at 100+ engineers; not before |
The philosophy: build the opinions (your conventions, your modules, your templates), buy the undifferentiated infrastructure (the observability platform, the secrets store, the runner infrastructure). At 30 engineers, running your own Prometheus at scale, operating a Vault cluster, and maintaining a Backstage instance are all meaningful operational burdens that distract from the four capabilities that actually matter.
Measuring Whether It's Working
A platform with no adoption metrics is a platform that will be deprioritised at the first budget squeeze. Track three things:
Time to first deployment for a new service. How long does it take from "we're building a new service" to "that service has deployed to staging for the first time"? If it takes four days of infrastructure work, your platform is not doing its job. A good platform gets this to under four hours, including environment provisioning, pipeline configuration, and observability setup.
Pipeline standard adoption rate. What percentage of your active services use the standard pipeline templates? If it's below 80%, you either have adoption problems (the platform isn't easier than the manual path) or exceptions that need to be understood and either accommodated or resolved.
Incident resolution time for platform-related incidents. When an observability gap or a secrets configuration error contributes to a production incident, how quickly can you resolve it? This metric tells you whether the platform is an operational asset or a liability.
Start with a platform retrospective, not a platform roadmap
Before you plan what to build, spend two days talking to your engineers about what they actually find painful. Not what they think they should want (self-service, developer portal, service mesh), but what they find themselves doing repeatedly that they wish they didn't have to do. The answers are almost always: copying and modifying pipelines, manually provisioning environments, debugging where logs went, and rotating credentials by hand. Those four answers will validate or challenge the four investments I've outlined, and they'll give you the adoption buy-in you need before you've written a line of platform code.
The Honest Scope Boundary
A lean IDP at 30 engineers is not a full-featured internal developer platform. It is a curated set of investments that removes the most expensive friction for the most engineers. It does not include: a self-service environment management UI, a service catalogue, automated cost attribution, a golden path wizard, or a developer experience team that runs quarterly surveys.
Those are real investments with real value — at the right organisational scale. Pushing them into a small team's platform roadmap before the foundations are solid is the fastest way to deliver an impressive-sounding but underused platform that erodes trust in platform engineering as a concept.
Build the four foundations. Measure adoption. Add scope only when the foundations are stable, adopted, and no longer the bottleneck. That discipline is rarer than it sounds, and it's what separates the platforms that deliver for years from the ones that get quietly abandoned after six months.
If you're trying to figure out where to invest your platform engineering budget — or whether a platform program makes sense at your current scale — let's talk — a 30-minute discovery call is enough to map your actual friction points and give you a concrete, right-sized plan.