• 9 min read

Platform Engineering Anti Patterns

Common platform engineering anti-patterns Australian teams hit, and how to build internal platforms engineers actually adopt. Book a review.

Quick answer: Platform engineering fails most often through tool-first builds, isolated platform teams and infrastructure sized for scale not yet reached; treat it as a product with proven demand.

  • Platform Engineering
  • Cloud Engineering
  • DevOps and SRE Practice
  • System Integration
Jump to section
  1. What Platform Engineering Actually Means
  2. The Anti-Patterns Worth Avoiding
  3. Where Platform Work Fits Alongside Integration and Modernisation
  4. Staged Modernisation Over Big-Bang Rebuilds
  5. Platform Engineering Anti-Patterns: Common Questions

Quick answer

What are the most common platform engineering anti-patterns?

High confidenceVerified 31 Aug 2026
The recurring failures are building platform tooling before proving developer demand, running an isolated platform team with no feedback loop, and over-engineering infrastructure for scale the business hasn't reached yet.

Sources

Platform Engineering Fundamentals

What platform engineering actually means

Platform engineering is the discipline of building an internal developer platform: a self-service layer of infrastructure, tooling and golden paths that lets application teams provision environments, deploy services and observe production without raising a ticket for every step. Done well, it reduces cognitive load on product teams and gives a small platform group leverage across many applications. Done badly, it becomes an expensive layer nobody actually uses.

The term is often used loosely. DevOps describes a culture of shared responsibility between development and operations; site reliability engineering (SRE) applies software engineering discipline to operational reliability targets; platform engineering is the productisation of both, packaged as an internal platform with its own users, roadmap and adoption metrics. Confusing the three is itself an early anti-pattern: a platform team that behaves like a ticket-taking operations function, rather than a product team serving internal customers, rarely gets adopted voluntarily.

The anti-patterns worth avoiding

The following patterns show up repeatedly across growing Australian businesses building their first internal platform, regardless of industry or team size.

Building the tooling before proving the demand

The most common failure mode starts with a tool rather than a problem: a team stands up a new CI/CD platform, service mesh or internal PaaS because it appeared on a conference agenda, not because engineers asked for it. A related version of this shows up in real-time infrastructure decisions, where teams reach for Message queuing best practices for Australian timezone synchronisation or build custom How to implement socket connections for Australian timezone synchronisation before confirming the business actually needs sub-second delivery rather than a periodic sync job.

Running an ivory-tower platform team

Platform teams that sit apart from the engineers they serve, with no shared roadmap review or usage feedback, tend to build for their own assumptions rather than observed friction. The fix is structural: treat application teams as customers, measure adoption, and let unused capability get deprecated rather than defended.

Over-engineering for scale that hasn't arrived

Architecture sized for the traffic a business hopes to have in five years adds real operating cost and cognitive load today. Multi-region failover, complex service meshes and elaborate autoscaling policies are appropriate once load genuinely demands them, not before. The right-sized approach is to build for the scale the organisation is actually approaching, with a credible path beyond it.

Avoiding Platform Engineering Anti-Patterns

Problem

Many platform engineering initiatives stall because teams build infrastructure before validating developer demand, run platform work as an isolated operations function, or size systems for growth the business hasn't reached, leaving expensive tooling with low adoption and duplicated effort.

Business Impact:

Time Wasted:Engineering time spent maintaining platform capability few teams actually use
Cost Implication:Ongoing cloud and tooling spend that outpaces the value the platform delivers
Opportunity Cost:Developer time diverted from product work to route around a platform that doesn't fit how teams actually build software

Solution

Treat the platform as a product: validate demand with real engineering teams, ship a small usable core before broad rollout, and expand capability only as usage and scale genuinely require it.

Our Approach:

  1. 1
    Audit current developer pain points(Typically the first few weeks)

    Interview the application teams who would use the platform to confirm which manual steps actually cost them time, rather than assuming

  2. 2
    Ship a minimal, adopted core(Following phase, iterative)

    Build the smallest self-service capability that removes a real bottleneck, then measure voluntary adoption before adding further scope

Expected Outcome:A platform that engineering teams choose to use because it removes real friction, rather than one mandated from above with low uptake.

Key Takeaways

What to Get Right in Platform Engineering

  • Treat the platform as a product with real users, not a mandateCritical

    Platform teams that measure adoption and gather feedback from application engineers build capability people actually choose to use, rather than tooling that gets bypassed.

  • Separate platform engineering from DevOps culture and SRE reliability targetsImportant

    DevOps is a way of working, SRE sets reliability objectives, and platform engineering packages both into a usable internal product; conflating the three creates confused ownership.

  • Match infrastructure investment to the scale the business is actually approachingImportant

    Building for hypothetical future load before it exists adds ongoing operating cost and complexity that the current team then has to maintain indefinitely.

  • Keep legacy systems in the architecture where they still do the jobImportant

    Integrating existing platforms is usually faster and less risky than a full rebuild, and it preserves institutional knowledge the business depends on.

Platform engineering succeeds when it is run as an internal product with proven demand, clear ownership separate from DevOps and SRE, and infrastructure scaled to real, not imagined, growth.

Why Platform Foundations Matter

Platform engineering decisions sit on top of broader shifts in how Australian businesses use cloud infrastructure and manage operational risk, which shape what a sensible internal platform actually needs to cover.

55%

Cloud computing adoption among Australian businesses

Significance: medium

More than half of Australian businesses reported using paid cloud computing services, meaning most platform engineering work now sits on top of existing cloud footprint rather than a greenfield environment.

Source:ABS Characteristics of Australian Business 2019-20 (https://www.abs.gov.au/statistics/industry/technology-and-innovation/characteristics-australian-business/2019-20)
over 91%

Business-reported internet service adequacy

Significance: low

Most Australian businesses report their internet connection meets most or all of their needs, meaning platform reliability work should focus on internal system design rather than assuming connectivity is the bottleneck.

Source:ABS Characteristics of Australian Business 2024-25 (https://www.abs.gov.au/statistics/industry/technology-and-innovation/characteristics-australian-business/latest-release)
37%

Data breaches caused by human error

Significance: high

More than a third of notified Australian data breaches stem from human error rather than external attack, underscoring why self-service platform guardrails matter as much as raw automation.

Source:OAIC Notifiable Data Breaches Report January-June 2025 (https://www.oaic.gov.au/news/blog/latest-notifiable-data-breach-statistics-for-january-to-june-2025)

Beyond the Platform Team

Where platform work fits alongside integration and modernisation

Internal platform engineering is one part of a wider systems layer that most growing Australian businesses eventually need attention on: integration between Xero, Shopify, HubSpot and bespoke line-of-business software, API development that exposes internal capability safely, and cloud engineering that keeps infrastructure operable by the team that owns it. A platform initiative that ignores these connections tends to solve the wrong problem first.

Real-time capability is a common trigger for this wider work. A business that has outgrown polling-based integrations often needs Server-sent events strategies for Australian timezone synchronisation or a properly designed Complete guide to notification systems in Australia, but only once the underlying platform and API layer can support it reliably across states and time zones.

Staged modernisation over big-bang rebuilds

Existing systems are assets where they still serve the business, so a rip-and-replace of core platforms is a last resort rather than a default recommendation. Legacy system modernisation and application modernisation work best staged: decompose one bounded piece of functionality behind an API, prove it in production alongside the system it's replacing, then move to the next piece. This keeps the business trading while the underlying architecture changes.

Infrastructure should also live in accounts and environments the client controls, rather than creating unnecessary lock-in to any single delivery partner. Combined with a maintainable architecture the internal team can actually operate day to day, that staged approach is what separates platform engineering that compounds in value from platform engineering that becomes another system to modernise in a few years.

Ready to Pressure-Test Your Platform Engineering Roadmap?

Book a working session to review current tooling, integration points and where a self-service platform would genuinely save engineering time, before committing further budget.

Email Our Team

or enquiries@nationaldigital.com.au1300 800 855

Platform Engineering Anti-Patterns: Common Questions

What does platform engineering actually mean?
Platform engineering is the practice of building an internal developer platform, a self-service layer of infrastructure, tooling and deployment paths that lets application teams provision, deploy and observe their own services without raising a ticket for every change. It borrows from DevOps culture and SRE reliability practice but packages both as a product with its own users and adoption metrics, rather than a purely operational function.
How is platform engineering different from DevOps?
DevOps describes a culture of shared responsibility between development and operations teams, focused on collaboration and continuous delivery. Platform engineering is more concrete: a dedicated team builds and operates a self-service platform that makes DevOps practices easy to follow by default, through templates, golden paths and automated guardrails, rather than relying on every team learning operations skills from scratch.
Where does site reliability engineering fit alongside platform engineering?
SRE applies software engineering discipline to operational reliability, setting error budgets and service-level objectives and treating operations problems as engineering problems. Platform engineering often implements the guardrails SRE recommends, such as safe deployment defaults and observability baked into the platform, so reliability targets are met by default rather than enforced team by team.
What's the clearest sign a platform engineering initiative is going wrong?
Low voluntary adoption is the clearest signal. If application teams route around the platform, keep maintaining shadow infrastructure, or complain that self-service capability doesn't match how they actually build software, the underlying cause is usually that the platform was built for an assumed need rather than a validated one.
How do we know if our business is ready to invest in platform engineering?
Readiness usually shows up as recurring friction across multiple application teams: repeated manual environment setup, inconsistent deployment practices, or growing cloud costs nobody fully owns. If only one team has the problem, a shared library or better documentation is often enough; a dedicated internal platform tends to earn its cost once several teams hit the same wall independently.
Which tools do platform engineering teams typically rely on, and do we need all of them?
Common categories include infrastructure-as-code, container orchestration, CI/CD pipelines, service catalogues and observability platforms. Few growing businesses need every category from day one; the requirements-led approach is to identify the specific bottleneck an application team faces, choose the smallest tool that resolves it, and expand tooling only as genuine usage and scale justify the added operating complexity.

Written by Cameron Young, CEO

  • 9 min read

Related reading