An invoice, a summary, and not much else
Each month the invoice arrives with a short summary: bug fixes, improvements, work on the new module. The hours look plausible. But when you ask what exactly was fixed, the answer takes a few days and is hard to follow. The new module has been in progress for a while and you have not seen it.
You are not accusing anyone of anything. You simply cannot tell whether you are getting good value, because you have no way to see the work.
Why visibility disappears
- The code lives in the supplier's own repository, so you cannot see commits or changes.
- Tickets are tracked in their internal system, not yours.
- Nothing is deployed anywhere you can reach until a big release.
- Reporting is written for invoicing rather than for decision making.
- Nobody on your side has the time or technical background to ask sharper questions.
Most of this is not deliberate. It is simply how the supplier finds it convenient to work. But the result is the same: you are paying for activity you cannot inspect.
What not seeing it costs
| Risk | Consequence |
|---|---|
| Unclear value | You cannot tell good work from slow work |
| Late surprises | Problems appear only at a big release |
| Weak position | Changing supplier is hard when you do not hold the code |
| Security | You do not know who has access to what |
| Priorities drifting | The team works on what is easy, not what matters most |
Unclear value also makes budgeting hard. When a board member or finance lead asks what the development spend delivered this year, you want to point to features, fixes and their effect on the business. A pile of summaries that say improvements and bug fixes does not make that case.
The weak position is the one that lingers. A supplier holding your code and your accounts holds a lot of power over you, even if they never use it.
How we make development work visible
This is how we run our own engagements, and we can help you put the same structure in place with another supplier.
- Code in your repository. GitHub, GitLab, Bitbucket or Azure DevOps, owned by your business. Every change arrives as a pull request with a description you can read.
- Tickets in a tracker you can see, such as Jira, Linear or GitHub Issues, with each ticket linked to the code that addressed it.
- A staging site you can use. Features appear there as they are built, not all at once at the end, so you can try them.
- Short written updates in plain language: what was finished, what is in progress, what is blocked, and what decisions are needed from you.
- Time linked to outcomes. Hours are reported against tickets or features, so you can see what each piece of work took.
- Regular demos, kept short, where the developers show working software rather than slides.
If you are not technical, we write updates for you, not for developers. If you want someone independent to read the pull requests and tell you what they mean, we can do that too.
With visibility in place
You can open the tracker and see what is happening this week. You can click through new features on staging before they go live. Invoices line up with work you can see. And because the code and tickets sit in your accounts, you can bring in another developer or supplier whenever you choose.
Check your own situation
- You receive invoices but struggle to connect them to finished work.
- The code is hosted in the supplier's account, not yours.
- You only see new features at large releases.
- Asking for detail takes days to get an answer.
- You would find it hard to switch supplier tomorrow.