The 2-4 Week Delivery Model: How I Scope AI Projects to Ship Fast

The first thing most people ask when I tell them I deliver in 2-4 weeks is: "What are you leaving out?" It's a fair question. Traditional AI consulting projects routinely run 3-6 months, sometimes longer. The assumption is that speed means shortcuts, and shortcuts mean fragile systems that fall apart the moment someone feeds them an edge case.

That assumption is wrong. I want to explain why. Not to sell you something, but because I think it's genuinely worth understanding what separates a fast project from a reckless one.

Why Traditional AI Consulting Takes So Long

The honest answer is not technical complexity. Most AI implementations for law firms, insurance carriers, and compliance teams involve a bounded set of well-understood problems: extracting structured data from documents, routing items based on content, surfacing relevant precedents, flagging anomalies. These are solved problems. The technology is mature.

What actually consumes time in a typical engagement is process overhead: multiple stakeholders who need to align before any work starts, weeks of requirements gathering conducted by people who won't write the code, lengthy procurement cycles, and a handoff from a sales team to a delivery team to a junior team who will do the actual work.

I don't have any of that. There is no sales-to-delivery handoff because I am both. There is no junior team. There are no steering committee meetings where a project manager summarizes what the engineers told them last week. When you talk to me, you're talking to the person who will build the system.

That's not a pitch. It's the mechanism that makes the timeline possible.

What Actually Happens in Week One

Discovery is not a two-week workshop. It's a structured set of conversations and hands-on investigation that I can complete in a few days if the client is engaged.

On day one or two, I want to understand three things. First, what is the specific workflow that is breaking down? Not "we have document management challenges" but "intake coordinators spend four hours a day extracting coverage limits from endorsement pages and entering them into PolicyCenter, and they make errors about 8% of the time." That level of specificity is what makes scoping possible.

Second, what does the data actually look like? I ask to see real documents, real system screenshots, real output files. Not sanitized samples, but the actual messy inputs that hit the system on a Tuesday afternoon. The shape of the data determines the approach far more than the abstract problem description does.

Third, what does success look like, and who decides? If I build something that extracts coverage limits with 97% accuracy but the team needs 99.5% to trust it for straight-through processing, that matters before I start, not after I finish.

By the end of the first week, I have a written scope document that names the exact workflow, the exact inputs and outputs, the success criteria, the edge cases we will and will not handle in v1, and the definition of done. That document is the foundation of everything else.

The One Workflow Rule

The single most reliable way to kill a fast project is to let the scope expand during implementation. And it will try to expand. Every stakeholder has another thing they would love to automate while we're in there. Every demo surfaces a related problem that "would only take a day."

My default position is: one workflow, one system, one set of success criteria per engagement. Not because I can't build more, but because doing one thing well is worth more than doing three things adequately.

This is the "one workflow" rule, and it requires discipline on both sides. My job is to hold the line on scope. The client's job is to trust that a working v1 is better than a theoretical v2 that ships six months from now. In practice, the best clients understand this intuitively. They've been burned by big consulting projects that delivered something technically impressive but operationally useless.

The one workflow rule also makes testing meaningful. When scope is narrow, you can actually define what passing looks like. You can measure accuracy against a ground-truth dataset. You can run a parallel test where the AI and a human do the same work independently and compare results. Broad scope makes that kind of rigorous evaluation almost impossible.

Build vs. Buy vs. Integrate

One of the most consequential decisions in any implementation is what to build from scratch, what to use off the shelf, and what to connect to existing systems.

My default is to buy or integrate wherever the problem is solved. There are excellent commercial solutions for OCR, document classification, entity extraction, and a range of other foundational capabilities. Building those from scratch is rarely the right call. The interesting engineering work is almost always in how you stitch them together, how you handle the edge cases specific to your data, and how you fit the result into the workflow the client's team actually uses.

For a typical law firm or insurance carrier, this means the AI layer is built on top of a combination of foundation model APIs (usually OpenAI or Anthropic depending on the task), an orchestration layer I build in Python, and direct integration into whatever system of record the client already uses: their case management platform, their policy admin system, their document management system.

I don't rip and replace. If the firm runs on iManage, the output goes into iManage. If the carrier runs on Guidewire, the output goes into Guidewire. From the user's perspective, the AI is invisible to the workflow. It handles the extraction and routing, then puts the result exactly where a human would have put it manually.

The Implementation Sprint

Once scope is locked and the discovery findings are documented, implementation moves fast. Most of the actual build happens in a two-week sprint.

The first few days are infrastructure: environment setup, API keys and credentials, access to the systems we're integrating with, initial data pipelines to pull a representative sample of documents for development. Operational friction in this phase, specifically waiting for IT to provision access or waiting for procurement to approve a vendor, is the most common cause of timeline slippage on the client side. I flag this in the scope document and ask clients to have it resolved before the sprint starts.

The middle of the sprint is the core build: the extraction pipeline, the prompt engineering, the classification logic, the integration layer. I test against real documents continuously, not just at the end. I build with the client's actual data from day one, which means the model sees the same coverage endorsements, the same contract formats, the same compliance filings that will hit production.

Toward the end of the sprint, I run a structured evaluation. I hold out a set of documents the system has never seen, run them through the pipeline, and score the output against ground truth. If the accuracy doesn't meet the agreed threshold, we either tune until it does or we have an honest conversation about whether the success criteria were calibrated correctly against the actual data.

Testing With Real Data, Not Synthetic Datasets

This deserves its own section because it's where a lot of AI projects fail in ways that don't show up until after go-live.

Synthetic test data is useful for validating that a pipeline doesn't crash. It is nearly useless for validating that a pipeline will work on the documents that show up in production. Real documents are messy. They have scanning artifacts and inconsistent formatting and handwritten annotations and pages in the wrong order. They have variations in structure that no synthetic generator will anticipate.

From day one, I work with a sample of the client's actual historical documents. Not one or two examples but a representative set that covers the range of variation in their real data: the clean digital-native files and the third-generation fax scans, the standard forms and the non-standard ones, the easy cases and the genuinely ambiguous ones.

When the evaluation at the end of the sprint uses a held-out set of that same real data, the accuracy number means something. It's not a benchmark result. It's a prediction of how the system will perform on Monday morning.

Handoff and Training

I've seen AI implementations fail not because the system was wrong but because the team didn't know what to do when the system was uncertain. The handoff is not an afterthought.

After the evaluation, I spend time with the people who will actually use the system. For a law firm, that might be paralegals and intake coordinators. For an insurance carrier, it might be claims adjusters or underwriting assistants. The goal is not to make them understand the technology. It's to make them understand what the system will do, what it will not do, and what to do when it flags a document for human review.

I also document the system clearly: what it's doing, how to monitor it, what the common failure modes look like, and how to reach me if something breaks. That documentation is written for the person who will be responsible for it in six months, not for me.

Ongoing Support

Most engagements end with an optional retainer for monitoring and optimization. This is not a support contract designed to extract recurring revenue. It's a practical recognition that production AI systems benefit from periodic attention.

Models drift. Document formats change. A new type of coverage endorsement enters the market and the extraction logic needs to be updated. A regulatory change requires a new output field. These are small changes, but they're easier to handle with a relationship in place than by re-engaging from scratch.

Some clients want monthly check-ins and proactive monitoring. Others want a break-glass arrangement where they call me when something goes wrong. Both are fine. I try to match the support model to what the client actually needs rather than selling them a level of engagement they won't use.

Who This Works For

I want to be direct about this: the 2-4 week model is well-suited to mid-market organizations and it has limits at the high end.

A law firm with 50-200 attorneys, a regional insurance carrier, a corporate compliance team at a mid-size company: these organizations typically have a bounded, well-defined workflow problem that can be scoped cleanly, a reasonably standard technology stack, and decision-makers who can approve a project without a six-month procurement cycle.

A Fortune 100 organization with enterprise security review requirements, multi-team stakeholder alignment, and a procurement process that takes longer than the build itself is a different engagement. The technical work is often the same. The organizational overhead is not, and I'm not going to pretend that overhead doesn't affect the timeline.

If you're in that second category and you want to move faster than your organization typically allows, the most useful thing I can do is scope an isolated pilot with a single team that can move independently of enterprise procurement. Start there, prove it works, then expand with organizational momentum behind you.

The Honest Case for Moving Fast

The argument for moving fast is not just about saving time. It's about learning earlier.

A six-month project often spends the first four months building something based on assumptions about what the workflow actually is and what the data actually looks like. Those assumptions are frequently wrong in ways that don't surface until someone runs the system on production data. By that point, the investment is large enough that there's organizational pressure to make it work rather than to rebuild it correctly.

A 2-4 week project gets to production fast enough that you find out what's wrong while the cost of fixing it is still low. The first version is not the final version. It's an informed starting point built on real data and real requirements, not on what a requirements document said six months ago.

That's the model. If it sounds like the right fit for something your team is trying to solve, I'd like to hear about it.

---

Book a discovery call to walk through your specific workflow. The first conversation is free, and you'll leave with a clear sense of whether a fast implementation makes sense for what you're trying to build.