Our Process: From Discovery to Handoff

We do not run discovery calls that end with a 40-slide deck. We run a structured engagement that ends with a working system.

Every project follows the same four phases. Skipping them is how projects fail. Not some projects — all of them. We have seen enough failed AI implementations to know that the process exists for a reason, and cutting corners on it does not save time. It costs time.

Phase 1 — Discovery

Duration: 1-2 sessions, 60 minutes each. Format: Video call or in-person. Recorded with your permission (for our reference only, never shared). Cost: Free. No commitment required.

We start by mapping your actual situation, not the version you think we want to hear. We are not looking for polished presentations of your workflow. We are looking for the truth.

What We are Actually Looking For

During Discovery, we are hunting for four things:

Time leaks. Where does the same type of work happen over and over, consuming hours that could be used for something more valuable? Not "we are busy" — specific, recurring tasks that follow a pattern.

Decision patterns. Which decisions in your workflow require real judgment (experience, context that changes every time) and which follow a repeatable rule? AI handles rule-based decisions well. It handles judgment-heavy ones poorly. Knowing the difference is the first step.

Data flow. How does information move through your organization? Where does it get stuck? Where does it get lost? Where do people manually copy data from one system to another? These hand-off points are often the best candidates for automation.

Tool friction. Which of your existing tools work well together, and which do not? A CRM that has a great API makes integration easy. A legacy system that only exports CSV files manually makes it harder. We need to know this before we estimate anything.

What Discovery Is NOT

Discovery is not a sales pitch. We will not show you a demo of what AI can do and wait for you to be impressed. You are not here to watch us perform.

Discovery is not a "needs assessment" where we nod along to everything you say and then propose the most expensive solution. If your needs do not match what we build, we will tell you during Discovery, not after you have committed.

Discovery is not the beginning of a project. It is the decision point. You may walk away with a clear "no" and that is a perfectly valid outcome. A good Discovery that results in "no" is more valuable than a bad Discovery that results in a project that should not have started.

What You Bring

Access to real examples. Actual emails, actual reports, actual workflows. Not cleaned-up versions. The AI will encounter your real data, with all its messiness and inconsistency. We need to see that during Discovery, not during build.

Discovery is free. No commitment is required to proceed to Specification, and we will tell you if the project is not the right fit before that stage begins.

For a complete guide to the Discovery process, including how to prepare and what to expect, see The Consultation: Why It Matters.

Phase 2 — Specification

Duration: 3-5 working days after Discovery. Deliverable: A written functional specification document. Your role: Review, ask questions, approve.

We write a functional specification before writing a single line of code. This is not optional. This is not a formality. This is the single most important document in the entire project.

What a Spec Document Looks Like

A typical specification runs 5-15 pages depending on the project tier. It contains these sections:

Problem statement. What we are solving, written in plain language. If your team reads this section and does not recognize the problem, we got it wrong.

Exact inputs and outputs. What goes into the system (data format, sources, frequency) and what comes out (reports, notifications, processed documents, API responses). No ambiguity. If the input is an email, we specify what kind of email, from which source, in what format.

Processing logic. What the AI does with the inputs. Step by step, in order. Including what happens when the AI encounters something it cannot handle (the fallback path matters as much as the happy path).

Edge cases. The things that make a simple process complex. We identified them during Discovery, and here they are documented with specific handling instructions. "Client sends email in a language we do not support" — what happens? "Invoice is missing a required field" — what happens? Every edge case gets an answer.

Scope boundary. What the system does NOT do, written explicitly. This section prevents 90% of "but I thought it would also..." conversations during build. If it is not in the spec, it is not in scope.

Integration points. Which tools the system connects to, how, and what happens when those connections fail. API specifications, authentication requirements, rate limits — all documented.

Acceptance criteria. How you will know the build is correct. Specific, measurable tests that the system must pass before we consider it done. These are the standard we will both be held to.

Why Written Specs Prevent Project Failures

Most AI projects fail because the scope was never written down. Both sides had a different picture in their heads. The vendor thought "email classification" meant sorting into 5 categories. The client thought it meant reading, summarizing, and routing to the right person with a draft response. Nobody was wrong — nobody had written down what they meant.

The spec is a contract between us. Not a legal contract (though it can be referenced in one), but an operational contract. It is the single source of truth for what we are building. When questions arise during build — and they always do — we go back to the spec.

If it is not in the spec, it is not in scope. If you want it in scope, we add it to the spec (with updated timeline and cost). This is not bureaucracy — it is clarity.

You review and approve the spec. If we disagree on something, we resolve it in writing before build begins. No one starts coding with unresolved questions.

Phase 3 — Build

Duration: Depends on tier. Tier 2: 2-4 weeks. Tier 3: 4-8 weeks. Tier 4: 8-16 weeks. Your role: Test on real data, provide feedback, report issues.

How Build Works in Practice

A typical iteration cycle looks like this:

Week 1 (Tier 2 example):

›Days 1-3: Core system built and configured. AI model integrated, knowledge base loaded, basic processing logic implemented.
›Days 4-5: Internal testing against your sample data from Discovery. We catch the obvious problems before you see anything.

Week 2:

›Day 1: You receive access to the first working version. Not a demo — a real system connected to your data.
›Days 2-4: You test against real work. Not hypothetical scenarios — your actual documents, your actual emails, your actual processes.
›Day 5: You report what worked, what broke, and what felt wrong. We collect this feedback in writing.

Week 3:

›Days 1-3: We fix what broke, adjust what felt wrong, improve handling of edge cases you discovered.
›Days 4-5: You test again. Repeat until acceptance criteria from the spec are met.

This cycle continues for as many iterations as needed. We do not have a fixed number of revision rounds. We have acceptance criteria, and we iterate until they are met.

Testing on Real Data

"Testing on real data" means exactly what it says. We do not build a demo with curated examples and call it done. We connect the system to your actual data sources and let it process real inputs.

This is where surprises happen. The email format that worked perfectly in testing breaks because one client uses HTML signatures with embedded images. The document parser handles PDFs from your system perfectly but chokes on scanned documents from a partner. The classification model works great in English but your clients sometimes write in German.

These surprises are normal. They are why we iterate. And they are why we test on real data instead of demo data — because demo data never contains the surprises.

Bugs vs. Feature Requests

During build, we distinguish clearly between bugs and feature requests.

A bug is when the system does not do what the spec says it should do. Email classification is supposed to sort into 5 categories, but it consistently puts "invoice inquiries" into "general" instead of "finance." That is a bug. We fix it, no discussion.

A feature request is when you want the system to do something that is not in the spec. "Can it also draft a reply?" when the spec only covers classification. That is a feature request. It goes into the backlog. If you want it added to the current build, we update the spec, timeline, and cost in writing.

This distinction is not about being difficult. It is about protecting the project timeline and making sure both sides are clear on what is included. Feature creep is the number one killer of AI projects, and we guard against it actively.

Our Quality Verification Workflow

Every output our systems produce goes through a multi-step verification process:

›Automated checks. Format validation, data integrity, error detection.
›AI cross-verification. A second AI model reviews the output of the first. Different model, different prompt, independent assessment.
›Human review. We manually check samples from every output category, focusing on edge cases and high-stakes decisions.
›Client testing. You test on real work and report discrepancies.

This workflow exists because AI models hallucinate. It is a known property of the technology, not a flaw in our implementation. The question is never "does the AI make mistakes?" — it is "are the mistakes caught before they reach the end user?" Our verification workflow is how we catch them.

Phase 4 — Handoff

Every build ends with a handoff package delivered to your team.

What the Handoff Package Contains

The handoff is a collection of everything your team needs to operate the system without us:

›System documentation. What was built, how it works, architecture overview, component descriptions. Written for your team, not for engineers (unless your team is engineers, in which case we write it for engineers).
›Operations manual. Step-by-step instructions for common maintenance tasks: adding new entries to the knowledge base, adjusting prompts, updating data sources, restarting components after an outage.
›Configuration files. All system prompts, model settings, integration credentials (stored securely), and workflow configurations. Everything is version-controlled in a GitHub repository that you own.
›Known limitations. An honest list of what the system does not handle well, with workarounds. Every system has limits. We document them rather than pretend they do not exist.
›Troubleshooting guide. Common issues and how to resolve them. "The AI starts giving short answers" — check the context window, it might be full. "Classification accuracy drops" — check if the input format changed.
›Support contact protocol. How to reach us during the support period, response time expectations, what qualifies as a bug.

What "You Can Operate It Without Us" Means

This is our standard. If your team cannot run the system day-to-day without calling us, the handoff failed.

Specifically, your team should be able to:

›Add new content to the knowledge base
›Adjust AI prompts when your business needs change
›Monitor system health and recognize when something goes wrong
›Handle common issues using the troubleshooting guide
›Know when a problem exceeds their capability and needs professional support

We do not build systems that create permanent dependency. You hired us to build something. When it is built, it is yours. Fully.

Training Session

For Tier 3 and Tier 4 projects, the handoff includes a live training session with your team:

›Tier 3: Up to 2 hours. Covers daily operation, common maintenance, and troubleshooting.
›Tier 4: Up to 4 hours. Covers all of the above plus architecture overview, component interaction, and advanced configuration.

The training is recorded and included in your handoff package. New team members can watch it later.

What Happens Between Phases

Projects do not move from one phase to the next instantly. Here is what typical transition periods look like:

Discovery → Specification: 1-3 business days. We process our notes, draft the initial spec structure, and begin writing.

Specification → Build: 1-5 business days. You review the spec, ask questions, we revise, you approve. Simple specs take a day. Complex ones might take a week of back-and-forth.

Build → Handoff: Immediate once acceptance criteria are met. We do not artificially extend projects.

Typical total timeline from first Discovery session to live system:

›Tier 2: 4-6 weeks
›Tier 3: 8-12 weeks
›Tier 4: 12-22 weeks

These are real ranges, not marketing estimates. They include the review cycles and feedback windows that always happen.

Red Flags We Watch For

Sometimes we need to pause or stop a project. These are the warning signs:

No feedback for 5+ business days. We sent you a build to test. Five days pass. Nothing. This means either the project is not a priority for you (which means the timeline will slip), or something went wrong that you have not told us about (which means we cannot fix it). Either way, we pause and schedule a check-in.

Scope changing faster than we can spec it. "Actually, can it also handle invoices?" on Monday. "What about customer complaints too?" on Wednesday. "And can we add a reporting dashboard?" on Friday. Each of these might be reasonable individually. Together, they indicate the problem is not well-defined yet, and building against a moving target wastes everyone's time.

Stakeholders who were not in Discovery now making decisions. We mapped the process with you. You understood the trade-offs. Now your manager (who was not in the room) has different priorities and wants different features. This is not a technical problem — it is an organizational one. We pause until all decision-makers are aligned.

"Can we just add one more thing" syndrome. Every addition has a cost, even small ones. When small additions accumulate, they create complexity that was not accounted for in the spec, the timeline, or the price. We address this by treating every addition as a spec amendment — written, estimated, approved — rather than letting it slide.

When we see these red flags, we do not just push through and hope for the best. We stop, flag the issue in writing, and propose a resolution. Sometimes that means a re-scoping session. Sometimes it means a timeline extension. In rare cases, it means pausing the project entirely until the prerequisites are back in place.

Communication

All in writing. Email or a shared project thread. We do not manage projects through WhatsApp, Slack DMs, or informal phone calls. Written communication creates a record, prevents misunderstandings, and lets both sides search for decisions that were made weeks ago.

Weekly status updates on Fridays. Short, structured: what was completed this week, what is planned for next week, any blockers. You will know exactly where the project stands without having to ask.

Response expectations. We respond to project-related messages within 24 hours on business days. We ask the same from you. When both sides respond promptly, projects stay on track. When one side goes silent, timelines slip.

No project decisions in informal channels. If something is discussed on a call, we follow up with a written summary. If you send a WhatsApp message with a change request, we will acknowledge it and ask you to email it. This is not about being rigid — it is about making sure nothing gets lost.

If something is blocked on your side for more than 5 business days, the timeline shifts accordingly. The same applies in reverse: if we are blocked on our side, we notify you within 24 hours and adjust the timeline in writing.

Integrations The Consultation