Software contractor supervision means checking, on the buyer's behalf and at regular intervals, that the work matches the specification after the contract is signed. It rests on three things: measurable milestones, working demos in an environment you control, and scenario-based acceptance testing. Done properly, it exposes drift in the first few weeks rather than on delivery day.
The problem: once the contract is signed, control shifts to the supplier
In most organisations the heaviest effort in buying software goes into gathering quotes and negotiating the contract. After signature things go quiet. The supplier reports that "development is progressing", there is a monthly meeting, a few screenshots are shared. Months later the first real delivery arrives and the team discovers that the reporting screen is not what they pictured, the ERP integration has slipped to "phase two" and nobody ever agreed how user permissions should work.
The cause is rarely bad faith. There was a gap from day one between the work the buyer had in mind and the work the supplier understood, and no one measured that gap as the project went along. Contractor supervision is how you close it before delivery day.
Three situations make supervision hard:
- There is no technical counterpart in-house. The project owner is usually a business unit; nobody on the payroll can judge architecture, code quality or test coverage.
- The specification is not measurable. Requirements such as "user-friendly", "fast" or "secure" cannot be tested at a milestone or at acceptance. We cover this in how to write a testable technical specification.
- Payments are tied to dates, not deliverables. If invoices fall due on a calendar, your project can easily slide down the supplier's priority list.
The cost of not supervising
Projects missing their targets are a common pattern, not an exception:
- BCG's 2020 research, based on a survey of 825 senior executives, found that 70% of digital transformations fell short of their objectives; only 30% met or exceeded their target value and produced sustainable change (BCG — Flipping the Odds of Digital Transformation Success, 2020).
- ERP projects tell a similar story. Panorama Consulting's 2026 ERP Report found that more than a quarter of responding organisations went over budget and almost a quarter went over schedule. The most common reason for budget overruns was an unexpected need for additional technology; for schedule overruns it was organisational issues. In other words, much of the trouble sits in scope and management rather than in the code.
- In Türkiye, the in-house expertise to supervise a supplier is thin. According to the TurkStat ICT Usage Survey in Enterprises, 2026, only 15.2% of enterprises with 10 or more employees employed ICT specialists (10.8% of those with 10–49 employees), and 31.7% of those recruiting ICT specialists reported difficulties.
Read together, the picture is clear: a large share of projects drift, and most organisations lack an internal team able to see that drift technically. Every unsupervised month makes correction more expensive, because a flawed data model or integration becomes costlier with every screen built on top of it.
A seven-step framework for supervising software contractors
The framework works for privately negotiated contracts and for public tenders alike. In Turkish public procurement, the formal inspection and acceptance process under Public Procurement Law No. 4734 still applies; these steps supply the technical substance for that process.
- Split the scope into work packages. Break the specification into independently deliverable packages such as user management, the order module, the ERP integration and reporting. Write down what will be visible when each is complete. If the scope itself is fuzzy, start with a proper software requirements analysis.
- Tie payments to milestones. Each instalment should depend on a work package meeting its acceptance criteria. No single clause does more to shape a supplier's priorities; it is the software equivalent of progress payment tracking in construction, where you pay for work actually completed.
- Ask for demos in your own environment. Not a slide deck or screenshots, but working software in a test environment you can access. Let your own users try it with realistic sample data. Where field users are involved, for example in construction project management software, have the demo run by a real site user on a tablet.
- Get access to the code and the issue tracker. Read-only repository access, open tickets and release notes are the evidence base for supervision. Check the ownership and handover clauses against the checklist in our guide to source code in software contracts.
- Keep a deviation log. At each milestone, record every point that does not match the specification in a numbered list: clause, expected, observed, severity, target close date. A tracked list, not meeting minutes.
- Run change requests separately. If the scope needs to change, use a written request, an impact assessment (time and cost) and a sign-off. "Can we just add this?" decisions are the most frequent source of overruns; our article on software project cost shows how those items grow. The costs that should be planned from the outset across the whole programme are collected in digital transformation cost factors.
- Run acceptance testing scenario by scenario. Write at least one test scenario for every clause in the specification and record the outcome (pass, fail or conditional) in a signed report. Do not forget performance, permission and integration scenarios.
What to check at each milestone
| Area | Question | Evidence |
|---|---|---|
| Functionality | Do the package's requirements actually work? | User trial in the test environment |
| Data model | Do fields and relationships match the specification? | Database schema, sample records |
| Integration | Has the ERP or accounting link been tried with real data? | Integration logs, error scenarios |
| Security | Are roles and permissions defined? | Role matrix, unauthorised-access attempt |
| Code and process | Is the code in the repository, with release notes? | Repository history, ticket records |
| Documentation | Are installation and user guides progressing? | Draft documents |
Do not close the security row by looking at a role matrix alone. For systems handling personal or payment data, write an independent penetration test before go-live into the contract, and make closing its findings one of the acceptance criteria.
Running the milestone review meeting
After each milestone, hold a short meeting with a fixed agenda. Start with the deviations left open last time: closed items are shown in the test environment, and open ones get a new date.
Next, your own users demonstrate the new package while the supplier answers questions. Finally, confirm any open change requests and the scope of the next delivery. The output is an updated deviation log and a definition of the next milestone that both sides have agreed.
This keeps the discussion anchored in written evidence rather than impressions.
Three common mistakes
Relying on the supplier's own status report. A status report is useful, but it is not independent verification. "Done" in the report should match what you can see in the test environment.
Squeezing acceptance into a single day. Leaving every test to delivery day turns all defects into one negotiation. Package-by-package acceptance resolves problems in small pieces.
Separating the business and technical views. The business unit looks at screens and IT looks at servers; nobody asks whether the integration works with real data. Many of the cases in why ERP projects fail happen in exactly this gap.
How we supervise contractors at Digital Bridge
Digital Bridge has built custom software and its own hardware since 2013. Through our IT consultancy service we put that experience on the buyer's side of the table: we represent you, not the supplier, and our recommendations are not tied to any brand or product.
- Before the tender: we turn your needs into written requirements, prepare a technical specification in which every clause can be tested at delivery, and produce a cost estimate broken down by work item. With your legal team we clarify the technical side of delivery criteria, service levels and delay clauses.
- During development: we review each milestone against the specification and report deviations early in a numbered log. We assess the things a business unit cannot see, such as the data model, links between integrated systems and API integrations.
- At delivery: we run acceptance tests scenario by scenario and prepare the signed report.
- The bigger picture: where the project is one of several investments, our digital transformation consultancy produces a roadmap showing which investment comes first and why. The other steps, from planning to purchasing, are in our complete Digital Transformation guide.
Because we run our own development team, we know from the inside how much effort each stage of a custom web software project really takes and which shortcuts cause trouble later. We do not sell packaged products; every engagement starts with a needs analysis and a written proposal setting out scope, phases and fees.
Next step
If you have a project under way, answer three questions this week: have you seen the latest milestone running in your own test environment, is there a numbered list of open deviations, and are payments tied to deliverables or to dates? One "no" is enough to show a supervision gap. If you have not chosen a supplier yet, read our guides on choosing a software company and building a digital transformation roadmap. To review your project together, get in touch; we will go through your current specification and contract and draw up a supervision plan with you.