Software Due Diligence Before Scaling Delivery

A product can look healthy from the outside while the engineering reality is held together by one developer, undocumented integrations and a deployment process nobody wants to touch. Software due diligence is how you find that out before you commit budget, take on a supplier, acquire a business or scale a technical team around the wrong foundations.

For founders, product leaders and operational teams, the objective is not to produce a thick report full of theoretical concerns. It is to answer a commercial question: can this software support the next stage of the business at an acceptable cost and risk?

That question matters whether you are buying a SaaS company, inheriting a legacy platform, appointing a development partner or adding engineers to an existing team. The right review shows what is working, what will slow delivery down, and what needs fixing first.

What software due diligence should establish

A useful review gives decision-makers a clear view of delivery risk. It should establish whether the system is maintainable, secure enough for its use case, deployable without heroics and understood by more than one person. It should also expose whether the roadmap being promised is realistic with the current codebase, team and budget.

This is not the same as asking a supplier whether they use React, .NET, Laravel or Python. A modern stack can still be poorly structured, lightly tested and dependent on ageing third-party services. Equally, an older application is not automatically a liability. A stable legacy .NET system with clear boundaries, reliable monitoring and knowledgeable engineers may be a safer investment than a fashionable rebuild with no operational discipline.

The outcome should be practical. You need a prioritised list of risks, an estimate of the likely effort involved, and a recommendation on whether to proceed, renegotiate, stabilise or rebuild selected areas.

Start with the business case, not the repository

Technical teams can spend days inspecting code without answering the question the buyer actually has. Set the scope before anyone opens a repository.

If you are acquiring a business, focus on risks that could affect valuation, customer retention, regulatory exposure and post-deal integration. If you are hiring an embedded engineer or outsourcing a build, focus on speed to productivity, ownership, quality controls and the cost of getting the work into production. If you are modernising an internal platform, prioritise continuity of service, data migration and the systems that block operational change.

Ask what the software must achieve in the next 12 to 18 months. It might need to support twice the transaction volume, meet a customer security requirement, replace a manual back-office process or enable a new AI workflow. Those needs determine what deserves close inspection. There is little value in criticising a minor front-end inconsistency if the real commercial risk is a database that cannot be backed up or a payment integration with no failure handling.

Review the codebase for maintainability, not perfection

Every established codebase has shortcuts. The question is whether those shortcuts are contained and manageable, or whether they make ordinary changes unpredictable.

A review should look at application structure, module boundaries, duplication, dependency management, test coverage and the ease of making a typical change. Readability matters, but it is not enough. A clean-looking codebase may still have poor domain modelling, hidden coupling and no meaningful automated tests.

Pay particular attention to areas where knowledge is concentrated. If only one person understands how billing works, how customer data is synchronised or how production releases are handled, that is a delivery risk even if the code itself is sound. Check commit history and pull request practices too. They often reveal whether the team has a review culture or whether changes have been pushed directly into production under pressure.

Do not treat a low test percentage as an automatic rejection. Some systems are hard to test retrospectively, and a high headline percentage can hide weak tests. What matters is whether critical paths are covered: authentication, payments, permissions, data changes, core calculations and the workflows that generate revenue.

Check how software actually reaches production

Many delivery problems sit outside the codebase. A business may have capable developers but still lose weeks to manual releases, missing environments and unclear approval steps.

Assess the route from a ticket to a live release. Is source control in place? Are builds and deployments automated? Is there a separate test environment? Can the team roll back a failed release? Are changes observable once they are live?

You also need to see how incidents are handled. Look for logs, error tracking, uptime monitoring, alert ownership and a process for recording what went wrong. Without these basics, engineering time gets consumed by guesswork. The first sign of trouble may come from a customer rather than the team responsible for the platform.

For a fast-moving startup, the answer does not need to be enterprise ceremony. It does need to be repeatable. A lightweight pipeline, sensible access controls and clear release ownership are usually more valuable than a long policy document nobody follows.

Test security and data exposure against reality

Security diligence should match the type of data, the sector and the customers involved. A consumer prototype and a platform handling financial or health-related information deserve different levels of scrutiny. Neither should rely on assumptions.

Review where data is stored, who can access it and how access is removed when people leave. Check authentication, role-based permissions, encryption, secrets management, audit trails, backups and the process for applying security updates. Third-party services deserve attention as well. A product may have sound internal code but expose customer data through an over-permissioned integration or an abandoned cloud account.

Do not stop at a checklist. Ask for evidence. Can the team demonstrate a restore from backup? Can they show which accounts have production access? Can they explain how a vulnerability would be identified, prioritised and fixed? Clear answers suggest operational control. Vague reassurance usually means work is needed.

Examine the people and delivery model

Software is maintained by people, not repositories. This is where many reviews fail: the buyer assesses the technology but ignores whether the team can continue to deliver.

Identify who owns the architecture, infrastructure, product decisions and customer-critical integrations. Understand their availability, notice periods and whether they are employees, contractors or an external agency. If a supplier is involved, establish who does the work day to day and who remains accountable when delivery slips.

A sensible delivery model gives you direct access to the engineers doing the work, visibility through your existing tools and regular reporting on progress and blockers. It also avoids tying essential knowledge to a single agency account manager. For businesses adding capacity quickly, embedded senior engineers can be lower risk than a closed outsourced team because product context, priorities and technical decisions stay visible inside the business.

Tender Software works on this basis: senior offshore engineers integrate into the client team, with UK-side accountability and flexible monthly terms. That model does not remove the need for diligence. It makes the answers easier to verify through direct communication, sprint participation and a trial period before a larger commitment.

Turn findings into a costed decision

The final output should not be a fear-inducing catalogue of flaws. It should separate immediate risks from improvements that can wait.

A useful prioritisation has four levels:

• Critical issues that threaten security, legal obligations, revenue or service continuity.
• Near-term delivery blockers that make planned work slow, expensive or unreliable.
• Maintainability improvements that should be scheduled alongside roadmap work.
• Nice-to-have refinements that have limited commercial impact for now.

For each material issue, assign an owner, likely effort, dependency and consequence of doing nothing. Avoid false precision. A range such as two to four engineering weeks is more honest than an exact number where the underlying discovery work has not happened yet.

This is also where diligence affects price and timing. If a proposed acquisition includes £150,000 of deferred platform work, that should inform valuation and integration planning. If an agency promises a six-week build but the current system has no test environment or deployment pipeline, the estimate needs challenging. If the risks are manageable, do not delay progress waiting for a perfect architecture. Agree the stabilisation work, fund it properly and sequence it around customer value.

When a light review is enough

Not every decision requires a full technical audit. For a small, low-risk prototype, a focused review of code ownership, deployment access, data handling and critical dependencies may be enough. You are looking for obvious traps before moving quickly.

A deeper assessment is justified when the software supports significant revenue, processes sensitive data, underpins an acquisition, has suffered repeated incidents or will be handed from one team to another. The potential cost of getting it wrong is higher, so the review needs to go beyond surface-level stack checks.

The best time to carry out software due diligence is before a contract is signed or a roadmap is promised. By then, you still have options: change the scope, adjust the price, retain key people, ring-fence risky components or choose a different delivery approach. That is the point of the exercise. Get clear on the condition of the software, then make the commercial decision with your eyes open.