Technical audit
A short paid review of the code, the infrastructure and the parts of the process costing the most time.
- Commitment
- [Days or hours]
- Minimum term
- [Weeks, or none]
- How it starts
- [4 to 6 words]
- What you get
- Written findings, ranked
Independent technical practice
The senior engineer you have not hired yet
One person covering the software, the infrastructure it runs on, and the decisions that get expensive to reverse.
- [Reassurance 1: 3 to 5 words. A commitment you are willing to make.]
- [Reassurance 2: 3 to 5 words. A commitment you are willing to make.]
- [Reassurance 3: 3 to 5 words. A commitment you are willing to make.]
- Custom sites & apps
- Workflow & AI integration
- Infrastructure & DevOps
- Developer experience
- Fractional CTO
Position
The case for one engineer
What follows from the same person handling the build, the infrastructure under it, and the advisory work around both.
No handover between specialists
The application and the infrastructure it runs on usually sit with different people, and the gap between them is where a project waits in someone else's queue. Here they sit with the same person.
The reasoning is written down
Architecture choices are handed over with the options that were considered and the reason each was ruled out, so whoever opens the repository next is not reverse engineering the decision.
When this is the wrong fit
A team that already has senior engineering in place rarely needs this. Neither does work that wants an agency with a project manager and a design department. Filling a seat on an existing sprint board is also a poor use of it.
Services
Five areas, usually combined
Listed separately because a decision to bring someone in normally starts with only one of them. Most engagements end up touching more.
-
01
Custom sites and apps
Does the software you need not exist as something you can buy?
- Internal tools and dashboards
- Customer-facing web applications
- Marketing and content sites
- Prototypes and proofs of concept
- APIs and integration layers
Software running in production that matches how the business actually works, with the source, the accounts and the deployment path handed over.
-
02
Workflow and AI integration
Is someone retyping the same information into a second system?
- System-to-system integrations
- Document and data extraction
- Language model features in existing products
- Scheduled reports and alerts
- Approval and exception routing
The repetitive path runs without a person in it, and the cases that genuinely need judgement get routed to whoever should see them.
-
03
Infrastructure and DevOps
Would rebuilding your production environment take longer than a day?
- Infrastructure defined as code
- Build and deploy pipelines
- Monitoring and alerting
- Backup and recovery drills
- Cloud cost review
The environment can be rebuilt from a repository, and the alerts that wake someone at night point at something worth waking up for.
-
04
Developer experience
How long does a new engineer wait before their first merged change?
- Build and test speed
- Local environment setup
- Release automation
- Code review standards
- Documentation that stays current
The slow parts of the daily loop get measured and removed, which usually costs less than the time a team is already losing to them.
-
05
Fractional CTO
Are architecture and hiring questions landing on someone non-technical?
- Architecture and code review
- Technical due diligence
- Hiring and team structure
- Build against buy decisions
- Roadmap sequencing
Someone accountable for the technical direction who is not also the person expected to write every line of it.
One worked example
Hours lost to a manual process
The workflow area is the one part of this that reduces to a number cleanly, so it is the part worth showing. Read it as a single example rather than a description of the whole practice.
The same process, before and after
A request handled by hand, then the same request once the repetitive steps run without anyone in them.
What the manual version costs
Move the sliders to fit your own situation.
hours a week × people × 52 weeks × hourly cost
Cost of the hours per year
$21,840
Saving if 60–80% goes away
$13,100–17,500
What the sliders leave out
The figure above only counts the labour cost of one repeated task. It says nothing about the errors that get corrected later, the days a request spends waiting in an inbox, or the work a team stops doing to keep up with the queue.
Those are usually the larger numbers and none of them fit on a slider, which is a reasonable summary of why an estimate like this is a starting point for a conversation.
Rough figures. The 60–80% saving is a fixed assumption in this widget, and the real number moves with how much of the task needs human judgement.
Approach
How an engagement actually runs
Written out in more detail than is usual, because there are no client case studies on this page to infer it from.
-
Step one
First call
A conversation about what is stuck, what has already been tried, and what it costs to leave it as it is. It ends with a straight answer on fit, including the answer that this is not the right place for the work. [Typical call length: 2 to 4 words, a commitment only you can make.]
-
Week one
Reading before writing
The first week goes on the existing code, the cloud accounts, the deployment path and the history of what has broken. It produces a short written note of what was found and what it implies, which is often the first time all of it has been in one document.
-
Before any building
Written scope
Scope goes in writing first: what is being built, what is deliberately excluded, what it depends on from your side, and how it will be known to be finished. Nothing starts on a verbal understanding of the goal, because that is where most of the disagreements later come from.
-
While the work runs
Visible progress
Work lands in a repository your team has access to from the first day, so progress can be inspected instead of taken on trust. [Update cadence and format: around 15 words. How often you report, in what form, and where. A commitment only you can make.]
-
When it changes
Scope changes
Requirements move once real users touch something. A change gets sized and sequenced against what is already agreed before it is picked up, so the trade against the rest of the scope is visible while there is still time to decline it.
-
At the end
Handover
Handover covers how it runs, how it is deployed, what tends to break first and what to do about it. The target is that someone already on your team can operate it without a call. [Support after handover: around 20 words. What you will and will not do once it ships.]
Engagements
Three ways to buy this
Ordered by commitment, smallest first. The numbers below are the ones only the owner of this practice can set, so they are left blank for now.
Project engagement
A defined piece of work with a written scope, taken from the first call through to something running in production.
- Commitment
- [Days per week]
- Minimum term
- [Weeks]
- How it starts
- [4 to 6 words]
- What you get
- Working software and its handover
Fractional CTO retainer
Recurring time each month for architecture review, hiring input and the decisions that do not fit inside a ticket.
- Commitment
- [Hours per month]
- Minimum term
- [Months]
- Notice period
- [Weeks notice]
- What you get
- Standing time and written recommendations
How pricing works
[Pricing posture, paragraph 1: around 45 words. How you charge rather than what you charge. Fixed price against day rate against monthly retainer, what triggers a re-quote, and whether the audit fee comes off a later project.]
[Pricing posture, paragraph 2: around 30 words. Invoicing terms, expenses, and anything a buyer would otherwise have to ask about on the first call.]
About
Who you would be working with
[About, paragraph 1: around 45 words. Background and the work you have actually done. Left blank deliberately, since inventing this would be a biography neither of us can stand behind.]
[About, paragraph 2: around 45 words. Why you do this work and what kind of problem you take on by preference.]
[About, paragraph 3: around 35 words. What working with you is like day to day.]
Questions
Worth asking early
Including the awkward ones.
Why are there no client names on this site?
[Answer, 40 to 90 words. The honest reason. Whether the work was under NDA, in-house, or too recent to name, and what you can offer instead of logos.]
How does pricing work?
[Answer, 40 to 90 words. Fixed price against day rate against retainer, what changes the number, and what a buyer should expect to be quoted before anything starts.]
What is the smallest engagement you will take?
[Answer, 40 to 90 words. The floor, in hours or days or money, and why a floor exists at all.]
What happens if the work is not going well?
[Answer, 40 to 90 words. How it gets raised, what the exit looks like, notice period, and what happens to work already paid for.]
Can you work alongside an existing team?
[Answer, 40 to 90 words. How you slot in around in-house engineers, whose tools and process win, and how code review works in that arrangement.]
Who owns the code and the cloud accounts?
[Answer, 40 to 90 words. Ownership of the repository, the infrastructure and any third-party accounts, and when it transfers.]
What do you not take on?
[Answer, 40 to 90 words. The work you turn down. Being specific here is worth more than another paragraph about what you can do.]
Contact
Send the problem as it stands
A short description of what is stuck and what has already been tried is enough to work out whether this is a fit. No brief required.
[Contact email: not yet created, drop it in here]
[Response time: 3 to 6 words. A commitment only you can make.]