How We Scoped and Delivered a Custom AI Platform in 3 Weeks

The client is a mid-market financial services firm with 1,200 employees. Their problem: analysts spent 6-8 hours per week searching internal documents, Slack conversations, and Confluence pages for answers that someone in the company already knew. Knowledge was trapped in silos, and the search tools they had (Confluence search, Google Workspace) were keyword-based and missed context.

They'd talked to two Big Four firms. Both proposed 8-12 week discovery phases followed by 16-20 week builds. Estimated cost: $850K-$1.1M. Timeline to production: 6-8 months. The client's constraint: they needed something in production by end of quarter—12 weeks out—and had budgeted $200K. Traditional firms said it couldn't be done.

We said it could, but only if they were willing to work differently. No 6-week discovery. No separate design phase. No handoff to a different team for build. One integrated team, one 3-week sprint, production-first from day one. They agreed. Here's how we did it.

Day 1, we ran a 4-hour scoping session with key stakeholders: CTO, head of analyst team, IT operations, and compliance. We asked: What are the top 10 questions analysts ask most often? What data sources would answer those? What would success look like in 30 days? By end of day, we had a prioritized use case list and success metrics (30% reduction in search time, 80% answer accuracy, sub-5-second response latency).

Days 2-3, we audited their data landscape. They had Confluence, SharePoint, Slack, and an internal wiki. We pulled sample datasets, checked permissions models, and tested API access. We discovered that 60% of valuable knowledge lived in Slack threads and only 20% was in formal documentation. This changed our architecture—we needed to index conversational data, not just documents.

Days 4-5, we built a working prototype. Not a slide deck. Not a proof-of-concept demo with curated data. A functioning RAG system ingesting real Slack and Confluence data, answering real analyst questions, deployed to a staging environment accessible to 5 internal testers. End of week 1, stakeholders could test the system and give feedback. This is the key: production assumptions were validated in week 1, not week 12.

The prototype surfaced issues immediately. Response quality was inconsistent—some answers were perfect, others missed key context. Latency spiked when indexing large Slack channels. The embedding model struggled with financial jargon. These are the problems you want to find in week 2, not week 20 after you've committed to a rigid architecture.

We iterated fast. Switched from a generic embedding model to a finance-tuned model (nomic-embed-finance). Added a reranking step to improve retrieval precision. Implemented caching for frequently-asked questions. Integrated with Okta for SSO and role-based access control. Each fix was tested with real users the same day. Feedback cycles were measured in hours, not weeks.

By end of week 2, the system was production-grade: secure, performant, and accurate enough to trust. Compliance signed off on data handling. IT approved the deployment plan. The internal test group reported 85% answer accuracy and sub-3-second response times. The remaining work wasn't building—it was polishing and documenting.

Week 3 was deployment, monitoring setup, and knowledge transfer. We rolled out to 50 analysts in a phased launch. Set up observability (usage analytics, answer quality tracking, cost monitoring). Wrote runbooks for common issues. Trained the internal team on how to update the knowledge base, tune retrieval settings, and monitor for drift.

We also documented the architecture, data flows, and scaling plan. But here's the difference from traditional consulting: the documentation described a system that was already running in production, not a theoretical design. Every diagram, every API spec, every configuration setting was validated by real usage. There was no gap between design docs and implementation reality.

By day 21, the system was live, the team was trained, and we were in monitoring-only mode. Analysts were using it daily. Average search time dropped from 6 hours/week to 2.5 hours/week. Answer accuracy in production was 82% (above the 80% target). Cost per query: $0.08. The client's CFO called it the fastest ROI they'd seen on any enterprise software project.

This wasn't luck. It was a repeatable playbook. First, ruthless scope discipline. We didn't try to solve every knowledge management problem. We solved one high-value use case (analyst Q&A) and did it well. Scope creep is the killer of fast delivery. We protected scope by defining success metrics upfront and saying no to features that didn't directly serve those metrics.

Second, production-first from day one. No separate prototype phase. No 'we'll harden it later.' The week 1 prototype was built on the production stack with production data and production security constraints. This eliminates the rework that happens when teams discover late that their prototype assumptions don't hold in production.

Third, integrated ownership. The same team that scoped the project built it, deployed it, and handed it off. No strategy consultants defining requirements for a separate dev team. No architects designing systems they won't implement. When the people making architectural decisions are the same people dealing with implementation consequences, decisions get better and faster.

Fourth, tight feedback loops. We didn't wait 8 weeks to show stakeholders something. We showed working software in week 1 and iterated based on real usage. Fast feedback eliminates the risk that you build the wrong thing. It also builds trust—stakeholders see progress weekly, not monthly.

The traditional model says: spend months planning, then execute the plan. The AI-native model says: build something minimal, learn from production, iterate based on data. The difference is philosophical. Traditional consulting treats uncertainty as a risk to mitigate through analysis. AI-native delivery treats uncertainty as information to extract through experimentation.

This changes procurement strategy. Instead of one $1M, 9-month engagement, you can run three $200K, 3-week projects in the same timeframe. You learn faster, derisk earlier, and get more production systems shipped. The capital efficiency is dramatically better, and the organizational learning compounds.

It also changes governance. Instead of steering committees reviewing slide decks, they're reviewing production metrics: usage, accuracy, cost, user feedback. Decisions become evidence-based instead of opinion-based. The conversation shifts from 'do we think this will work?' to 'is this working, and how do we improve it?'

Fast delivery isn't free. It requires client commitment. The CTO and key stakeholders attended every weekly review. IT provisioned access in days, not weeks. Compliance reviewed designs in real-time, not at the end. If your organization can't move at that pace, traditional consulting's slower cadence might be a better fit.

It also requires realistic scoping. We delivered one use case exceptionally well. We didn't try to build an enterprise-wide knowledge graph or integrate 20 data sources. Teams that want to 'do everything' in 3 weeks will fail. The discipline is in choosing the right narrow scope that delivers measurable value.

But if you can commit to fast decision-making, tight collaboration, and disciplined scope, the 3-week delivery model isn't aspirational—it's operational. The playbook works. The results compound. And the organizations that master it are building AI capabilities faster than competitors thought possible.