After ITI AI Concierge moved to an AI Pod, production releases went from 2 in five months to 10 in four, and the monthly budget fell 52%. Large features still wait about a week for client acceptance, and the team now spends more of its time reviewing than writing.
The pod ships faster because it deletes handoffs: relay delivery, where each role passes the baton, became bench delivery, where each builder carries a feature to production and the only shared gate is the client.
What ITI asked for and what changed
ITI AI Concierge is the AI assistant of the International Team for Implantology (ITI), a global community of 25,000+ implant dentistry professionals. It answers members' questions only from ITI-approved sources and cites each one down to the page, with copyright and authors shown.
The short version of the project is our ITI AI Pod case study. This post adds the full numbers and what the model asks of both sides.
In May 2026, ITI asked Netguru for more features for every euro spent, with ITI owning ideation and priorities. The new budget moved four roles off the project within a month, and the AI Pod started on 1 July 2026.
Netguru answered by moving the product to an AI Pod. Relay delivery loses time and context each time a business analyst, designer, developer or QA passes a feature along. In bench delivery, four builders each own a feature from concept to production.
Production releases, delivered work and budget improved. Review, acceptance and client decisions became the constraint.
We recommend bench delivery for one product with a single decision owner who can rule every week, because faster builders still queue at the client's acceptance gate. Where that owner is missing, the saving stalls.
Before and after: the numbers in one table
The team released to production five times as often on about half the budget. We compare February to June 2026 (classic team) with July to October 2026 (AI Pod), with data counted to 22 October.
The windows are unequal (five months against four), so the 5× compares raw counts from one project's delivery data.
Merged PRs and commits are easy to inflate with AI assistance, so they support the picture and closed stories and tasks are the steadier output signal. The same applies to cost per merged PR, which fell 68%. It is a real figure, but it only means something next to the release row.
For a CFO, the budget and release rows carry the case. The rest of this post covers what they cost in review, acceptance and client time.
How the AI Pod team works: each builder owns a feature
An AI Pod on ITI AI Concierge runs on four core builders, each carrying a feature from concept to production. Four roles that used to pass work along (analysis, design, frontend and security) left the project within a month.
The four builders are a PM-orchestrator who also builds, a QA engineer who wrote the automated UI test suite, a backend engineer who also builds frontend and takes features end to end, and an AI engineer. The handoff seats of relay delivery no longer exist.
A tech lead and a DevOps engineer join on demand for direction checks. Neither sits on the core team.
The week has a fixed shape. Four days go to features, and the fifth goes to tests, security, accessibility and cleanup.
AI agents (Claude Code) write most of the code from written specs. People own the intent, the review and the quality.
The roster also depends on someone outside it. Every Wednesday, a 30-minute session shows ITI new concepts as clickable prototypes, and the client gives the green light before the team builds. A separate weekly roadmap sync between ITI's product owner and our PM sets priorities. Four benches move only as fast as those decisions come.
Which handoffs disappeared, and what replaced them
Handoff elimination on ITI AI Concierge meant the baton passes between business analyst, designer, developer and QA were removed, and each builder carries a feature from concept to production. What replaced them is written knowledge in GitHub. We explain the AI Pod model itself in a separate post.
We moved knowledge into the repository before shrinking the team, in this order:
- Handover overlap. Before the team shrank, assignments overlapped as a handover, while the people holding the context were still on the project.
- Code audit. The tech lead audited the codebase and cleaned up the architecture before the team shrank.
- AGENTS.md. Build, test and convention notes went into the repository root, so every agent session starts with the same briefing.
- Rules files. A project constitution and BACKEND, FRONTEND and DESIGN.md files (the last one pointing to Figma) hold the architecture rules that the tech lead and designer used to carry.
- Decision log. Decisions are recorded in the repository, where agents and new people read them.
- Specs. Every feature starts as a short written spec, so scope is agreed before code, and Claude Code with GitHub Spec Kit turns it into a plan, tasks and implementation. The team wrote 109 specs from July to October.
Taking over a feature now takes about an hour. In September a two-week absence on the team still saw 3 releases. One month of field observation is not a guarantee.
Why production releases went from 2 to 10
Production release frequency rose because handoff elimination removed the queues between a finished change and a deployed one. Each builder now carries a feature to production without waiting for the next role in the chain.
The DORA metrics give the sturdier reading: deployment frequency and lead time for changes. After the switch, the median time from a finished code change to production was 6 days. We measure from merge, not first commit, so it understates DORA's full lead time.
The 6-day median blends two different paths:
- Small fix: reaches production within hours.
- Large feature: takes 1-2 weeks from concept to production, of which about one week is UAT at ITI.
Our interpretation is that releases now wait on acceptance, not on code.
The release mechanics changed too. ITI tests and accepts every release in UAT, and production gets a tagged copy of exactly what the client accepted, with release notes. In the first four months that rhythm delivered voice questions, source author credits and four answer modes.
Commits show the same shift. From February to June the team made 5 to 10 commits a week. July went to tuning the new way of working, and from August the count climbed to about 15 to 20 or more a week. We treat commits and merged PRs as supporting evidence only, because they count activity and say nothing about what reached users.
What got harder after the switch
The costs of faster shipping on ITI AI Concierge show up in three places: review, acceptance, and the specialist work that no longer sits on the team.
Review became the constraint. AI agents produce code faster than people can review it, and every reviewer has to understand what they approve.
Acceptance became the UAT bottleneck. About one week of a large feature's 1-2 weeks to production is UAT at ITI, and faster builders do not shorten that week. Open questions also wait for the client's weekly decision.
Specialist gaps surface in audits. With no designer, frontend developer or security engineer on the core team, accessibility rested on the weekly maintenance day until the WCAG 2.2 AA audit in October. The audit found issues, and the first fixes shipped in version 1.3.1.
Ticket data also stopped being like for like. Before the switch, tickets were split into sub-tasks. After it, written specs replaced that breakdown, so Jira counts and the median ticket lead time from the two periods describe different units of work. We leave ticket lead time out of the comparison for that reason.
What we would plan for is that review and acceptance now set the pace. Budget QA and acceptance testing as standing capacity, and agree with the client who runs UAT and how many days a large feature gets.
What keeps quality in check when AI writes most of the code
After the switch, the constraint on ITI AI Concierge moved from writing code to reviewing and accepting it, with client decisions setting the pace. Quality checks had to run on every change.
The guardrails are agent rules in the repository and the spec-first sequence. Each code change gets an AI review, a security and dependency scan, and a check by a person who knows the code. Automated UI tests run on every change, and every release runs end-to-end tests with Playwright.
Answer quality has its own checks. Before each release, Promptfoo runs a clinical test set plus checks for hallucination, out-of-scope questions and red-team attacks. In production, Langfuse traces answers and collects member feedback.
The assistant answers only from passages that retrieval-augmented generation (RAG) finds in ITI's library, built on FastAPI, LangChain and Azure OpenAI, and the platform runs on Microsoft Azure behind a web application firewall, with monitoring.
Every role has to build. QA and the PM ship code alongside the backend and AI engineers, and our QA engineer alone delivered 54 code changes and wrote the automated UI test suite.
That asks a lot of people. Each builder needs an agent licence (Claude Code here), and the team holds a weekly "people programming" session to share practices. The model suits experienced people.
What does an AI Pod need from the client?
An AI Pod needs a named decider on the client side who joins a weekly 30-minute client decision loop, accepts work on staging, and has time reserved for user acceptance testing (UAT).
On ITI AI Concierge, ITI's product owner filled that role, through the Wednesday prototype session and the weekly roadmap sync. Each builder owns a feature from concept to production, so no internal handoff absorbs an open question. Unresolved questions go straight to the client, and the pod waits for the answer.
Part of the budget saving therefore transfers responsibility to the client. Clarifying scope and chasing acceptance used to be spread across roles in the classic team. In the AI Pod, both become client time, and the UAT bottleneck on large features is where that shows up first.
ITI took that on. Philipp Nueesch, ITI's CMO: "I love it, absolutely. I'm proud that we were bold enough to do this as a small, agile organization. It really shows, and the results are great."
Our decision rule, drawn from this one project: adopt an AI Pod only if all three conditions hold.
- A named decider attends the weekly loop and can settle scope questions on the spot.
- That person, or a delegate with equal authority, accepts features on staging.
- UAT capacity is booked before a large feature starts.
If any condition is missing, the path from concept to production stalls at the first open decision, and the lower budget pays for idle builders. Name the decider and the UAT capacity before signing. A client with distributed approval chains may need more than 30 minutes a week, and one engaged client is a narrow sample.
How to judge an AI Pod: release frequency, not pull requests
Judge an AI Pod on production release frequency and time to production, then check whether the vendor's baseline supports the comparison. DORA defines deployment frequency and lead time for changes as the reference measures, and both count only what reaches production.
Put these four questions to any vendor:
- Baseline: Which period is the "before", and did a production pipeline or version tags exist then? Without them, the old release count is a recollection.
- Knowledge: Do specs and agent rules live in the repository, or in people's heads?
- Builders: Can QA and the PM open and merge PRs? If not, handoffs still exist.
- Tickets: Are story sizes and splitting rules the same before and after? Re-slicing changes throughput and lead time without changing delivery.
The ITI AI Concierge numbers come from one product, one client and one team, counted to 22 October 2026. A client with slow decisions or a regulated release process should expect a different result.
Our post on the AI Pod delivery model covers the metrics in theory, and the productized AI Pod service is a different configuration from ITI's.
Conclusion: Staff the gate, then talk to us about an AI Pod
Buy an AI Pod for release frequency and time to production, and staff the gate it exposes.
On ITI AI Concierge, bench delivery moved faster than relay delivery because each builder carried a feature from concept to production with no baton to pass. Every feature still queued at the one shared inspection point: client acceptance and client decisions. Faster benches do not shorten that queue.
Staffing the gate means three things. Name an acceptor with authority to sign off. Hold the weekly 30-minute client decision loop every week. Book UAT time before a large feature starts. Treat review load, UAT time and specialist audits as the price of the model, and plan for them up front.
If your side of the gate is ready, talk to us about an AI Pod.
FAQ
How many people are in an AI Pod?
ITI AI Concierge's AI Pod has four core builders: a PM-orchestrator, a QA engineer, a backend engineer who also builds frontend, and an AI engineer, each owning features from concept to production. The tech lead and DevOps engineer are on call for direction checks and sit outside the core team. The classic team before it had eight people.
How do you keep quality when AI writes most of the code?
Every feature starts as a written spec, and every code change gets an AI review, a security and dependency scan, and a check by a person who knows the code. Automated UI tests run on every change. Before each release, an answer test set checks for clinical accuracy, hallucination, out-of-scope questions and red-team attacks, and Langfuse traces answers in production.
How fast did the team ship after moving to an AI Pod?
Production releases went from 2 in five months to 10 in four. The median time from a finished code change to production is 6 days: small fixes ship within hours, and large features take 1-2 weeks, including about a week of UAT at ITI.
What does the client have to do in an AI Pod?
The client joins a weekly 30-minute client decision loop and runs user acceptance testing on large features. Builders act on those decisions directly, with no handoff chain to absorb a late answer. If the client skips a week, work waits, and the UAT queue grows with it.
What are the downsides of an AI Pod?
On ITI AI Concierge, review became the constraint, large features waited about a week for UAT, accessibility issues surfaced in an audit, not in daily work, and delivery depended on the client's weekly decisions. The pod also asks a lot of a small group, who review and accept more than they write. Choose it when release frequency outweighs those costs.
