How we work
Five stages, and the fourth is the one that matters
Most of what separates a demo from a system is decided after the demo works. This is the sequence we run, what comes out of each stage, and what it looks like when it is going well.
- Outcome first
- Thin vertical slices
- Evals over demos
- Cost and latency are requirements
- You own the IP, the repo and the models
- No black boxes
The five stages
01
Discover
Frame the outcome, audit data and systems, spike the risky part, size it.
What happens
- Agree the outcome in a sentence, and how we will know it happened
- Audit the data, the systems it lives in and what it is safe to send where
- Build a throwaway spike of the part most likely to fail
- Set a latency and cost-per-run target before anything is designed
- Size the work and name the risks that could change that size
What you get
- Solution brief
- Architecture sketch
- Estimate
- Risk register
What it looks like
On a voice agent, Discover ends with a brief naming the outcome in one sentence, the two systems a transcript has to reach, and a throwaway spike that has already proved the telephony round-trip fits inside the latency target — before anyone has designed a screen.
02
Design
Flows, interface, system and data architecture, agent and model design; prototype the riskiest path first.
What happens
- Map the flows a person actually takes, including the ones that go wrong
- Design the system, the data model and the agent or model behaviour together
- Prototype the riskiest path first, not the most demonstrable one
- Write the evaluation plan while the definition of good is still being argued about
What you get
- Clickable prototype
- Technical design doc
- Evaluation plan
What it looks like
On a retrieval system, Design settles what a good answer is and writes it down as a scored eval set, in the same week the chunking strategy and the reranker are chosen. The prototype answers ten real questions badly, on purpose, so the argument happens before the index is built.
03
Engineer
One-to-two week slices, CI from day one, instrumented as it is built, demo every sprint.
What happens
- Ship thin vertical slices — each one runs end to end
- CI, types and tests from the first commit rather than before launch
- Instrument as we build, so the traces exist the first time something is wrong
- Demo every sprint against the real system, not a deck
What you get
- Working software every sprint, not at the end
What it looks like
A first slice is narrow and complete: one document type, uploaded through the real interface, chunked by the real pipeline, answered by the real model, traced end to end. It is deployed to a staging environment in your account in week one, and it stays deployed.
04
Evaluate & harden
Eval suites, red-teaming, guardrails, latency and cost budgets, load, accessibility and security review.
Most agencies stop at 03. The gap between a demo that impresses and a system that survives is stage 04.
What happens
- Build the eval set from real inputs, and gate releases on it
- Red-team the prompts, the tools and the failure paths
- Hold the build to the latency and cost budget set in Discover
- Load test, accessibility review, security and dependency review
What you get
- Eval report
- Performance budget
- Runbook
What it looks like
The eval set is built from inputs the system will actually see, including the malformed and the adversarial ones, and a release that scores below the agreed bar does not ship. The latency budget from Discover becomes an assertion in CI rather than a number in a document.
05
Launch & operate
Deploy, monitor, iterate on real usage, transfer knowledge.
What happens
- Deploy into your accounts, with your infrastructure as code
- Watch the first weeks of real usage and fix what real users find
- Iterate against the evals rather than against opinions
- Hand over: architecture docs, runbooks and a walkthrough with your team
What you get
- Production system
- Handover pack
- Documented ops
What it looks like
Handover is a working session against the running system, not a document drop: your engineers deploy it themselves once while we watch, and the runbook is corrected wherever they hesitate. The infrastructure is Terraform in your repository, so nothing depends on us being reachable.
How to start
Four ways to work with us
Most engagements begin with the smallest one that answers the open question. You can move between them, and we will tell you when a smaller one would do.
AI Sprint
2–3 weeks · Fixed scope, fixed price
Best for: Is this even feasible?
Request a quote for AI SprintWhat you get
- Working prototype of the riskiest path
- Evaluation baseline you can hold the next phase to
- Architecture and integration plan
- A costed build plan, so the next decision is an easy one
Product Build
6–16 weeks · Milestone-based
Best for: Idea → launched product
Request a quote for Product BuildWhat you get
- Discovery through launch, run as the five stages
- A demo every sprint against the real system
- Evals, guardrails and a performance budget before launch
- Documented handover — architecture docs, runbooks and a walkthrough
Dedicated Pod
Monthly, rolling · Monthly, rolling
Best for: An ongoing roadmap, embedded with your team
Request a quote for Dedicated PodWhat you get
- 2–5 engineers plus design and product
- Working in your tools, your repo and your ceremonies
- One point of contact and a weekly written update
- Scale the pod up or down at a month's notice
Managed & Support
Monthly retainer · Monthly retainer
Best for: It's live and it must stay live
Request a quote for Managed & SupportWhat you get
- Monitoring, alerting and on-call cover
- Model and dependency upgrades, including deprecations
- Iteration against real usage and the eval suite
- An agreed response window, written down
Fixed price where the scope is fixed. Time and materials where the discovery is real. We tell you which one applies before you sign, and we don't do change-order surprises.
Sample timeline
Twelve weeks, laid out
A build with a real integration and a real evaluation bar, from first conversation to a system your team operates. The shape holds; the weeks move.
An illustrative shape, not a project we have run. Every engagement is sized in Discover, and the estimate that comes out of it is the one that counts.
Weeks 1–2
Discover
Outcome, data audit, a throwaway spike of the riskiest part, and a latency and cost target written down before anything is designed.
Deliverable Solution brief, architecture sketch, estimate, risk register
Weeks 3–4
Design
Flows including the ones that go wrong, the system and data model, the agent or model behaviour, and the evaluation plan — written while the definition of good is still being argued about.
Deliverable Clickable prototype, technical design doc, evaluation plan
Weeks 5–9
Engineer
Thin vertical slices, each running end to end in your environment. CI, types and traces from the first commit. A demo against the real system every sprint.
Deliverable Working software every sprint, deployed to staging from week five
Weeks 10–11
Evaluate & harden
The eval set gates releases. Red-teaming on the prompts, the tools and the failure paths. Load, accessibility and dependency review. The latency budget becomes an assertion in CI.
Deliverable Eval report, performance budget, runbook
Week 12
Launch & operate
Deploy into your accounts with your infrastructure as code, watch the first week of real usage, and hand over in a working session rather than a document drop.
Deliverable Production system, handover pack, documented operations
Working together
How we run a project
The part most proposals leave out. None of this is negotiable-in-principle and then quietly dropped — it is how the work is actually done.
Cadence
One weekly call with everyone who can make a decision, and a written update the day before it so the call is spent on decisions rather than status.
Demos
Every sprint, against the running system. Never a deck, and never a recording — if it cannot be demonstrated live it is not done.
Where the work lives
Your GitHub organisation, your cloud accounts, your model provider keys. We work in your repository from the first commit, not in ours.
Access
A shared channel in your Slack or Teams. Questions get answered the same working day; nothing waits for the weekly call.
Reporting
Burn against the estimate, the eval scores, and the latency and cost numbers — the same figures we hold ourselves to, not a separate status colour.
When it slips
You hear it in the update it happens in, with what changed and what it costs. A schedule that only moves at the end was never a schedule.
Start with Discover
Two weeks, fixed price, and you own everything that comes out of it — including the finding that we are the wrong people for the work.
contact@algologix.coWe reply within one working day.