Invented Work: How Extra Complexity Sneaks Into a Software Quote

There's a piece doing the rounds among engineers at the moment about how staff-level developers sometimes invent work: building tools nobody asked for, refactoring things that weren't broken, chasing "best practice" for its own sake. It's usually framed as a career problem inside big companies. But the same thing shows up in software quotes for small and mid-sized businesses, and it costs you real money.

Not all of it is dishonest. A lot of it is habit, fear of being blamed later, or a genuine belief that more structure is always safer. But if you're paying for bespoke software or extra development capacity, it's worth knowing what invented work looks like, because it's rarely presented as optional.

What invented work actually looks like

It's not usually a line item marked "unnecessary". It's dressed up as care, foresight or good practice. Some common shapes:

• Multi-tenancy for one tenant. Building an internal tool as if it might one day be sold to other companies, when it's only ever going to run for you.
• A plugin or configuration system. Making a feature endlessly configurable when the business only ever needs one version of it.
• An admin panel nobody will use. A full CRUD interface built for edge cases that happen twice a year and could be handled with a database query.
• Microservices for a system with ten users. Splitting a small app into separate services "for scale" long before scale is a real concern.
• Custom authentication instead of a proven library. Reinventing something well-solved because it's more interesting to build than to install.
• Test suites for throwaway prototypes. Rigorous coverage on code that's going to be rewritten in three months once you've validated the idea.

Each of these can be the right call in the right context. The problem is when they turn up regardless of context, because they're what the developer or team defaults to, not what your business actually needs.

Why it happens

In agencies and larger teams, the incentives often point towards more work rather than less. Hourly billing rewards time spent, not problems solved. Junior developers need something to do, and giving them a self-contained "framework" to build keeps them occupied without much oversight. And there's a reputational angle too: an impressive-sounding architecture looks better in a portfolio than a boring solution that fits the job.

None of this requires bad intent. Most developers who over-engineer genuinely believe they're protecting you from future pain. The trouble is that future pain is speculative, and the cost of building for it is not. You pay for the extra abstraction whether or not you ever need it, and you pay again later when someone has to understand and maintain it.

How to spot it in your own project

You don't need to read code to catch this. A few plain questions usually surface it:

• "What problem does this solve today?" If the answer is about a hypothetical future rather than a current pain point, treat it as optional and ask what it costs to leave out for now.
• Watch for phrases like "in case we need to scale" or "best practice". They're not wrong on their own, but they should come with a specific reason tied to your business, not a general principle.
• Ask for the plainest version first. If someone can't describe a simpler way to solve the same problem, that's worth a second conversation before you commit budget to the complex one.
• Look at who benefits. Does the extra structure make the system easier for you to run, or does it mainly make it more interesting to build?

A clear brief helps here too. When the requirements are written down in plain language before anyone starts building, it's much harder for scope to quietly expand into work that was never actually asked for. If you're not sure what should be in one, the software brief generator is a quick way to turn a rough idea into something specific enough to quote against, rather than something vague enough to pad.

Why this matters more with overflow and white-label work

Invented work is particularly easy to miss when you're not the one managing the developer day to day, which is exactly the situation with agency overflow or white-label capacity. If a client's project is being quietly gold-plated, the agency footing the invoice from outside might not notice until the budget's already gone. It's worth checking, whoever is doing the building, whether the scope matches what the client actually asked for, or whether it's grown to match what's interesting to build.

What changes with one developer instead of a team

I work alone, and that changes the incentives in a useful way. There's no bench of junior developers who need a project to justify their time, and no billing structure that rewards padding the estimate. If something can be solved with a library instead of a custom build, I'll say so, because building the custom version doesn't make me look better, it just makes the job take longer for the same fee.

It also means there's nobody between you and the decision. If you ask why a feature is structured a certain way, you get an answer directly from the person who wrote it, not a project manager relaying it secondhand. That doesn't guarantee every choice I make is perfect, but it does mean there's a direct line to challenge it if something looks over-built.

If you want to see how that plays out before committing to anything, how I work covers the stages a project actually goes through, from scoping to launch, and where you get to check the scope before it turns into a bill.