Custom software vs an internal developer platform: which problem are you actually solving?

Key takeaways

• By 2026, Gartner forecasts 80% of large software engineering organizations will have platform teams, up from 45% in 2022 (Gartner, 2023). The qualifier "large" is doing a lot of work, and small teams keep ignoring it.
• The 2024 DORA report found internal platforms correlate with a 10% lift in team performance but also an 8% drop in throughput and a 14% drop in change stability (DORA, 2024). A platform is not a free win.
• What actually moves the needle is developer independence — working without waiting on another team — which DORA links to a 5% productivity gain (DORA, 2024). You can buy that without staffing a platform team.
• Custom software is a bet on product differentiation. An internal developer platform is an internal product with its own users, roadmap, and product manager. Confusing the two is how small teams burn senior engineers on plumbing.

TL;DR

Under 100 engineers, "we need a platform" is almost always the wrong diagnosis. The symptom is real: deploys are slow, every environment is a snowflake, and senior people spend their days unblocking juniors. But the cure is rarely a capital-P Platform team building a bespoke internal developer platform. It's usually a thin paved path over managed services, plus ruthless removal of the specific toil your engineers hit every day. Build custom software where it differentiates your product. Adopt, don't build, the platform underneath it, until you have enough platform users to justify a platform team.

Why teams confuse these two problems

Platform engineering became fashionable, and fashionable ideas get misapplied. Adoption is already near-universal: recent DORA research finds about 90% of organizations use an internal developer platform (DORA, 2024). So the question stopped being "should we adopt one" years ago. The useful question now is narrower: at our size, does a dedicated platform effort pay for itself, or are we solving a headcount problem with an architecture project?

Here's the confusion in one sentence. Custom software exists to make your product different from a competitor's. An internal developer platform exists to make your engineers faster at shipping that product. Those are different investments with different owners, different risk profiles, and different failure modes. When a 30-engineer company decides to "build a platform," it's often really trying to fix a delivery bottleneck, and it reaches for the most expensive possible tool to do it.

What is an internal developer platform, actually?

An internal developer platform is a self-service layer that lets engineers provision environments, ship code, and run services without filing tickets or waiting on ops. In practice it bundles paved paths, golden templates, and a portal on top of your infrastructure. The 2024 DORA research is blunt about what makes it work: the real prize is developer independence, the ability to get work done without relying on another team, which correlates with a 5% productivity gain at both the individual and team level (DORA, 2024).

Notice what that finding does and doesn't say. It says autonomy helps. It does not say you need a bespoke platform, a Backstage deployment, or three engineers with "platform" in their title to get that autonomy. A managed PaaS, a good CI template, and one well-written deployment script can deliver most of the independence a small team is missing, without becoming a product you now have to maintain forever.

The uncomfortable data: platforms have a downside

This is the part the hype skips. The same 2024 DORA report that found platforms lift team performance by 10% and individual productivity by 8% also found they correlate with an 8% decrease in throughput and a 14% decrease in change stability (DORA, 2024). A platform can make your organization feel more capable while shipping less, less safely, especially when it's mandated for every task before it's mature.

Why the split? A platform adds a layer of indirection. Below a certain scale, that layer costs more in friction than it saves in standardization, because you don't yet have enough teams hitting the same problems to amortize it. InfoQ's analysis of the DORA data put it plainly: platform engineering shows "its biggest successes in large organisations," while for smaller ones it can be "challenging" and even "potentially counterproductive" (InfoQ, 2024). If a Tier-1 dataset is telling you the intervention may hurt at your size, that's worth more than a conference talk telling you it's the future.

So what problem do you actually have?

Usually it's toil, not the absence of a platform. McKinsey's developer experience research found engineers can spend 20–30% of their time on undifferentiated work: wiring up integrations, chasing security approvals, configuring environments (McKinsey, 2020). That's the real bottleneck for most sub-100-engineer teams, and it's the thing worth attacking first.

Read that carefully. The bottleneck is undifferentiated work, not the absence of a platform team. You can attack that 20–30% of toil directly and cheaply. Ask a blunt question at your next retro: what did you wait on this week? The answers — a staging environment, a deploy, a database migration, a secret — are your actual backlog. Fix those five things and you've captured most of the platform upside with none of the platform overhead.

An internal developer platform is a product, and products need staff

If you decide you genuinely need a platform, price it honestly. It is not a side project. In Puppet's 2024 State of DevOps data, 52% of respondents said a product manager is "crucial" to platform-team success (Puppet by Perforce, 2024). A platform has users, a roadmap, support requests, and a satisfaction problem if nobody adopts it. That's a product commitment, not a ticket.

The same survey shows how much runway mature platforms have had: about 70% of respondents said their platforms are at least three years old, and 10% have run them for more than a decade (Puppet by Perforce, 2024). Platform engineering as a discipline is concentrated in organizations that have had years, and headcount, to invest. A 25-person startup copying their playbook is copying the output of a decade of scale it doesn't have yet.

There's a simple staffing test. If you can't dedicate at least one person to the platform as their actual job, plus someone doing product management for it, you don't have a platform. You have a shared responsibility that will rot the moment its champion changes teams.

What to build, what to adopt, what to outsource

Here's the framing we use with clients weighing this exact decision. Sort every candidate into one of three buckets, and be honest about which is which.

The mistake we see most often isn't building too little. It's building an internal platform to solve a problem that a $20-per-seat managed service already solves, then assigning your two best engineers to maintain it instead of the product customers pay for. Backstage, the popular open-source developer portal, is a great tool, but a portal is only worth running when you have enough services and teams that discovery is a real problem. At ten services, a README and a Slack channel is your portal.

What we got wrong: On an early engagement we helped a ~40-engineer client stand up a "proper" internal platform because that's what the mature orgs did. Eighteen months later, two of their strongest engineers were full-time platform maintainers, product velocity had dropped, and adoption of the platform's fancier features was near zero. We'd solved a scaling problem they didn't have yet and created a staffing problem they couldn't afford. The fix was embarrassing in its simplicity: we deleted half of it, moved onto a managed PaaS, and wrote three paved-path templates. Independence went up; the maintenance tax went to nearly zero.

When an internal developer platform genuinely earns its place

Platforms aren't wrong; they're just stage-dependent. The honest triggers are structural, not aspirational. You're probably ready when several teams keep solving the same infrastructure problem in slightly different ways, when onboarding a new service takes days of tribal knowledge, or when you have enough engineers that a 5% independence gain (DORA's figure) translates into real money. That last point matters: percentages only become budgets at scale. Five percent of 200 engineers funds a platform team. Five percent of 20 engineers funds a nice lunch.

If you're above roughly 100 engineers with multiple product lines and repeated infrastructure duplication, the DORA and Puppet data start to favor a real platform investment, with a dedicated team and a product manager. Below that, treat "platform" as a set of paved paths you maintain lightly, not an org chart.

How to decide in one afternoon

You don't need a quarter-long assessment. Run this in a room with your senior engineers.

1. List the last month's blockers. What did people wait on? Be specific — environments, deploys, approvals, data.
2. Sort each blocker: is it undifferentiated toil (adopt a service) or genuine product work (build it)?
3. Count your platform users. How many teams would actually use a self-service layer? Under three or four, you don't have a platform audience.
4. Price the team. If you can't fund one dedicated engineer plus part-time product management, don't start a platform. Buy paved paths instead.
5. Pick the cheapest thing that removes the top three blockers. Ship it. Re-measure in a month.

If, after that, the answer is still a platform team — build it deliberately, staff it as a product, and measure adoption. If the answer is "we just needed managed CI and a deploy template," you've saved yourself the most expensive lesson in this article.

Frequently asked questions

Isn't platform engineering the industry standard now?

For large organizations, increasingly yes. Gartner forecasts 80% of large software engineering orgs will have platform teams by 2026, up from 45% in 2022 (Gartner, 2023). But "standard for large orgs" is not "correct for a 30-person team." The DORA 2024 data shows platforms can be counterproductive at smaller scale, so borrowing a big-company playbook wholesale is a real risk.

Can we get the benefits without building a platform?

Mostly, yes. The measurable win DORA identifies is developer independence, worth about a 5% productivity gain (DORA, 2024). A managed PaaS, solid CI templates, and self-service environments deliver most of that autonomy without you owning a bespoke internal product and its long-term maintenance cost.

How do we know we've outgrown paved paths?

When multiple teams repeatedly rebuild the same infrastructure, onboarding a service takes days, and a 5% efficiency gain across a large headcount would fund a dedicated team. Puppet's 2024 data shows mature platforms typically have years of investment behind them (Puppet by Perforce, 2024); it's a scaling milestone, not a starting move.

What's the single biggest mistake at small scale?

Assigning your strongest engineers to build internal tooling that a managed service already provides, while the product they should be differentiating stalls. McKinsey's research shows 20–30% of developer time already goes to undifferentiated toil (McKinsey, 2020); the goal is to remove that toil, not to hire a team to manage a new layer of it.

The decision behind the decision

Custom software and an internal developer platform answer different questions. One asks "how do we build a product nobody else has?" The other asks "how do we help our engineers ship faster?" Both are legitimate. But below 100 engineers, the fast path to the second answer almost never runs through a bespoke platform; it runs through adopting good managed services and deleting your team's specific toil. Spend your scarce senior engineering time on the differentiation only you can build. Rent the rest. When you genuinely outgrow that, the data will tell you, and you'll build the platform as the product it actually is.

If you're weighing this decision right now and want a second opinion grounded in real engagements rather than conference slides, that's exactly the kind of architecture call we help teams make.