Resource · Cloud & Infrastructure
Build vs. buy,
without the over-engineering.
A four-factor framework for engineering leaders at mid-size companies (200-1,000 employees) making platform and infrastructure decisions. The goal is to avoid the costly mistakes of over-engineering while making sure your team has the capabilities it actually needs to ship.
Most mid-size companies are stuck in the missing middle , too large for startup simplicity, too small for enterprise complexity. The temptation is to copy patterns from Google, Netflix, or your last big-co employer. Don’t. Use this framework before committing to building custom platform tools, adopting complex infrastructure, or signing a multi-year vendor contract.
The model
Four factors. Score each 1-5.
Every build-vs-buy decision should be scored against these four. The decision matrix below tells you what the scores mean together.
1
Maintenance burden
The ongoing time and expertise to keep this running reliably.
Evaluation questions
- ? How many engineer-hours per quarter will this require?
- ? Does this require specialist expertise only one or two people have?
- ? How often will dependency changes force updates?
- ? What is the blast radius if it breaks?
- ? Can a mid-level engineer maintain this, or does it require senior+ expertise?
Low (1)
- · Under one engineer-week per quarter
- · Minimal dependencies
- · Self-documenting or simple architecture
- · Failures are low-impact and obvious
- · Mid-level engineers can maintain
Medium (3)
- · One to four engineer-weeks per quarter
- · Several dependencies needing periodic updates
- · Requires documentation to maintain
- · Failures impact team productivity
- · Requires mid-to-senior engineer expertise
High (5)
- · More than four engineer-weeks per quarter
- · Complex dependencies and frequent security patches
- · Requires deep expertise
- · Failures impact production systems
- · Requires senior or staff engineer expertise
2
Time to value
How quickly this capability needs to deliver value to the business.
Evaluation questions
- ? When does the business need this in production?
- ? Is this blocking other critical initiatives?
- ? Can the team ship core product features without it?
- ? What is the cost of delay per month?
- ? How long would it take to build vs. configure a bought solution?
Urgent (5)
- · Needed in production within two weeks
- · Currently blocking product development
- · Costing significant revenue or opportunity
- · Competitive pressure demands action
Important (3)
- · Needed within 1-3 months
- · Creating friction but not blocking work
- · Will improve velocity or reduce costs
- · Planned for this quarter’s roadmap
Flexible (1)
- · Needed within six months or longer
- · Nice to have but not critical
- · Team can function without it
- · Exploratory or experimental capability
Build time is almost always longer than your initial estimate. Apply multipliers: simple tool ×2, medium ×3, high complexity ×4 or more. “Build time” includes design, implementation, testing, documentation, deployment, and initial bug fixes, not just coding.
3
Strategic differentiation
Whether this capability provides competitive advantage or is table stakes.
Evaluation questions
- ? Will customers notice if we do this exceptionally well?
- ? Would competitors pay to understand how we built this?
- ? Does this directly impact core business metrics?
- ? Is this tied to our unique domain expertise?
- ? Could this become a product offering itself?
Strategic (5)
- · Directly impacts customer experience in measurable ways
- · Reflects unique domain expertise or business model
- · Could become a competitive moat
- · Tied to core business metrics
- · Competitors would struggle to replicate
Tactical (3)
- · Supports core business but doesn’t differentiate
- · Needed for specific workflow or compliance requirements
- · Operational advantage but not customer-facing
- · Improves efficiency of your specific processes
Commodity (1)
- · Every company in your industry needs this
- · Multiple vendors offer similar solutions
- · No customer awareness of how this works
- · Standardised functionality with no unique requirements
4
Exit costs
The difficulty and cost of changing your mind later.
Evaluation questions
- ? How deeply will this integrate with existing systems?
- ? How hard would it be to migrate to an alternative?
- ? What is the data migration complexity?
- ? Are there lock-in mechanisms (proprietary formats, APIs)?
- ? How many other systems depend on this?
Low (1)
- · Standard APIs and data formats
- · Multiple competitive alternatives exist
- · Data is easily exportable
- · Integration is loosely coupled
- · Migration could happen in days or weeks
Medium (3)
- · Some proprietary elements but workable
- · A few alternatives exist
- · Data migration requires planning
- · Integration is moderately coupled
- · Migration would take 1-3 months
High (5)
- · Proprietary formats or deep integration
- · Few or no alternatives exist
- · Complex data migration required
- · Tightly coupled to many systems
- · Migration would take six months or require a rewrite
Be very cautious of: vendor-specific languages or frameworks; proprietary data formats with no export; “all-in-one” platforms that replace multiple systems; custom builds that become “legacy” before they ship; solutions that require rewriting code to switch.
Reading the scores
The decision matrix
Build
Low maintenance + strategic + tolerable time-to-value
Maintenance 1-2 and Differentiation 4-5 and Time to value 1-3.
Examples: domain-specific processing, workflow automation tied to unique business processes, integration glue between your systems, tools that directly support a competitive advantage.
Buy
High maintenance, urgent, commodity, or low exit costs
Maintenance 3-5 or Time to value 4-5 or Differentiation 1-2 or Exit costs 1-2.
Examples: CI/CD (GitHub Actions, GitLab CI), observability (Datadog, New Relic), internal tools (Retool, Airplane), authentication (Auth0, Cognito).
Defer
Evolving requirements or unclear pattern
Requirements still evolving, unsure which approach is right, capability isn’t urgent, or market for it is changing quickly.
Instead: document the manual process, set a 3-6 month review date, collect data on pain points and frequency. Deferring is not avoiding.
The shortcuts
Common platform decisions
The same questions come up over and over. Here are our defaults for the eight most common platform decisions at mid-size companies. They’re defaults, not rules, but the burden of proof is on the exception.
Container orchestration
Defer KubernetesStart with Docker on VMs. Kubernetes maintenance burden is massive; most mid-size companies don’t have the scale to benefit. Reconsider at 50+ services across 10+ engineers deploying multiple times daily.
CI/CD pipeline
BuyGitHub Actions, GitLab CI, CircleCI. Workflows are portable (low exit cost), maintenance burden is zero, time to value is immediate, and CI/CD is not strategically differentiating. Almost never build.
Observability
BuyDatadog, New Relic, Grafana Cloud. High maintenance burden to build, commodity capability, needs 24/7 reliability. Only build when hosted becomes prohibitively expensive, usually past 1,000 employees.
Internal admin tools
BuyRetool, Airplane. Custom admin tools have infinite maintenance burden, terrible time to value, no strategic differentiation, and requirements change constantly.
Infrastructure as code
UseTerraform, Pulumi, cloud-native (CloudFormation, CDK). Low maintenance, critical for repeatability and auditability. Multiple mature options. Never build from scratch, IaC is solved.
Deployment automation
Build (thin)Simple bash or Python scripts that handle your specific deployment steps, health checks, rollback procedures, and notifications. Run them on a bought CI/CD platform. Don’t build the platform itself.
API gateway / service mesh
DeferMost mid-size companies don’t need this. Achieve 90% of the benefit with simpler patterns. Reconsider when you have 30+ services with genuine service-to-service auth needs.
Onboarding docs
Build (lightweight)Markdown in version control, README per repo, simple wiki, ADRs. Strategic, faster onboarding directly impacts velocity. Low maintenance with standard tools.
Sanity check
Is your platform over-engineered?
If you spot more than two of these warning signs, your platform is fighting you instead of helping.
| Warning sign | Action |
|---|---|
| Deployment requires more than three steps | Simplify. Write a single script that does it all. |
| Only 1-2 people understand the infrastructure | Document everything. Simplify until juniors can contribute. |
| More than one day per week on infra maintenance | Audit what you’re maintaining. Sunset or replace complex components. |
| CI/CD pipeline takes more than 30 minutes for basic changes | Profile and optimise. Are you running unnecessary checks? |
| More than one hour to onboard someone to deployment | Too complex. Simplify and document. |
| Production incidents caused by platform tools | Your platform should be boring and reliable. Rethink the complexity. |
| Can’t easily explain your architecture choices | Document the decisions. If you can’t justify it, simplify it. |
| Developers complain the platform is slowing them down | Your platform exists to make developers faster. If it isn’t, it’s failed. |
The framework in practice
Four case studies
CI/CD pipeline
400-person software company, 60 engineers
- Initial proposal
- Custom Jenkins on self-hosted servers
- Scores
- Maintenance 5 · Time to value 4 · Differentiation 1 · Exit 4
- Decision
- Buy, GitHub Actions
- Outcome
- Proposal to first deployment in one week. Zero ongoing maintenance. 40 repositories migrated in six weeks. Three engineers freed up for product work.
Internal admin tools
300-person fintech, 45 engineers
- Initial proposal
- Custom React admin panel
- Scores
- Maintenance 5 · Time to value 3 · Differentiation 1 · Exit 5
- Decision
- Buy, Retool
- Outcome
- Equivalent functionality built in three days. Ops team self-sufficient for most admin tasks. ~8 weeks of engineering time saved.
Observability stack
500-person company, 80 engineers
- Initial proposal
- Self-hosted Prometheus + Grafana + Loki
- Scores
- Maintenance 5 · Time to value 4 · Differentiation 1 · Exit 3
- Decision
- Buy, Datadog
- Outcome
- Production observability in one week. Avoided a dedicated platform-engineer hire. Better ML-based alerts. $40k/yr vs. ~$150k+ loaded.
Kubernetes adoption
250-person company, 35 engineers, 12 services
- Initial proposal
- Migrate from VMs to Kubernetes
- Scores
- Maintenance 5 · Time to value 5 · Differentiation 1 · Exit 5
- Decision
- Defer, stay on VMs with Docker
- Outcome
- Improved deployment scripts and docs instead. Still deploys in under 10 minutes. Two weeks of engineer time vs. six months and a dedicated platform hire.
Worth remembering
Eight principles
- 01
Simple beats sophisticated.
Your infrastructure should be boring and reliable, not impressive.
- 02
Maintenance compounds.
Every custom build creates perpetual maintenance obligations.
- 03
Buy unless strategic.
Default to buying. Only build when there’s strong evidence it’s strategic.
- 04
Exit costs matter.
Choose options that preserve future flexibility.
- 05
Team size is a constraint, not a goal.
Right-size the platform team to actual delivery and maintenance needs.
- 06
Document everything.
Future you will thank present you.
- 07
Automate the repetitive.
But don’t over-automate edge cases.
- 08
Your platform serves your product.
If platform work isn’t making product development faster, it has failed.
Frequently asked
Questions we get
When should mid-size companies build platform tools?
Only when the four factors clearly favour it, low maintenance burden, strategic differentiation, acceptable time to value. In practice this means domain-specific processing, workflow automation tied to unique business processes, integration glue between your specific systems, or tools that directly support your competitive advantage. Almost everything else is a buy decision.
How do you estimate the true cost of building?
Take your initial development estimate and multiply by two to four depending on complexity. Add quarterly maintenance in perpetuity, feature additions as requirements evolve, incident response and on-call, plus the opportunity cost of what the team could otherwise have built. “Build time” includes design, implementation, testing, documentation, deployment, and the first six months of bug fixes, not just coding.
What about Kubernetes, should mid-size companies use it?
For most companies under 1,000 employees with fewer than 50 services, no. The maintenance burden is enormous, the scale benefits don’t materialise, and it’s rarely strategically differentiating. Docker on VMs with sensible deployment scripts will get you to several hundred employees comfortably. Reconsider when you have genuine scale problems, not when you read about Kubernetes on Hacker News.
How big should a platform team be?
A rough heuristic: 1-2 engineers at 200-300 people; 2-4 at 300-500; 4-8 at 500-1,000. The maintenance ratio matters more than headcount: for every engineer building new platform capabilities, expect at least 0.25 engineers maintaining existing ones. If maintenance is consuming more than 25% of platform-team capacity, you have too much infrastructure complexity.
When is "defer" the right answer?
When requirements are still evolving, the capability isn’t urgent, the market for it is changing, or you can live with a manual process for another quarter. Deferring is not the same as avoiding, document the manual process, set a review date, collect data on pain points, research what mature companies use. Premature decisions get rebuilt; deferred ones get made with better information.
Want a second pair of eyes on a real decision?
Most teams already half-know the answer, they want someone senior to pressure-test the reasoning before they commit. That's what we do.