How to Ship AI Features in Weeks, Not Quarters
Speed isn't recklessness. The teams that ship AI in weeks aren't skipping the hard parts — they've removed the parts that were never adding value. Here's the operating model I use when the job is production software, not a slide deck about AI.
Operating constraints (non-negotiable)
Scope to one outcome. Pick the single outcome that matters and cut everything else from v1. A narrow, real feature in production teaches you more than a broad prototype that never ships.
Decide before you build. Most delay is decision latency, not engineering. Get the decision-maker in the room, agree on the definition of done, and write it down before a line of code.
Build on what exists today. Use the model, framework, and infrastructure you can deploy now. Future capabilities are upside, never the plan.
Instrument from day one. Ship with the metric wired in. You can't improve what you didn't measure, and "it feels better" doesn't survive a budget review.
Hand it off on purpose. Working software plus the know-how to run it. The goal is a team that doesn't need you for day-to-day — that's what makes the next engagement easy.
Definition of done (write this in week zero)
Done means all of the following — not a subset:
- Real users in production (not staging-only, not "demo mode")
- One success metric live with a pre-ship baseline
- Named owner who reviews the metric weekly and owns prompt/config changes
- Data boundaries written — what's allowed in, what's off-limits, which vendors are approved
- Failure path — how a bad output gets caught, corrected, and logged without paging half the company
- Handoff notes — how to run it, where the knobs are, what to check Monday morning
If any of those are "we'll add later," you don't have a ship date. You have a hope date.
Week-by-week shipping template
Use this as a calendar, not a vibe. Adjust days, not the order. Skipping ahead without the prior week's outputs is how "two weeks" becomes twelve.
Week 0 — Clarity (before the build clock starts)
- Problem in one sentence; metric + baseline written
- Decision-maker named; definition of done signed off
- Data path and tool approvals confirmed in writing
- Smallest production slice agreed (what ships, what is explicitly cut)
- Repo, environments, and access ready — no "we'll set that up Monday"
Exit gate: One page. If you can't fit the plan on one page, the scope is wrong.
Week 1 — Thin vertical slice
- Build the happy path end-to-end for the narrowest real case
- Wire the metric (even if the UI is ugly)
- Run against real (or realistically messy) data — never only golden samples
- Log failures; fix the top failure modes in-product, not in a spreadsheet of "phase 2"
Exit gate: A user who isn't on the build team can complete the core flow once without a walkthrough from the engineer.
Week 2 — Harden and hand off
- Cover the failure cases that showed up in week 1
- Add the human override / review step if the feature needs one
- Finish owner docs: how to monitor, how to change prompts/config, who to call
- Ship to the agreed production audience; start the metric clock
- Kill scope creep that arrived mid-build — park it in a dated backlog
Exit gate: Definition of done checklist is actually checked. Owner can run the weekly review without the builder in the room.
Week 3 (optional buffer) — Only if regulated or multi-party
Use a third week when compliance review, security sign-off, or a second team's integration is genuinely on the critical path — not as padding for unclear scope. Same rules: no new features, only the gates that unblock production.
What "weeks" actually looks like on the calendar
A two-week AI ship is not hero hours — it's protected focus plus frozen scope. Rough shape for a one-to-two person build:
- Decision-maker: available for a 30-minute checkpoint at the end of week 0, week 1, and before production cutover. Async Slack is not a substitute for "is this still the outcome?"
- Builder time: mostly uninterrupted blocks on the vertical slice. Meetings that renegotiate scope get bounced to the dated backlog.
- Owner (future operator): joins the week-1 demo and the week-2 handoff so they're not meeting the system on day one of production.
- Stakeholders who aren't decision-makers: get a short written update, not a working session. Extra opinions mid-build are how weeks become quarters.
If you can't get the decision-maker twice in two weeks, you don't have a fast project. You have a slow organization wearing a tight estimate.
Anti-patterns that turn weeks into quarters
Discovery without a kill date. "We're still exploring" past week 0 is not diligence — it's avoidance. Spike for days, decide, cut.
Building the platform first. Platforms are how teams delay learning. Ship the feature; extract shared pieces only after the second real use case demands them.
Demo as a substitute for production. A polished walkthrough for leadership is not a ship. If users aren't on it and the metric isn't live, you're still in week 1.
Waiting on the next model. "It'll be better when the model updates" is how forever-pilots are born. Design for today's capability; treat upgrades as free upside.
Committee ownership. Five stakeholders, no single owner, weekly alignment meetings that renegotiate scope. Pick one person who can say done.
Metric theater. Tracking "AI interactions" or "prompts run" instead of the business outcome you named in week 0. Vanity usage numbers hide stalled value.
Security as a surprise. Dropping Legal a week before launch guarantees slip. Data path and approvals belong in week 0, boring and early.
Handoff as an afterthought. Builder leaves, nobody knows which prompt file is canonical, metric dashboard breaks silently. If the owner can't operate it Monday without you, you didn't ship — you visited.
A note on quality vs speed
Fast shipping is not "lower the quality bar." The bar that matters for v1 is narrow and high: the one outcome works in production for real users, the metric is honest, and bad outputs have a path. What gets cut is adjacent ambition — extra personas, nice-to-have dashboards, speculative agent behaviors, and "while we're in there" refactors.
If someone asks for more time to make it "enterprise ready," translate that into a checklist: which definition-of-done item is missing? If the answer is "vibes" or "more polish," ship. If the answer is "Legal hasn't approved the data path," that was a week-0 miss — fix the process, don't romanticize a longer build.
How to start Monday
Open a doc. Title it with the outcome, not the technology ("Triage under 8 minutes," not "AI support bot"). Fill definition of done. Book the decision-maker for a 45-minute week-0 review. Then protect the calendar like the ship date is real — because if it isn't protected, it isn't.
If you want help turning that one-pager into a two-week build with a clean hand-off, that's the Builds conversation. If you're not sure the problem is even build-shaped yet, run the seven questions first — clarity is cheaper than a sprint that should never have started.
Frequently asked
Yes, when scope is tight and success is defined up front. We've taken HIPAA-regulated and customer-facing AI software to production in roughly two to three weeks with one to two people. The constraint isn't headcount — it's decision latency and scope discipline.
Unscoped discovery and missing decision-makers. The build is rarely the bottleneck; ambiguity is. If the person who can say 'done' isn't in the room in week zero, you're already behind.
Production users, one instrumented metric, a named owner, written data boundaries, and a path to fix bad outputs without a war room. A demo is not done. A prototype behind a feature flag with no owner is not done.