April 6, 2026 · Iridis Engineering
Here is a pattern we see roughly once a month: A company signs a $200K–$500K contract with an AI vendor. Six months later, they have a system that technically works but solves the wrong problem, or solves the right problem with the wrong architecture, or solves everything perfectly except it can’t go to production because nobody checked the data residency requirements.
The contract gets renegotiated. Another $150K. Another three months. The vendor blames scope creep. The client blames the vendor. Both are wrong. The failure happened before anyone wrote a line of code.
The fix is absurdly cheap: spend $5–8K over two weeks on an architecture sprint before you commit to anything. It’s the difference between buying a house after an inspection and buying one from a photo on the internet.
Most AI projects don’t fail because the engineering is bad. They fail because someone made a wrong assumption in a conference room and nobody challenged it.
A 200-person consulting firm came to us wanting to “use AI to automate consultant scheduling.” They had 40 consultants, roughly 200 engagements per year, and a scheduling coordinator who’d been doing it for 11 years. The scheduling wasn’t the bottleneck. The problem was that project scoping happened over email threads with no structure, so by the time scheduling started, half the inputs were wrong. Automating scheduling would have made them produce wrong schedules faster. The actual fix was upstream — structured intake, not algorithmic scheduling.
A Series B healthtech company wanted to fine-tune a model on their clinical notes to generate patient summaries. They’d budgeted $180K and six months. We looked at their data: 3,200 clinical notes, no consistent format, five different documentation styles across their provider network. Fine-tuning would have produced a model that confidently generated plausible-sounding summaries with hallucinated clinical details. What they actually needed was a retrieval-augmented pipeline with structured extraction and a human review step. Cost to build: roughly $45K. Cost of the fine-tuning mistake they almost made: $180K plus whatever a hallucinated clinical summary costs you in liability.
A financial services company wanted real-time fraud detection using LLMs. Real-time meaning sub-200ms response on every transaction. What they actually needed was batch classification of flagged transactions with a 4-hour SLA, which their existing rule-based system was already pre-filtering. The LLM component they needed was a weekly model that re-ranked their rule thresholds based on emerging patterns. Not glamorous. Not “real-time AI.” But it was the system that would actually work within their latency budget and reduce false positives by 30%.
In every case, the wrong assumption wasn’t technical. It was conceptual. And it was baked in before anyone evaluated a single model.
An architecture sprint is not a strategy engagement. It does not produce a slide deck with quadrants and arrows. It produces a technical specification that an engineering team can build from.
Here is what gets delivered at the end of two weeks:
This document becomes the basis for any build contract — with us or with anyone else. The client owns it completely.
The first three days of an architecture sprint are not spent looking at code or evaluating models. They’re spent talking to people.
We interview six to eight stakeholders: the executive sponsor, the team that will use the system, the team that will maintain it, the person who understands the data, and whoever controls the budget. Separately. Never in a group.
The questions are deceptively simple:
What we’re actually listening for is the gap between what the organization says it wants and what it actually needs. The executive sponsor says “we need AI-powered analytics.” The analyst who’d use it says “I need to stop copying numbers from three spreadsheets into a fourth spreadsheet every Monday.” Those are not the same project. One costs $300K and takes eight months. The other costs $15K and takes three weeks.
We also listen for political signals. If two stakeholders describe the same process completely differently, that’s not a data problem — it’s an organizational problem. If the IT team hasn’t been consulted, the deployment timeline is fiction. If the data team says “we have great data” and then takes four days to produce a sample, the data is not great.
Three days of interviews routinely save three months of building the wrong thing.
Most of the architecture is determined by constraints, not choices. This is the part that gets skipped when someone jumps straight to a build contract based on a 45-minute discovery call.
Data residency. Where does the data live? Where is it allowed to live? If you’re a European company processing employee data, the architecture just narrowed to Azure West Europe or AWS Frankfurt and a very specific set of model providers. If you’re in healthcare, you just eliminated most hosted LLM APIs unless you can prove BAA compliance end to end.
Compliance requirements. SOC 2, HIPAA, GDPR, industry-specific regulations. Each one constrains your architecture. SOC 2 means audit logging everywhere. HIPAA means encryption at rest and in transit with specific key management. GDPR means right-to-deletion has to work, which means you need to know exactly where personal data flows in your AI pipeline, including model context windows.
Existing infrastructure. You’re not building on a green field. You have an identity provider, a cloud platform (or three), legacy systems that can’t be replaced, and an ops team that knows Kubernetes but not serverless (or vice versa). The architecture has to fit the infrastructure you have, not the infrastructure you wish you had.
Team capabilities. If your team has two Python developers and no ML engineers, a system that requires ongoing model training and evaluation is not viable. Design for the team you have, plan for the team you’re building toward.
Budget reality. Not the aspirational budget. The actual approved budget. Including ongoing costs, because an AI system that costs $50K to build and $8K/month to run looks very different from one that costs $80K to build and $800/month to run. Both might be the right choice. But you need to know which game you’re playing.
Constraint mapping usually eliminates 60–70% of possible architectures before any technical evaluation happens. That’s not limiting — it’s clarifying.
Sometimes the right answer is “don’t build this.” Three real examples from the past two years:
The fine-tuning that was overkill. A professional services firm wanted to fine-tune a model on 10 years of their consulting deliverables to “capture institutional knowledge.” After examining the data and use cases, we found that 90% of what they wanted was achievable with a well-designed prompt template and retrieval from their existing document management system. Recommendation: $12K RAG implementation instead of $200K fine-tuning project. Annual savings: $35K in model hosting they’d never need to pay.
The data that didn’t exist. A mid-market company wanted predictive analytics on customer churn. Reasonable goal. The problem: their CRM had been used inconsistently for three years. Half the customer interactions were in email threads, a quarter were in a different system their sales team preferred, and the rest were in people’s heads. The “dataset” they described in the initial pitch didn’t exist. Recommendation: don’t build the AI system yet. Invest in data consolidation. Come back when you have 12 months of clean data. We left $150K on the table giving that advice.
The $50/month SaaS tool. A company wanted a custom document classification system. After mapping the requirements, we realized they were classifying roughly 200 documents per week into 12 categories. The accuracy requirement was 90%, with human review on anything flagged as uncertain. Three off-the-shelf tools did exactly this for under $50/month. We recommended one, helped them configure it in a day, and charged for the sprint. Total cost to the client: the sprint fee plus $600/year.
In each case, the sprint fee was the best money they spent.
When the sprint does recommend building, the specification document becomes the foundation of the build contract. This is where the economics flip.
A typical AI vendor estimate comes from a 45-minute call where a solutions architect asks questions and a sales engineer makes notes. That estimate has a margin of error of 50–100%. Which is why build contracts balloon. Nobody’s lying — the information just wasn’t there to estimate accurately.
A sprint-informed estimate comes from 10 days of actual investigation. We’ve talked to the stakeholders. We’ve seen the data. We’ve mapped the constraints. We’ve evaluated the technical approaches and know which one fits. The margin of error drops to 15–25%.
For a $200K project, that difference in estimation accuracy represents $50–$100K of budget risk that simply disappears. The sprint paid for itself before the build starts.
The architecture sprint is good for clients. It’s uncomfortable for vendors. Here’s why:
It gives the client the power to walk away with a document they own and can take to any engineering team. Most AI vendors’ business models depend on converting the discovery call into a six-figure contract. The sprint inserts a decision point where the client has full information and genuine optionality. That’s threatening if your pitch doesn’t survive scrutiny.
It also forces honesty about what AI can and can’t do for a specific use case. A vendor who makes money on build contracts has a structural incentive to recommend building. A sprint that’s designed around a go/no-go recommendation has no such bias.
The sprint model separates evaluation from execution. You can hire the same firm for both — and often should, since context transfer is expensive — but the evaluation stands on its own. It has to, because the deliverable is a document that any qualified engineer can read and validate.
Let’s make it concrete.
| Path | Cost | Timeline | Risk |
|---|---|---|---|
| Skip to build contract | $200–500K | 6–9 months | High — wrong assumptions baked in |
| Sprint, then build | $5–8K + build | 2 weeks + build | Low — assumptions validated |
| Sprint, no build needed | $5–8K | 2 weeks | None — you just saved $200K+ |
The worst case scenario of an architecture sprint is that you spend $8K and get a specification document that confirms your original plan. You’ve lost nothing and gained a detailed technical blueprint.
The worst case scenario of skipping it is a six-figure contract built on assumptions that nobody validated.
One of these is obviously better than the other. The reason it doesn’t happen more often is that nobody’s selling it — because there’s more money in the six-figure contract.
We think that’s backwards. The sprint is where the real value is created. The build is just execution.
15 minutes. No slides. No pitch. Just a conversation about what you’re building.