Riskiest path first
We build the one part that could kill the idea — the extraction that must be right, the retrieval that must find the obscure document — and skip the login screen.
Narrow vertical sliceAI & data
Prove it works before you fund it
A four-week, fixed-scope build that turns one uncertain idea into a running system on your own data, a measured result, and a written recommendation on whether to keep going.
- Fixed scope
- 14 days to demo
- Full IP transfer
- 30-day warranty
What a PoC is actually for
A PoC answers one question: can this be built, on your data, well enough to matter. It is not a small product and it is not a design mockup. It is a narrow vertical slice of the hardest part of the idea, run end to end, on inputs that look like the ones you get on a bad day. Everything else — auth, admin screens, polish — is stubbed on purpose.
The familiar failure is a pilot that demos well and never ships, and the cause is rarely the model. It is that the demo ran on twenty hand-picked examples, nobody agreed in advance what counted as good enough, and the thing that eventually broke — data access, latency, cost per case — was never in scope. So we set the pass mark before any feature work, and the engagement ends in a written decision rather than a renewal conversation. A PoC that fails cheaply in four weeks is a good outcome.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| Four weeks, fixed scope | One question, not a backlog | Kill criteria written in week one |
| Security clearance outruns the clock | Work starts before live access | Synthetic first, live re-run before sign-off |
| One domain expert, part-time | Labelling is the scarce resource | Hundred-case set, rubric captured once |
| Demo data is not production data | Happy-path scores overstate real readiness | Long-tail inputs in the scoring set |
| Agentic loops multiply token spend | Demo cost misleads the budget | Cost and latency metered per case |
In scope
- One falsifiable question, end to end
- Labelled scoring set and grading rubric
- Narrow vertical slice on real data
- Cost, latency and failure measurement
Not in scope
- Authentication, roles and audit trails
- Production hardening of the passing slice
- Ongoing operation after the decision
Handled by
- MVP Software DevelopmentTurns a passing slice into a shippable product.
- Maintenance & SupportRuns and monitors the system after cutover.
What we build
Scored evaluation harness
A repeatable run over labelled cases from your own systems, pass or fail per case rather than a vague quality score. It fires on every change, so regressions surface immediately.
Evaluation harness in CIUnit economics measured
We instrument the run so you know cost and latency per transaction before committing. Agentic loops and retries make production bills diverge from a demo, and that number belongs in the decision.
Cost per transactionData access under constraint
When legal cannot clear live records in time, we work from an anonymised extract or a schema-faithful synthetic set, and mark every conclusion provisional until the live run happens.
Anonymised data extractDemoable interface
Enough front end that a domain expert or a board member can drive it themselves and form their own opinion. Thin, deliberately unpolished, and honest about which parts are stubbed.
Driveable demo buildProduction path costing
A written estimate of what makes the passing slice real: integration work, failure handling, review workflow, security posture. Priced separately, so the go decision carries a number.
Production build estimateHow the work runs
- 01Week 1
Frame the question
We reduce the idea to a single falsifiable question and write the number that settles it — accuracy on a named task, a latency ceiling, cost per case. We also write the kill criteria.
You getOne-page scope and kill criteria
- 02Weeks 1–2
Build the scoring set
We pull real cases from your systems, including the awkward ones, and sit with whoever knows the correct answer until each is labelled. Where judgement is subjective we capture the reasoning, so grading can be automated.
You getLabelled test set and rubric
- 03Weeks 2–4
Build and stress
We build the narrow end-to-end path against real data and run the harness daily. By day fourteen you can drive the demo yourself. Then we attack it: bad scans, missing fields, adversarial phrasing, load.
You getRunning demo and failure log
- 04Week 4
Call the decision
We hand over the repository, the harness and the numbers, then write a recommendation: go, stop, or reshape the question. If it is go, the production build is costed in the same document.
You getGo or no-go memo
What you are handed
- Running end-to-end demo on your data
- Labelled scoring set you keep
- Evaluation harness wired into CI
- Cost and latency per transaction
- Failure log with named root causes
- Written go or no-go recommendation
- Production build estimate and architecture sketch
- Full source repository and IP transfer
- Recorded walkthrough for stakeholders
Typical stack
Slice runtime
Python + FastAPITypeScript + NodeNext.jsStreamlitDocker Compose
Data & retrieval
Postgres + pgvectorQdrantDuckDBUnstructureddbt
Evaluation
pytestPromptfooRagasLabel StudioLangfuse
Ship & measure
GitHub ActionsFly.ioRenderVercelOpenTelemetry
The calls we make, and why
Should the PoC code become the production system?
No — the harness survives, the slice is scaffolding.
What carries forward is the evaluation harness, the scoring set and the data contracts. The slice itself was built to answer a question fast, and rewriting it against real requirements is cheaper than untangling decisions made under a fortnight’s pressure.
We’d choose otherwise whenthe slice is a narrow backend service with a stable contract and no front end.
Do we need to fine-tune a model, or is retrieval enough?
Retrieval first — it keeps the failure legible.
Fine-tuning locks you to one model generation and hides whether the failure was missing knowledge or weak reasoning. Retrieval leaves that distinction visible, which is the whole point at PoC stage, where you are diagnosing the problem rather than optimising a solution.
We’d choose otherwise whenthe task is narrow classification with thousands of labelled historical examples already in your database.
Should we buy an off-the-shelf tool instead of proving this ourselves?
Buy first if a vendor already covers the workflow.
When your only real question is fit, a two-week bake-off against the same scoring set answers it far cheaper than a build. Build the PoC when the differentiating logic is yours — your taxonomy, your judgement rules, your data joined in a way no vendor sees.
We’d choose otherwise whenthe vendor cannot legally hold your records, or you want the vendor scored as a harness baseline.
One PoC on the big idea, or three small ones?
One PoC, one named budget holder, one result.
Three shallow PoCs across departments are how pilot fatigue starts: each demos well, none has an owner, and by the third nobody believes the format. Depth beats breadth when the point is a decision that somebody has to live with and defend.
We’d choose otherwise whenthe underlying capability is shared and you are genuinely comparing use cases, not hedging.
This fits if
- One technical unknown is blocking a much larger investment decision
- A budget holder is waiting on evidence before approving a build
- You can supply real data and one domain expert
- The idea has been argued about internally without anyone testing it
- You want the option to walk away after four weeks
Look elsewhere if
- The PoC is procurement theatre and the vendor is already chosen
- You need a polished investor demo rather than measured evidence
- No data access, no domain expert, no decision maker
EngagementFixed-price PoC sprint
Typical lengthFour weeks, fixed
How it startsSend the one question you need answered and a data sample; we return a written scope and price.
Questions we get asked
What does a PoC cost, and why is it fixed price?
PoC Development at AivoraLabs is priced as a fixed fee against a fixed scope, agreed before work starts. Fixed price works here because the scope is one question rather than a feature list, and the timebox is the control: if four weeks cannot answer it, more weeks rarely will. Inference and hosting costs are itemised separately and capped.
Who owns the code and the data we hand over?
You own all of it. Source code, the labelled scoring set, prompts, configuration and documentation transfer to you in full at the end of the engagement, in your repository and under your accounts. Your data is used only to run your PoC, and model provider access runs under no-training terms. Handover includes a thirty-day warranty on defects.
What happens if the PoC fails?
You get the same deliverables and a documented reason, which is the point of running one. A no-go memo names what broke, at which stage, and what would have to change — better data, a different task boundary, a tolerance for human review — for the answer to flip. The fee is not contingent on a positive result.
Are we locked into your stack or your hosting?
No. The PoC runs on open components and standard interfaces, in your cloud account where you have one, and every external dependency is listed with a named alternative. Model access sits behind a thin routing layer, so swapping providers is a configuration change, though the scoring set has to be re-run to confirm the swap held.
How much of our team’s time does this take?
Roughly a day a week from one domain expert, concentrated in the first ten days. That person labels the scoring set and settles disagreements about what a correct answer looks like; nobody else can do it for them. We also need someone who can approve data access early, because a stalled security review is the usual reason the clock slips.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.