What you receive at each stage
Open a stage to see the work, its output, and the decision it supports. A sprint or audit can stand on its own; a full build takes the work through deployment and handoff.
1Define the outcome
We identify the user decision, available data, failure costs, product constraints, and what measurable success would look like. The goal is a testable problem, not “add AI.”
- Input
- Problem context, representative data, current system
- Output
- Problem framing, constraints, acceptance criteria
- Decision
- Sprint, audit, build, narrower scope, or no-go
2Prove the riskiest assumption
I run the smallest credible test against representative conditions. For video AI, that may be footage quality, tracking stability, temporal reasoning, or deployment speed, not just model accuracy on a clean sample.
- Method
- Focused spike, benchmark, data audit, or failure analysis
- Output
- Results, examples, failure modes, and open risks
- Decision
- Proceed, reframe, collect data, or stop early
3Design the system and milestones
The evidence becomes a delivery plan spanning data, annotation, models, domain logic, evaluation, serving, product integration, and operational ownership. Milestones are defined by accepted behavior, not activity.
- Scope
- Deliverables, interfaces, exclusions, and dependencies
- Milestones
- Acceptance criteria with demos and measurable gates
- Commercials
- Bounded price or staged proposal before work begins
4Build, measure, and demonstrate
I deliver working increments and keep the system observable as it grows. You see the current behavior, metrics, trade-offs, and next risk at each milestone, not only a written progress report.
- Visibility
- Working demos, metrics, and concise technical updates
- Control
- Shared code, decision log, and explicit scope changes
- Quality
- Representative evaluation and regression checks
5Harden, deploy, and transfer
“Done” includes the system around the model. I validate edge cases, latency, throughput, infrastructure cost, licensing, failure handling, monitoring, documentation, and the team’s ability to operate it.
- Delivery
- Production code, configuration, tests, and documentation
- Handoff
- Architecture walkthrough and operational knowledge transfer
- Aftercare
- An agreed support window and a clear next-step backlog
This process in practice: AIM
For AIM, the work connects data and annotation, perception, temporal models, biomechanics, scoring, optimized inference, and the final coaching visualization.
One minute of 720p footage is analyzed in about seven seconds on a single cloud GPU. The case study covers the system and the measurement conditions.
Read the AIM case studyBefore we start
What do I need before the first call?
A clear description of the product problem is enough. Representative data, footage, architecture notes, or current metrics help, but they are not required for the first conversation.
Can you work with an existing team and codebase?
Yes. I can work inside an existing product and engineering team as long as technical ownership, interfaces, access, and decision-making responsibilities are explicit.
What happens if the feasibility evidence is negative?
A well-supported no-go or narrower recommendation is a useful result. We stop or change direction before committing a larger budget to the wrong approach.
How are scope and pricing handled?
Small engagements use a clearly bounded scope and price. Larger builds are divided into accepted milestones, paid one at a time; you can stop after any milestone and keep everything delivered. Any material scope change is discussed and agreed before the work changes.
Where is your project today?
Send me the goal, the data you have, and the part you’re uncertain about. I’ll reply personally within one business day.