The message comes in, and everything shifts. Not dramatically. A founder types “let’s go” or “we’re in” and the project moves from a proposal to an actual build. That moment feels different in AI development services than it does in traditional software projects. It’s not the finish line. It’s the starting gun for about 48 hours of dense, decision-heavy work before the engineering team writes their first serious line of code.
These 48 hours don’t get documented much. Clients see the sprint demos, the prototype, the deliverables. What they rarely see is the process that makes those things possible: the brief, the staffing, the architecture call, the sprint plan. All of this happens quietly while a founder is still processing that the project just started.
I’ve managed enough builds to have a consistent pattern for this window. Here’s what it actually looks like.
Hours 0–4: The Discovery Call Recap
The discovery call already happened. We talked about what the client wants to build, why, and what a successful outcome looks like. But a call without documentation is just a conversation that fades.
My first move after getting the yes is writing a call recap while everything is still sharp. This isn’t a formal document. It’s a 1-2 page notes file covering: the client’s core problem, the proposed AI approach, anything flagged as uncertain, and the exact phrases the client used that I want to remember. That last part sounds minor. It isn’t. If a founder said “our users aren’t technical, they’ll be frustrated if this isn’t intuitive,” that context shapes engineering decisions three days later.
I also flag everything uncertain. If the client described their data as “pretty well-organized,” I note: needs verification. That phrase has burned me before. Well-organized can mean a clean Postgres database with consistent schemas or three spreadsheets with four different date formats. I don’t assume.
This document is internal. The engineering team sees it. The client doesn’t, not yet. Everything that follows in the next 44 hours starts here.
One rule I hold to: this recap gets written within 4 hours of receiving the yes. Not tomorrow. Not after I finish the other thing.
Hours 4–8: Writing the Brief
The brief goes deeper than the call recap. It’s written for the lead engineer who’ll be staffed on this project and needs enough context to walk into the architecture call with a real opinion.
It covers:
- What the client is building and why it matters to them
- The core question the prototype needs to answer (for new builds, the 72-hour prototype is almost always our starting point)
- Data availability: what we have, what format it’s in, what’s missing
- Initial tech stack direction: any preferences the client mentioned, plus my first instinct on what makes sense
- Open questions that need answering before we start building
- Risk flags: the 2-3 things most likely to slow us down
A brief I can’t complete is itself useful. If I get to the “data availability” section and don’t know the answer, that becomes a client follow-up before staffing happens. Staffing an AI engineer before I know whether we have usable data is how projects hit walls in week one.
I also keep a running list of commitments I haven’t made yet. Timelines, specifically. I don’t give the client a final timeline before the architecture call. If they ask, I tell them I need to come back after the engineering team reviews the brief. That’s not a dodge. That’s the accurate answer.
I used to skip this step when I was newer, briefing the team verbally in the architecture call instead. The missed context always cost more time than writing it down would have.
Hours 8–16: Engineering Staffing
With a brief in hand, I look at who’s available and who fits.
For most AI builds, the initial team is a lead AI engineer and a backend engineer. The AI engineer handles the model pipeline and retrieval layer. The backend engineer handles data infrastructure, APIs, and integration work. Frontend and QA typically come in during weeks two and three.
What I’m looking for:
Relevant experience. Not “has worked with LLMs.” Has built a RAG pipeline over internal documentation and run into the chunking strategy problems. Has tuned retrieval for a production use case and knows what breaks. The 6,000 weekly engineering hours across our team means I’m not posting a job listing. I’m making an allocation decision from engineers who’ve built this before.
Communication style. For clients who plan to be closely involved, I want engineers who can explain their decisions in plain English during standups. Some engineers are exceptional builders and less natural communicators. I match this to the client’s involvement level and tell the client upfront what to expect.
I send the brief to the assigned engineers and schedule the architecture call for the same day or early the next morning. The clock is running.
Hours 16–28: The Architecture Conversation
This is the most consequential meeting in the first 48 hours. Everything else is logistics. This is where we make real decisions.
The agenda I run through:
Tech stack confirmation. Which LLM provider: OpenAI, Anthropic, or open-source? If there’s a retrieval component, what’s the chunking and indexing approach? For agentic workflows, should we use LangGraph or build lighter orchestration? These decisions don’t need to be permanent. We need a direction to start building.
Data pipeline. How is data getting into the system and in what shape? If the client hasn’t given us data access yet, we identify a representative sample or synthetic data for the prototype. Real data integration becomes the first task in the full build.
The question the prototype answers. We name it explicitly and write it down. “By the end of the prototype, a non-technical user should be able to ask a plain-English question about their sales data and get a correct, cited answer.” That sentence is the north star. Every decision in the next 72 hours gets measured against it.
Risks and dependencies. Third-party APIs with unknown reliability, data quality issues we haven’t verified, library choices that might conflict with each other.
I write a half-page decision summary and send it to the engineering team within an hour of the call ending: what we decided, what each person owns, what’s still open.
One pattern I watch for: when the architecture call produces more open questions than decisions, that’s a sign the scoping wasn’t sharp enough. I pause. I go back to the client with specific questions before engineering continues. It feels slower. It isn’t. Unclear requirements produce fast work in the wrong direction.
Hours 28–36: Repo Setup and First Environment
This stretch is the engineering team’s work, not mine. But I track it because it’s an early momentum signal.
What should happen: repository created and shared, base project scaffolded (Next.js, FastAPI, or whatever the stack is), environment variables structured, and for RAG use cases, document loading and basic vectorization running. By the end of this window, I want confirmation that the AI is responding to a test query. Not well. Not correctly yet. Just responding.
I check in around hour 32. Not to micromanage, but to catch blocks early.
The blocks that show up here are almost always access-related. An API key without the right permissions. A shared Google Drive folder set to view-only. A data file in a format the client didn’t mention. These sound minor. Each one costs 3-4 hours if no one flags it until the following morning.
The Agile Alliance describes sprint planning as the process of identifying sprint goals and the work needed to meet them. In practice, for me, that means updating the sprint plan when reality changes. A 1-hour blocker doesn’t derail the sprint. An untracked 1-hour blocker that grows to 4 hours does.
Hours 36–44: Sprint Plan
Sprint planning in the first 48 hours is a working document, not a full ceremony. I put it together based on the architecture decisions and what the engineering team has confirmed is in place.
For a 72-hour prototype that feeds into a larger build, the plan covers two phases:
Phase 0 (the prototype, days 1–3):
- End of Day 1: AI pipeline responding to real queries. Rough, but working.
- End of Day 2: core feature usable. The client could interact with it and get meaningful output.
- End of Day 3: staging URL ready, known limitations documented, demo prep complete.
Phase 1 (post-prototype, if we move forward):
- High-level themes only at this stage. No detailed tickets yet. We scope Phase 1 properly after the prototype demo, once we know what it confirmed and what needs to change.
The sprint plan goes to the engineering team as a shared document. Ticket boards come later. Right now, everyone needs to see the same targets in the same place.
A simplified version goes to the client. Not the technical detail. Just: by this time on Thursday, here’s what you’ll see. Specific, not vague. One deliverable. One date.
Hours 44–48: First Client Check-In
This call is 15-20 minutes. It covers three things.
Scope confirmation. “The prototype will demonstrate X. It won’t include Y and Z yet. Does that match your understanding?” This is a sanity check, not a renegotiation. But sometimes a client says “yes, and I also realized yesterday I need…” and hearing that at hour 46 is much better than at the hour-68 demo.
Data and access status. If we need something from the client and haven’t received it, this is where I say so directly. “If we don’t have API access by tonight, I’ll let you know how that affects Thursday’s demo.” I give a specific time. Not “as soon as possible.”
What they’ll see next and when. One date. One deliverable. One honest flag if something is at risk. “You’ll get the staging URL Thursday at 4pm. I’ll walk you through it Friday morning.”
I don’t give vague progress reports. “We’re making good progress” is meaningless to a founder waiting to see their idea working. A deliverable, a date, and an honest flag if either one is in question. That’s the entire check-in.
What Usually Goes Wrong
These 48 hours rarely run perfectly. Here’s what I see most often:
The data isn’t what we expected. The client described their data one way on the discovery call. The reality is different. Not because anyone misled us. Because founders aren’t thinking about data schemas when they’re describing a product idea. When this happens: we adjust the prototype scope to use a representative sample or synthetic data and treat real data integration as the first task in the full build. The prototype still proves the AI approach works. It proves it with placeholder data instead.
A key dependency is unavailable. An LLM provider outage, a third-party API endpoint that’s broken, a library version conflict that takes an afternoon to untangle. These happen. I log them in the sprint plan as blockers and adjust the end-of-day target. I tell the client if a target date shifts. I don’t wait until the deadline to say something.
The architecture question was harder than expected. Sometimes a 20-minute call becomes 2 hours because the right approach isn’t obvious. That’s fine. A longer architecture conversation is better than a quick one that produces wrong decisions. I note it for the client and move the timeline if needed.
The client goes quiet. We need something: data access, a clarification, an API key. Twelve hours pass with no response. I send one follow-up with a specific deadline. If no response by then, I note it as a dependency delay and move forward with what we have, documenting what had to be substituted or skipped as a result.
None of these derail a well-run project. What matters is catching them early and adjusting.
Why These 48 Hours Set Everything
The 72-hour prototype promise is only possible because this window runs this way. The brief, the staffing, the architecture call, the sprint plan: each one removes a category of uncertainty before the build starts. By the time engineers are deep in the work, they’re not making it up as they go.
People and process before product. That’s not a tagline. It’s the reason AI development services produce working software on predictable timelines when they’re run this way. You can have the right talent and still miss the mark if the first 48 hours are chaotic. This window is where the talent gets everything it needs to move fast in the right direction.
We never over-commit or under-deliver. That starts here.
FAQ
What is included in AI development services from Kalvium Labs?
AI development services at Kalvium Labs cover the full build: scoping and architecture, a 72-hour working prototype for new projects, production engineering across AI, backend, and frontend disciplines, and project management from kickoff through deployment. Every project is supervised by Anil Gulecha, co-founder and CTO, ex-HackerRank and ex-Google.
How quickly can a project start after we agree on scope?
Engineering staffing happens within 8-16 hours of the brief being written, which itself gets written within 4-8 hours of the project start. In practice: if a client confirms in the morning, engineers are briefed and the architecture call is scheduled by the same afternoon or early the following morning. The 72-hour prototype window starts from there.
What does the client need to have ready before day one?
Two things matter most. First, data access: whatever data the prototype will run against, in a format we can work with. If access isn’t available by day one, we plan for a representative sample and treat real data integration as the first post-prototype task. Second, a clear decision on scope: what the prototype needs to prove. That should already be agreed on the discovery call before the project starts.
How do you handle scope changes in the first 48 hours?
Small clarifications are normal and expected. The scope confirmation call at hours 44-48 exists partly for this reason. Larger direction changes, the kind that affect what the prototype is trying to prove, get a proper scoping conversation before engineering continues. I’d rather pause for a few hours and repoint the team than have them build toward a target that shifted. I gently tell clients this up front.
How is communication handled during an active sprint?
Every sprint runs async-first: daily standups with written summaries, a shared channel for questions and updates, and documented sprint goals that both client and engineering team can reference any time. Urgent, blocking issues are treated as urgent. Non-blocking questions are batched into standups. The client always knows what’s happening and what’s coming next, without needing to ask.
If you want to know what the first 48 hours would look like on your specific project, Book a 30-minute call. I’ll walk you through exactly what we’d build and when you’d see it working.
