Why a senior development team costs less than cheap software

A senior development team costs more per day and less per working feature. Cheap software is paid for later: in rework, in technical debt that slows every change, in outages and security incidents, and in dependency on whoever wrote it. Research from Google's DORA programme shows that the best teams ship faster and more reliably at the same time, so you do not have to trade speed for quality. The practical question is how to tell a senior partner from a cheap one before you sign, and this guide gives you a checklist for exactly that.

It is written for founders, managing directors and heads of IT who are about to commission software, or who own software that has become slow and expensive to change.

#What cheap software really costs

The day rate is the most visible number in a software project and the least informative. What you pay for is working features over the life of the product, and that total depends far more on quality than on the price of a day. The costs of cheap software simply arrive later.

Rework and technical debt

Martin Fowler describes technical debt as a metaphor, coined by Ward Cunningham, for deficiencies in internal quality that make a system harder to change: the extra effort it takes to add new features is the interest paid on the debt. His technical debt quadrant separates prudent debt, taken on deliberately to reach a release and repaid afterwards, from reckless debt, where a team cuts corners because it believes it cannot afford clean code, or does not know better. Cheap teams mostly produce the reckless kind.

The interest is measurable. In a study of 39 proprietary production codebases, Adam Tornhill and Markus Borg found that low-quality code contained 15 times more defects than high-quality code, and that resolving issues in it took on average 124% more development time. Fowler argues in Is high quality software worth the cost? that for internal quality the usual trade-off runs the other way: developers find that poor-quality code slows them down within a few weeks.

Outages and failed releases

Software that is not tested before release is tested by your customers. Every failed release costs twice: once for the incident and again for the rework. CISQ's 2022 report estimated the cost of poor software quality in the US at USD 2.41 trillion or more, with accumulated technical debt at about USD 1.52 trillion. Those are national estimates, not a forecast for your project.

Security incidents

Security flaws are quality flaws that someone exploits. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at USD 4.99 million. Many weaknesses are mundane: missing access checks, misconfigured services and outdated dependencies, exactly the work cheap teams skip.

Dependency on whoever wrote it

The quietest cost is lock-in. If only the original developer understands the code, if the repository, the cloud account or the app store listing sit in their name, or if nothing is written down, you cannot change supplier without starting again. For cloud services, the EU Data Act has required providers to support switching since 12 September 2025 and abolishes switching charges from 12 January 2027. No regulation, though, hands you the knowledge in a freelancer's head or the accounts in an agency's name. That part is decided by your contract and your handover.

#What the research says about delivery performance

The most cited research on software delivery comes from DORA, a research programme at Google that surveys thousands of technology professionals every year. It gives a buyer measurable things to ask about, rather than adjectives.

The four key metrics, now five

DORA started with four key metrics: two for throughput (how fast changes reach production) and two for stability (how often they go wrong and how quickly you recover). Its current metrics guide adds a fifth, the rework rate:

• Change lead time: the time from a change being committed to version control to it running in production.
• Deployment frequency: how often changes are deployed to production.
• Change fail rate: the share of deployments that need urgent intervention afterwards, such as a rollback or a hotfix.
• Failed deployment recovery time: how long it takes to recover from a deployment that fails.
• Deployment rework rate: the share of deployments that are unplanned and triggered by an incident in production.

The central finding is that speed and stability are not trade-offs. For most teams the metrics move together, and top performers do well on all of them, because the same practices drive both: small changes, automated tests, automated deployment and fast feedback. A partner who tells you that quality will slow the project down has the evidence against them.

AI makes the team more important, not less

AI coding assistants are now standard, and they change the economics of cheap teams. The 2024 DORA report estimated that as AI adoption increased, delivery throughput fell by 1.5% and delivery stability by 7.2%. The 2025 report, based on nearly 5,000 respondents, found a positive relationship with throughput but a continuing negative relationship with stability, and summed it up in one line: AI does not fix a team, it amplifies what is already there. Generated code is cheap. Knowing whether it is correct, secure and maintainable is the senior part.

#Security basics a good team handles without being asked

The OWASP Top 10 is the standard awareness list of the most critical security risks in web applications. The 2025 edition puts broken access control first, followed by security misconfiguration and software supply chain failures. None of these needs a security specialist to prevent. They need engineers who build the safeguards in from the start:

• Access control on the server. Every request checks who the user is and what they may see, rather than hiding buttons in the interface.
• Configuration as code. Environments come from versioned configuration, with secrets in a secret store and no default passwords.
• Dependencies under control. Libraries are pinned, scanned and updated, and new packages are vetted before anyone installs them.
• Input handling. Queries are parameterised and input is validated at every boundary.
• Logging and alerting. Security events are logged, and someone is alerted when something unusual happens.

In the EU this is also a legal duty. Article 32 GDPR requires security appropriate to the risk, including a process for regularly testing and evaluating it, and Article 28 requires a data processing agreement with every processor, which includes your development partner if it handles personal data. A senior partner raises both before you do.

#What senior actually means

Seniority is not years on a CV or the number of frameworks listed. Someone can write code for ten years without ever owning a system in production. In practice, senior engineers are recognisable by five things.

Judgement

They know which decisions are expensive to reverse (the data model, permissions, billing, the hosting region) and spend their care there. They say no to features that do not serve the goal, and explain why.

Architecture

They choose the simplest structure that will survive the next few years: usually one well-organised application rather than a distributed system, with clear boundaries between the interface, the business rules and the data. They write down why, in short decision records.

Testing

They treat automated tests and the release pipeline as part of the product, not as extras for later. Every change is tested and deployed the same way, so releases are routine rather than events.

Communication

They explain trade-offs in plain language to people who do not write code, put plans and decisions in writing, and raise bad news early, while it is still cheap to act on.

Ownership

They care what happens after the release: monitoring, incidents and the person who maintains the code next.

A team does not need to be entirely senior. It needs senior people making the expensive decisions and reviewing the work, and enough of them that the knowledge never sits in one head.

#In-house, agency, freelancers or staff augmentation

Each of the four common ways to staff a project is right somewhere. The deciding questions are who owns the architecture and who holds the knowledge when the project ends. Hiring in-house is slow in Germany: Bitkom's study of August 2025 counted about 109,000 unfilled IT positions and found that IT vacancies stay open for 7.7 months on average.

The last row has legal detail in Germany, because who directs the work decides whether it counts as temporary agency work under the AÜG. Our guide to IT staff augmentation in Germany covers it.

#How to evaluate a development partner

Every proposal promises quality, so ask for evidence you can check. A good partner will be glad you asked.

#Red flags

• A fixed price for a large, vague project without a discovery phase. Someone is guessing, and you pay for the guess in change requests.
• A single figure instead of a range, before anyone has asked about your data, integrations or users.
• No working software until the end. If you cannot click through something within the first few weeks, you cannot tell if the project is on track.
• Senior people in the pitch, unnamed people on the project.
• Repositories, hosting or app store accounts that the supplier will "set up for you" in its own name.
• No questions about your business, your users or your existing systems.
• No automated tests, or tests "planned for later".
• Reluctance to show code, give references or put the plan in writing.

#How to keep costs predictable

Projects overrun when uncertain scopes are priced as if they were certain. You cannot remove the uncertainty, but you can stop paying for all of it at once.

1. Split the work into phases with a fixed scope. A short discovery phase produces a written scope, an architecture and a plan; each later phase delivers a usable release, and you decide after each one whether to continue.
2. Ask for estimates as ranges. An honest early estimate is a range, and it narrows as the scope becomes clearer. A single figure at the start means the uncertainty is hidden somewhere, usually in future change requests.
3. Fix the date and the budget, and let the scope flex. Rank features by value. If time runs short, the least important ones move to the next phase instead of the deadline moving.
4. See working software every week. A weekly release on staging shows progress you can check and surfaces misunderstandings early.
5. Budget for life after launch. Hosting, monitoring, security updates and small improvements are running costs. Agree how they are handled before go-live.

If you are planning a first version, our guide to building an MVP that still works in month nine covers the decisions to make in week one and a four-week plan.

#How Bespoke IT works

Bespoke IT Consultants builds web and mobile apps for companies in Germany, Austria and Switzerland, and places senior engineers in client teams. We work the way this guide describes: senior engineers on the expensive decisions, a written scope before anything is built, a release you can click through every week, tests on every change, hosting in Germany, and code, cloud and app store accounts in your name, with a documented handover your own team can run. If you want a first figure, our estimator gives you an indicative range in about three minutes.