// THE ENTERPRISE TAX

Same app.
Two ways to build it.

Strip away the branding and most “enterprise” projects are the same software as their straightforward counterparts — with extra layers, extra sign-offs, and an extra zero on the invoice. Some of that extra is real. Most of it is manufactured.

// 01

01

What “enterprise” should mean

Enterprise requirements are real when they come from genuine constraints: regulatory and audit obligations, integration with legacy systems of record, multi-team or multi-region coordination, uptime SLAs and disaster-recovery commitments, or data volumes and security postures a small app doesn't have. When these constraints exist, the extra architecture, governance, and process earn their cost.

REGULATORY OBLIGATIONSLEGACY INTEGRATIONSLAs & DRMULTI-TEAM COORDINATION

// 02

02

What gets rebadged as “enterprise”

Most internal tools, customer portals, and line-of-business apps have none of those constraints — yet get sold and staffed as if they did. The work doesn't change; the invoice does. A five-screen approvals tool becomes a “platform.” A weekend's integration becomes an “Enterprise Service Bus modernisation.” A single backlog becomes a steering committee.

RELABELLED SCOPEPROCESS THEATREROLE INFLATION

// 03

03

Same app, two delivery models

Take a typical line-of-business app — an internal expense-approval or customer-request tool. Here's the same build, priced and staffed two different ways.

DimensionLabelled “enterprise”Right-sized
Discovery8–12 week discovery phase, workshops, RAID logs1–2 week scoping, working backlog
TeamBA, 2x PM/scrum, onshore + offshore leads, 2 architects, dev pool, separate QA and DevOps teams1 architect/lead, 2–3 senior engineers, shared QA and DevOps
Architecture"Enterprise" framework, microservices for a CRUD app, custom middleware/ESBRight-sized stack matched to actual load and integration needs
GovernanceSteering committee, change board, weekly status decksLightweight backlog and regular client demos
ToolingProprietary low-code platform with ongoing licence feesStandard, owned, open stack
HandoverVendor retains key knowledge; change requests priced at premium ratesDocumentation, source, and knowledge transferred in full
Typical outcomeLonger timeline, higher run-rate cost, locked-in vendorSame app, delivered faster, owned outright

Where genuine enterprise constraints exist — compliance, scale, legacy integration — the middle column is justified. Where they don't, it's a markup with a label on it.

// 04

04

Why it happens

It isn't usually malice — it's incentives. Time-and-materials contracts reward more people and more phases. Enterprise frameworks and certifications justify premium day rates. Vendors that keep the architecture complex and proprietary keep the client dependent on them for the next change request. The result is the same pattern repeated across the industry: ordinary software, extraordinary cost.

// HOW THE INFLATION HAPPENS

Three tactics to watch for

01Renaming & relabelling
  • "Integration" becomes an Enterprise Service Bus modernisation
  • A form becomes a case management platform
  • A script becomes an automation framework
02Process & people padding
  • Multi-month discovery for requirements that fit on one page
  • Duplicate onshore and offshore leadership layers
  • Steering committees and change boards for single-team work
03Lock-in & compliance-washing
  • Proprietary platforms with recurring licence fees
  • Full regulatory-grade controls on internal tools that don’t need them
  • Thin initial scope, priced to generate expensive change requests

// WHERE WE STAND

We use the word “enterprise” for what it actually means — scale, compliance, integration complexity — never as a synonym for more expensive. If your app doesn't need the layers, we won't sell you the layers.
See how we'd scope your project

// GET STARTED

Get a right-sized scope for your project.

Tell us what you're building. We'll tell you what it actually needs — and what it doesn't.

Talk to us