A founder asked me last month when his AI-powered onboarding tool would be ready. Twenty minutes into the discovery call, with the use case still unfolding in front of me, he asked the question every founder asks. “So, six weeks? Eight?”
I told him I didn’t know yet, and that I’d come back to him in 24 hours with a number I could stand behind.
He paused. I could hear him weighing whether that response made me more credible or less. Then he said, “Okay, that’s actually helpful. Send me the brief tomorrow.” We had a working agreement by Wednesday and a prototype by the end of the following week.
I’ve trained myself to say “I need to come back after analysis” because every fast estimate I gave on a new requirement during my first year of AI development services work cost me more than it earned. Not always in money. Sometimes in trust, sometimes in a sprint that started two days late because the data wasn’t where I’d assumed it was, sometimes in a quiet conversation three weeks later about why we were 40% over the original estimate.
This post is about when I commit to a timeline immediately, when I don’t, and what I do during the 24-hour gap. It’s also about why founders, in my experience, trust the pause more than the snap answer.
When I Will Commit to a Timeline in the Call
There are scenarios where I’ll quote a number on the spot. They share three properties.
We’ve built something almost identical before. A retrieval-augmented chatbot over a documentation set sized between 200 and 5,000 pages. A sentiment analyzer on call transcripts. A document parser that pulls structured fields out of contracts. These aren’t novel for our team anymore. We’ve shipped each of them at least three times. The variables are predictable: data volume, target accuracy, the integration surface on the client’s side. I can scope a prototype in real time, and a fixed-bid estimate the same day.
The client’s data lives somewhere we can read it. A Postgres database, an S3 bucket, an API with documentation. If they tell me the data is in 14 Google Sheets maintained by different team members, I’m not committing in the call. That’s not because Sheets are bad (they’re often fine), but because I need to see a sample before I know how messy “fine” actually is.
The success criteria are concrete. “The model returns the right answer 8 times out of 10 on this test set” is concrete. “The AI feels intelligent” is not. Concrete success criteria mean I can pre-define what “done” looks like, which means I can estimate the effort to get there.
If all three boxes get ticked on the call, I commit. Sometimes that’s a 72-hour prototype. Sometimes it’s a four-week build. Either way, the number I quote isn’t a guess. It’s pattern matching against work we’ve finished before.
When even one of those boxes is empty, I stop and wait.
The 24-Hour Analysis I Run Instead
The wait isn’t a stalling tactic. It’s a structured process that takes about three hours of focused work on my end and another hour of input from the engineering leads.
Step 1: Decompose the requirement into knowns and unknowns. I open a doc, write the client’s request at the top in their own words, and list every component underneath. For the onboarding tool conversation I mentioned, the components were: a conversational interface, an LLM chain that pulled from internal HR policy documents, an integration with the client’s Slack workspace, and a feedback capture mechanism so HR could review answers.
For each component, I mark it K (known, we’ve done it) or U (unknown, we haven’t). Most projects come back with three or four Ks and one or two Us. The Us are where the estimate has to flex.
Step 2: Find the hidden cost. Every AI project has one. It’s almost never the model. Sometimes it’s the data prep (corpus needs reformatting, deduplication, OCR on PDFs). Sometimes it’s the eval setup (defining the test cases, building the scoring rubric). Sometimes it’s the integration (the client’s auth system is custom and undocumented). I try to name the hidden cost explicitly, because if I can’t name it, that’s the part the estimate will be wrong about. Steve McConnell’s Software Estimation: Demystifying the Black Art calls this the “cone of uncertainty,” and it’s why early estimates have ranges, not points.
Step 3: Talk to the engineering lead for 30 minutes. Anil Gulecha, our CTO (ex-HackerRank, ex-Google), reviews anything technically unfamiliar. I walk him through the requirement. He asks the questions I haven’t thought to ask yet: “Have you confirmed the chunking strategy works on policy docs?” “Is the Slack integration going through their bot framework or webhooks?” “What happens if the LLM returns a confidently wrong answer?” His questions become the unknowns I need to test before I quote.
Step 4: Write a one-page brief. Not a proposal. A brief I can send the client that includes the requirement in their words, our understanding of it, three to five open questions, and a proposed estimate range with a single sentence on each thing that could push the number. I’ve been refining the format for about a year now, and it usually takes 40 minutes to draft.
That whole loop takes a working day. Not because the analysis is hard, but because compressing it any further produces estimates I can’t defend. I’ve tried.
What I Tell the Client in the Meantime
The hardest part of this process isn’t the analysis. It’s holding the client’s confidence during the 24-hour gap.
What I say at the end of the discovery call, almost word for word: “This is a new shape of problem for us, and I want to give you a number I can stand behind rather than a number that sounds good in this meeting. I’ll send you a brief by tomorrow afternoon with our understanding, the estimate, and the things I still need to confirm. If anything in it doesn’t match what you meant, we adjust. Sound okay?”
Three things matter in that script:
- I name why I’m waiting. Vagueness (“let me get back to you”) makes people anxious. Specificity (“a number I can stand behind”) makes them lean in.
- I commit to a deadline for the wait itself. “By tomorrow afternoon” is concrete. “Soon” or “in a few days” is not. I deliver inside that window every single time, because the deadline I set during the pause is the first promise the client gets to test.
- I leave room for them to push back. The brief is a draft, not a verdict. If they read it and something’s off, we have a 15-minute call to align before any timeline gets locked in.
The phrase I never use: “we’ll figure it out as we go.” It feels collaborative. It’s not. It’s a way of postponing the analysis to a moment when the cost of getting it wrong is much higher. Hofstadter’s law (the thing I’ve internalized after enough reps) says it always takes longer than you expect, even when you take Hofstadter’s law into account. Founders who hear “figure it out as we go” eventually realize they’re paying for the figuring.
Why Founders Trust the Pause More, Not Less
This is the part I didn’t expect when I started doing it.
The first few times I held off on committing to a timeline, I assumed the client would read it as hesitation, even incompetence. The opposite happened. Most founders I work with have been burned by an agency or a dev shop that quoted fast and then quietly extended the deadline twice. By the time the project finished, the original estimate was a memory, not a benchmark.
When I say “I need to come back after analysis,” what they hear (most of the time) is: this person is taking the question seriously. The response I get most often is some variation of “thank you, that’s actually refreshing.” A founder building a B2B SaaS analytics tool told me later that the 24-hour wait was what made him trust me with a six-figure budget. He said the agencies he’d talked to before all promised same-day estimates, and the projects had a habit of ending in legal disputes.
There’s a small percentage of cases where the pause works against me. Founders with hard deadlines (a board meeting in three weeks, an investor demo) sometimes need a number now, even if it’s wrong. For those cases, I’ll quote a wide range with a strong caveat: “Based on what I know in this call, this is somewhere between four and seven weeks. I’ll narrow it tomorrow. If you need to make a budgetary decision today, plan for the seven.” The seven is what they should plan for. The four is the version where everything goes right.
I don’t use this format when I have time. I use it when the client’s calendar makes 24 hours feel like a luxury. It’s a fallback, not a default.
The Three Numbers I Come Back With
When I send the brief, I include three numbers, not one.
Best case. The version where every assumption holds. The data is clean, the integration works the first time, the eval shows the model is performing within target on day three. I write this number knowing it’s the version of the project that almost never happens.
Realistic case. This is the number the client should plan against. It assumes one or two things go sideways, the test set takes a half-sprint to refine, and at least one round of “we thought this would work but it doesn’t” happens during the build. Most of our projects land within 10% of the realistic case. That’s the track record I’m willing to defend.
What could push it back. This is the number clients remember even though I deliberately don’t make it the headline. It’s the version where the hidden cost I named in step 2 turns out to be larger than expected, or the client’s data isn’t ready when we start, or a scope change in week two adds two sprints. I list the specific reasons, not just the buffer. Naming the risks is what gives the realistic number its credibility.
The worst projects I’ve seen had a single number on the original quote and no version of “what could push it back” written down anywhere. By the time the push-back happened, there was no shared language for it, and the conversation became about blame instead of adjustment.
When I Still Get It Wrong (Because I Do)
Last quarter I missed an estimate by about 30%. The project was an internal knowledge agent for a midsize fintech, and on paper it looked like work we’d done before. RAG over policy docs, a chat interface, an admin panel. K, K, K.
What I didn’t catch in the analysis: the policy documents were in 11 different formats including scanned PDFs from 2017, half of them in two languages, and several had been amended via tracked-change Word files that were treated as authoritative even though the originals were stored separately. The client had described their corpus as “well-organized” because, from their team’s perspective, it was. They knew which documents were current and which weren’t. We didn’t.
We discovered this in sprint two. I’d quoted six weeks, realistic case. We delivered in eight, with three sprints instead of two on the data preparation alone.
The recovery wasn’t graceful. It involved a mid-project conversation I didn’t enjoy, a re-scoped sprint plan, and an adjustment to the fixed-bid number we’d agreed on. The client stayed because I’d documented the “what could push it back” section in the original brief and one of the items was almost exactly the situation we hit. That document didn’t make me right. It made the conversation possible.
The lesson I took away: the analysis window needs to include a request to see the actual data, not just hear it described. I’ve added that to the discovery process now. Every project where data is the foundation gets a “show me five real examples” step before I write the estimate. It’s saved me twice in the last three months. The five questions I ask every client before we write a single line of code include that question explicitly now, and it’s the one I added after this fintech project.
The Estimate Discipline Is the Project Discipline
The way I think about it now: the discipline of saying “I need to come back after analysis” is the same discipline that makes the rest of the project run cleanly.
A PM who commits to a number under pressure is a PM who’ll commit to scope changes under pressure later. The pause at the start trains everyone (client, engineering team, and me) that decisions get made on evidence, not on whoever’s loudest in the room. That posture carries through the whole engagement.
The other thing it does, which I underestimated when I started: it filters clients. The founders who get irritated by a 24-hour analysis window are usually the ones who’ll be irritated by every other reasonable boundary too. The ones who say “yes, that’s how I’d want to work” are the ones who become repeat clients and the ones who refer their network. The 24-hour pause is, weirdly, one of our better qualification tools. It’s not designed as one. It just turns out to work that way.
If the only thing you take from this post: stop quoting timelines on new requirements without analysis. The analysis doesn’t have to look like ours. Use whatever process gives you a number you can defend. But don’t let the call’s social pressure produce an estimate that’s going to embarrass you in three weeks. The client doesn’t want a fast number. They want a true one.
FAQ
Why won’t an AI development services team commit to a timeline upfront?
Good ones will, when the work is similar to projects they’ve shipped before. They won’t (or shouldn’t) commit on the call when the requirement involves data they haven’t seen, an integration they haven’t tested, or an accuracy threshold they can’t yet measure. The reason isn’t caution for its own sake. It’s that fast estimates on unfamiliar AI work tend to be wrong by 30-100%, and by the time the wrongness shows up, the client has already planned a launch around the original number.
How long should the analysis window be before committing to an AI project timeline?
For most requirements, 24 to 48 hours is enough. The analysis isn’t about modeling the entire project. It’s about identifying the unknowns, talking to engineering, and writing a defensible range. If a PM tells you they need two weeks to give you any number, that’s a different signal: either the requirement is genuinely complex (in which case the wait is justified) or the team is using analysis as a way to delay an awkward conversation. Push back gently and ask what specifically they’re investigating.
What if I need to make a decision today and can’t wait 24 hours?
Ask for a wide range with a caveat. A reasonable PM should be able to give you a “between four and seven weeks” type answer in the call, with the understanding that the upper end is what you should budget against. Don’t take the lower number as a commitment. If you have a hard deadline (board meeting, investor demo), tell them up front so they can structure the estimate around the constraint.
How do you handle scope changes that happen mid-sprint?
Every scope change goes into the sprint handoff document with a “what changed” entry that names the trade-off explicitly: what we added, what we deferred, and how it affects the realistic-case timeline. Both sides see it, both sides confirm it. We never accept a scope change verbally and figure out the impact later. The handoff doc is what makes the change visible before it becomes a disagreement.
What’s the difference between “I don’t know yet” and “I don’t know how to do this”?
A big one. “I don’t know yet” means the engineering pattern is familiar but I haven’t sized the specific requirement. “I don’t know how to do this” means we’d be learning while building, which is different work and should be priced as a research spike, not a fixed bid. A good PM will tell you which one they’re in. If they conflate the two, you’re going to have a bad time at week three.
Thinking about an AI build and not sure what’s a fair timeline? Book a 30-minute call and I’ll walk you through the analysis I’d run on your specific requirement, including what I’d flag as a known and what I’d want to dig into before quoting.
