Most people who reach out to us have never hired an AI development agency before. They've seen demos, read about what AI agents can do, and have a use case in mind — but they're not sure what the engagement actually looks like, what they'll need to provide, and what they'll walk away owning.
This is a complete, honest walkthrough of how our projects run.
Before the contract: the scoping call
The first call is not a sales call in the traditional sense. We're trying to figure out whether this project is a good fit to build.
We'll ask: what problem are you trying to solve, what does the current workflow look like, what data do you have available, what does success look like in three months. We'll also ask questions that sometimes surprise people: what happens when the AI gets something wrong, who owns this system after we hand it off, have you looked at off-shelf solutions.
If an existing tool would solve your problem, we'll tell you. We don't build custom systems for problems that don't require them. When there's a genuine fit — the workflow is custom, the data is proprietary, or the off-shelf options don't cover the requirements — we move to a scoping document.
Phase 1: Discovery (1–2 weeks)
Discovery is the most important phase of the project. It's also the phase most agencies rush through.
What we do during discovery:
- Stakeholder interviews. We talk to the people who will use the system, not just the people who commissioned it. Users surface requirements that sponsors miss — edge cases, exceptions, the workflows that don't appear in the documentation.
- Data audit. We look at the actual data: where it lives, what format it's in, how current it is, what preprocessing it will need. We've learned not to trust data inventories made before anyone looked at the data.
- Integration mapping. Every system the AI will need to read from or write to gets identified and documented. We check API availability, authentication requirements, and rate limits before committing to a timeline.
- Success metric definition. What does "working" mean, specifically? For a RAG chatbot: recall@5 above 85%, average response quality above 4.0/5.0 in human eval. For an agent: task completion rate above 90%, escalation rate below 15%. These get written down before build starts.
What we need from you: 2–3 hours of stakeholder time, access to data samples (even a small representative set), and login credentials for any systems we'll integrate with.
Phase 2: Architecture (1–2 weeks)
With the spec in hand, we design the technical approach.
For a RAG system, architecture covers: data pipeline design, chunking strategy, embedding model selection, vector database choice, retrieval configuration, and the LLM stack. For an agent, it covers: tool definitions, the agent loop, memory strategy, and orchestration approach.
The eval plan is written during architecture. We define the test cases we'll use to measure quality at launch — before a single line of production code is written. This forces us to be honest about what "done" means, and it gives you a clear standard to hold us to.
Architecture produces a technical design document that you review and approve before we start building. This is the checkpoint where scope changes are cheapest — before any build work has happened.
Phase 3: Build (3–8 weeks)
Development happens in two-week sprints with a working demo available to you throughout. You don't wait 10 weeks and then see a finished product — you see it incrementally and can give feedback as it takes shape.
What build includes:
- Prompt engineering and iteration on real examples from your domain
- Integration development and testing against your actual systems
- A staging environment accessible for stakeholder testing
- Weekly check-in calls to review behavior on real queries
We track quality against the eval suite continuously during build, not just at the end. This means regressions get caught immediately rather than on the day of the demo.
What we need from you: feedback within 2 business days on staged demos, quick-turnaround answers on product decisions (the most common cause of delays is waiting a week for a yes/no on a design choice), and flagging of test cases where the system behavior looks wrong.
Phase 4: Evaluation (1–2 weeks)
Before anything goes to production, the system runs through the full eval suite defined in phase 2.
This phase includes:
- Automated eval across all test cases with scoring on each dimension
- Human review of a representative sample
- Load testing for customer-facing systems
- Security review: prompt injection testing, access control validation, data handling verification
- Stakeholder sign-off on the final test results
A system that doesn't hit its quality thresholds doesn't go to production. This is a hard gate, not a suggestion. We've pushed back launch dates because eval results came in below threshold. It's less pleasant than shipping on schedule and more pleasant than shipping a system that fails in front of your customers.
Phase 5: Deployment and handoff
Production deployment to your infrastructure (or our recommendation for a managed deployment on Vercel, AWS, or GCP). We set up monitoring — request logging, error alerting, quality dashboards — before we step back.
Handoff includes:
- System documentation: architecture overview, data flow, component descriptions
- Operations runbook: how to monitor the system, what alerts mean, how to restart components
- Prompt library: all prompts used, with notes on what each controls and how to adjust it
- Knowledge transfer session: a 2-hour call walking your team through the codebase, the eval harness, and the deployment configuration
What you own at the end: all source code (no license, full ownership), all prompts, all documentation, the eval harness, and the deployment configuration. You are not dependent on us to operate or change the system after launch.
Common questions
Do we need to prepare our data before starting? No — data preparation is part of the project scope. But if you start with clean, well-structured data, the timeline is shorter.
Can we change scope during the project? Yes, through a change request process. Small additions that fit the existing architecture are absorbed. Material scope changes have timeline and cost implications that we'll document and agree on before proceeding.
What's our involvement after launch? Optional. We offer ongoing maintenance and iteration support, but it's not required. Many clients take full ownership after handoff. Others prefer to keep us on a retainer for model updates, knowledge base expansion, and prompt iteration.
If you want to understand whether your specific use case is a fit, the contact page goes directly to us. We respond same business day.