Build Audit
Understand the build before you commit to the next step.
A scoped engineering review can help you decide what to repair, what to replace, and what to do first. Start by describing the product and the problem.
- Price
- Quoted after review scope is agreed
- Schedule
- Confirmed with the proposal
- Possible deliverables
- Findings, priorities, and next-step recommendations
- First step
- Send a project inquiry
Qualification
Whether this is your problem
Useful when
- You inherited a codebase without a clear technical owner.
- An AI feature behaves differently with real data.
- A build is stalled and the remaining work is unclear.
- You need to compare repair and rebuild options.
A different starting point may help when
- There is no code or system to review yet.
- You need visual design or product research first.
- The task is already narrow enough to implement directly.
The deliverable
Agree what the review needs to answer
The proposal defines the deliverables for your system. A review can include:
- Prioritised engineering findings
- Architecture and dependency observations
- Repair and rebuild options
- Recommended next steps with assumptions
The findings document identifies the area reviewed, the observed issue, supporting evidence, its priority, and the recommended next step. The agreed scope defines which parts of your system are inspected.
Process
From review scope to next steps
- 01Scope
Describe the blocked work
Share the product context, known failures, and the decision you need to make.
- 02Access
Agree the review boundaries
Confirm the required access, confidentiality terms, deliverables, fee, and schedule before a review begins.
- 03Review
Inspect and reproduce
Examine the agreed areas of the system and investigate the behavior behind the reported problems.
- 04Findings
Choose the next step
Discuss the findings, remaining uncertainty, and the options for moving forward.
Why paid
Separate diagnosis from the build decision
A focused review is engineering work with its own scope. It can answer a technical question before a larger implementation is commissioned.
Discuss the proposed outputs and fee first. Sending an inquiry does not commit you to an audit or a subsequent build.
Work
Related client work
Published examples of the software and systems we have worked on for clients.
Engagement
Agree the terms before starting
- The proposal defines the review scope, access needed, deliverables, fee, and schedule.
- Agree confidentiality and data-handling requirements before sharing a private system.
- Review and implementation are separate decisions. Any credits or commercial conditions must be included in the written proposal.
- Confirm ownership, handover requirements, and any follow-up support in the engagement agreement.
FAQ
Build Audit questions
Should I send repository access in the inquiry?
Start with a description and an optional public product URL. Access and confidentiality requirements can be agreed separately. Do not send credentials through the form.
How long does a review take?
The codebase, review questions, and access requirements determine the schedule. Timing is confirmed in the proposal.
Will a review prove the whole system is production-ready?
No review can establish that from a limited scope. The findings should state what was inspected, what was not, and which questions remain.
Does an inquiry commit me to a build?
No. Review and implementation are separate decisions. You can discuss the findings before deciding what happens next.
Contact
Arrange a conversation
Email a short description of your project, or call to discuss the work and arrange a time.
Include what you are building, what needs attention, and any deadline or budget to consider.