Technical judgement on your side of the table
You run the business. You are not going to learn to read code, and you should not need to. We assess the technical work on your behalf and report what it means in terms you can act on.
You are not short of information. You are short of a means to verify it.
You receive updates. They are detailed, they are confident, and you have no way to test a single statement in them. In most cases this is not a problem, because most developers report honestly. The difficulty is that an honest but slow team and a team managing your expectations produce an identical status report.
Who this is for
- You have been told the work is 90% complete, and it has been 90% complete for a month.
- Every delay arrives with a reason, and every reason sounds plausible.
- You cannot establish whether a task is genuinely difficult or simply being treated as such.
- You are paying for a team you have no means of evaluating.
- A supplier proposal is in front of you and you cannot assess whether the price is reasonable.
- You have inherited a system and nobody can tell you what condition it is in.
How the engagement works
We do not replace your team, your supplier or your judgement. We give your judgement something to work from.
Review
We examine what exists, not what is reported
The codebase, the repository history, the ticket history and the deployment record. How frequently anything reaches production, how long a change takes from started to live, and which areas have been rewritten more than once. These are matters of record. A status meeting is not.
Report
You receive it in plain language
One page. What is complete, what is genuinely underway, what has not started, and which of the stated reasons hold up. No architecture diagrams and no terminology you would have to look up.
Questions
We tell you what to ask and what a sound answer looks like
Ahead of your next meeting with the team you receive three or four specific questions and the range of answers that would be reasonable. This is the part that changes the dynamic, because a specific question cannot be answered with a general statement.
Attendance
We attend the meetings that matter
Estimate reviews, proposal reviews, and the discussion in which a deadline moves. You do not have to relay anything technical, and the team is addressing someone able to verify what is said.
What you receive
Short, regular and written for you rather than for an engineer.
An opening assessment
The condition of what you have: what works, what is fragile, what would be expensive to change later, and what it would cost to put right. Delivered within the first two weeks.
A one-page review each week
What actually progressed, measured against what was stated the week before. If nothing progressed, the report says so.
The questions, in advance
Ahead of estimate reviews, proposals and any discussion in which a date is likely to move. Specific enough that a vague answer is recognisable as one.
What this engagement is not
The arrangement only works if your team does not experience it as a threat.
| Your developers and your supplier | Remain in place |
|---|---|
| Hiring and dismissal decisions | Yours. We do not offer recommendations unasked |
| Writing the code | Still them, not us |
| Reviewing and assessing the work | Us |
| Explaining it to you | Us |
| Deciding what to do about it | You |
Comparable work
On EasyCEP Garaj we worked from this side of the table, supporting the backend work their own developers were carrying out. We have been on both sides of this arrangement: we build products ourselves, which is why we know what a reasonable estimate looks like and how long work genuinely takes.
EasyCep Garaj
A full-stack commerce build, storefront through to operations.
Frequently asked questions
How do I know whether my developers are making genuine progress?
Not from the status report, because a report is a claim. Look instead at the records produced as a by-product of the work: how often code reaches production, how long a change takes from started to live, whether the same area is repeatedly rewritten, and whether you can open and use what is described as finished. If you are not technical, someone has to read those records on your behalf. That is what this engagement provides.
My developer says the work is nearly finished. How do I verify that?
Ask to use it, on a machine that is not theirs, performing the task a real customer would perform. A claim of "nearly finished" that cannot survive that request usually means the remaining work is the part nobody estimated: error handling, edge cases and the behaviour that only appears under real data. That final stretch routinely takes longer than everything preceding it, and it is where most projects lose a quarter.
Can you review the work of a team we have already engaged?
Yes, and that is the most common case. We need read access to the repository and the ticket system. We do not require your team's permission to be useful, but we do inform them we are involved, because a review nobody was told about produces a defensive team and poorer information.
Will this make my developers defensive?
Less than you would expect, provided it is framed correctly. Competent engineers are usually relieved: they have been attempting to explain a real constraint to someone with no way to evaluate it, and now there is someone present who understands the argument. Those who object are generally objecting to being reviewed, which is itself informative.
Is this a fractional CTO service?
There is overlap, but the remit here is narrower and more concrete. A fractional CTO sets technical strategy and frequently takes over the team. We are not taking over your team and we are not writing a three-year technology plan. We review the work being carried out for you and report what is true about it, so that you continue making the decisions you were already making, with better information.
How much of my time does this require?
Approximately thirty minutes a week to read the report and raise anything you want to raise, plus whichever meetings you would like us to attend. The purpose of the arrangement is to remove work from your week, not to add a second reporting line to it.
Related reading
Software Accessibility: Audit, Priorities, and Remediation
A practical guide to software accessibility covering priority journeys and technical constraints, risk, measurement, and clear next steps.
Database Migration Checklist: Planning, Testing, and Rollback
A practical guide to database migration checklist covering priority journeys and technical constraints, risk, measurement, and clear next steps.
App Performance: Metrics, Bottlenecks, and an Improvement Plan
A practical guide to app performance covering priority journeys and technical constraints, risk, measurement, and clear next steps.
How to Modernize an Existing Mobile App Without Losing Users
A buyer-focused guide to mobile app modernization: planning a coherent first release, managing risk, and learning how to sequence experience, platform, backend, analytics, accessibility, and release changes around continuity.
Send us what you have been told
Send the most recent status update you received. We will tell you what it does and does not establish.
Building the product for what comes next
We would rather deliver one product that holds up than three that have to be rebuilt. That standard is the same on every project, whatever its size.
Ali Boran GazelCEO