Engagement model
From problem to production, clearly
Five phases. Six weeks to a first deployable — a system running in your environment, on your data, measured against a metric we agree in week one. A named deliverable at every step, so you always know what you are getting and when.
At a glance
The six-week timeline
Six weeks is a constraint we impose on ourselves because it forces the decisions that make projects succeed. Removing it reliably makes them fail: scope grows to fill the time, evaluation gets deferred, and the project meets reality months later with untested assumptions stacked on top of each other.
| Step | Phase | Duration | Key activities | Deliverable |
|---|---|---|---|---|
| 01 | Discover | Week 1 |
| Opportunity brief with a baseline, a target metric and a go/no-go recommendation |
| 02 | Architect | Week 2 |
| Technical architecture, evaluation plan and fixed-scope build estimate |
| 03 | Build | Weeks 3–4 |
| Working system in your staging environment, running on your data |
| 04 | Validate | Week 5 |
| Evaluation report with pass/fail against the Week 1 target metric |
| 05 | Deploy & Scale | Week 6+ |
| Production system, full source code, documentation and a trained internal team |
Phases are sequential but not rigid: discovery is contracted separately, and the build phase is only scoped once the architecture and evaluation plan exist.
Phase by phase
What actually happens each week
Discover
Week 1Find the problem worth solving and the number that proves it.
Key activities
- Stakeholder and operator interviews
- Data inventory and access review
- Baseline measurement of the current process
- Opportunity sizing and success-metric definition
Deliverable:Opportunity brief with a baseline, a target metric and a go/no-go recommendation
Architect
Week 2Design the system end to end before writing production code.
Key activities
- Model and retrieval strategy selection
- Deployment topology and security review
- Evaluation harness design
- Cost and latency modelling
Deliverable:Technical architecture, evaluation plan and fixed-scope build estimate
Build
Weeks 3–4Ship working software in weekly increments you can actually use.
Key activities
- Data pipelines and feature/index construction
- Model training, fine-tuning or prompt-program development
- Application and API integration
- Weekly demos against real data
Deliverable:Working system in your staging environment, running on your data
Validate
Week 5Prove the system works before it touches a customer.
Key activities
- Offline evaluation against a held-out gold set
- Shadow-mode or A/B comparison with the current process
- Red-teaming, failure-mode and bias review
- Operator acceptance testing
Deliverable:Evaluation report with pass/fail against the Week 1 target metric
Deploy & Scale
Week 6+Put it into production, then hand over the keys.
Key activities
- Production rollout with monitoring and rollback
- Runbooks, dashboards and alerting
- Team training and knowledge transfer
- Expansion roadmap for adjacent use cases
Deliverable:Production system, full source code, documentation and a trained internal team
Ground rules
Four conditions that make the timeline real
These are in the engagement letter. They are the difference between six weeks and six months, and the first two are where projects actually slip.
-
One use case, fixed
One problem, one success metric. Adjacent requests go on a roadmap for a later engagement, not into this one. This is the rule clients push hardest on and the one that most determines whether six weeks happens.
-
Data access exists before week three
Not "is being arranged" — tested, with a real credential. The most common cause of slippage in this industry is not technical difficulty, it is a provisioning ticket. We will not start a build phase on a promise of access.
-
One decision-maker, available weekly
A named person who can approve a tradeoff within a day. Design by committee does not fit in six weeks; a standing 45-minute decision meeting does.
-
Evaluation before optimisation
No model improvement work until the harness exists. Otherwise "better" is a matter of opinion and the team optimises whatever is most interesting rather than what matters.
What you get either way
-
6 weeks to first deployable
Fixed-scope engagements with weekly demos. You see working software in week three, not a deck.
-
Security & compliance first
Your VPC, your on-prem hardware or fully air-gapped. SOC 2-aligned controls, DPAs, and no training on your data.
-
Owned, not rented
You get the source code, the weights, the infrastructure-as-code and the documentation. No platform lock-in.
FAQ
Questions clients ask before signing
How much does a custom AI engagement cost?
Discovery is a fixed-fee engagement in the low five figures and is deliberately decoupled from the build — you can walk away with the opportunity brief and no further commitment.
A first production deployable typically lands between $75k and $250k depending on data readiness, integration surface and deployment environment. We quote a fixed scope after the Architect phase, so you are never signing a blank cheque against an hourly rate.
Do you really ship in six weeks?
Six weeks is the time to a first deployable — a system running in your environment on your data, measured against the target metric we agreed in week one. It is not the time to a finished product roadmap.
It works because we fix the scope to one use case, run the evaluation harness from week two, and refuse to start a build until data access actually exists. The projects that slip are the ones where we skipped that last rule.
Who owns the code and the models?
You do, outright. Source code, fine-tuned weights, prompt programs, evaluation datasets, Terraform modules and documentation are delivered into your repositories under your licence.
There is no runtime fee, no per-seat charge and no KODA-hosted dependency unless you explicitly ask us to operate the system for you.
Can you deploy on our infrastructure or in an air-gapped environment?
Yes. Roughly half of our deployments run inside a customer VPC, and we regularly deploy fully on-premises — including air-gapped facilities with no outbound network access.
That constraint shapes model selection: air-gapped work means open-weight models served with vLLM or TensorRT on your hardware, and we size that during the Architect phase rather than discovering it late.
What data do you need to get started, and how do you handle it?
For discovery, usually less than you expect: a representative sample, access to the people who run the current process, and whatever measurement of today's performance already exists.
Data is processed under a DPA, inside your environment wherever possible, and never used to train models for other clients. We delete working copies at engagement close and give you the audit trail.
What if the discovery phase says we should not build it?
Then we say so in writing and you have saved several hundred thousand dollars. It happens in roughly one engagement in five.
Common reasons: the data does not exist at the quality the use case needs, an off-the-shelf product already covers 90% of the value, or the process itself should be fixed before it is automated.
How do you support the system after launch?
Every engagement ends with runbooks, dashboards, alerting and a training handover to your team — that is the default, not an upsell.
Optional retainers cover model refresh, evaluation-set maintenance and on-call escalation. Most clients take one for the first two quarters and then run it themselves.
Start with discovery
Fixed fee, one week, decoupled from any build. You leave with an instrumented baseline, a target metric and an honest go/no-go recommendation — including, sometimes, the recommendation not to build.