Why twenty-one days and not eight months.

Every project Jigen accepts ships to production in twenty-one days. Not a tagline. An industrial choice — and one that filters out a significant slice of the market. Worth explaining why we chose this number, what fits inside it, and — above all — what doesn't.

The complexity myth

The technology consulting industry has built its revenue model on the word complexity. The more inflated the estimate, the more reassured the stakeholders: if it's expensive and long, it must be serious. Construction-site logic applied to software that, in reality, lives on rapid iterations and pre-trained models whose next version ships every three or four months. Eight-month roadmaps don't describe the difficulty of the problem. They describe the cost structure of the agency proposing them: meeting rooms, mid-tier project managers, approval cycles, alignment meetings, meetings about meetings.

When an agency sells you an eight-month AI project, it's selling you time, not output. The suspicion is confirmed at delivery in most cases: presentations, mockups, conceptual frameworks, and a handful of fragile automations the client won't be able to maintain on their own.

The final bill isn't only financial. It's the loss of internal momentum: six months of meetings in which management has stopped making operational decisions because "we're waiting for the platform". That's the real hidden cost of long timelines, and it doesn't appear in any quote. The metric that really measures the damage isn't the vendor's cost — it's the number of decisions deferred inside the company during those six months. Typically high. Typically unrecoverable.

Why twenty-one and not fourteen, not thirty

The number isn't arbitrary, and it doesn't come from a market benchmark. It comes from an operational constraint we measured on our first cycles. Three weeks is the minimum window in which a hybrid human-AI team can complete the four passes needed to take a system from zero to production: understand the domain, build the architecture, integrate with the client's systems, harden the system to an acceptable reliability level.

Fourteen days — two weeks — force you to skip hardening. You get to a demo that works under controlled conditions but doesn't survive the edge cases of the real world. You deliver a prototype, not a system. Thirty days — a month — on the contrary are already enough to inject the "we're finishing" pattern: a team at the start of the month doesn't have the same operational pressure as the team at day eighteen out of twenty-one. The intensity curve drops, scope swells, and you arrive at day thirty with a system that's almost ready but not yet closed.

Twenty-one days sit at the point where the constraint is still rigid but the work is still possible. It isn't an opinion: it's an empirical balance we found experimentally and then sealed into the contract.

Anatomy of the cycle · day by day

For those who've never seen it from the inside, a Jigen cycle isn't a month of work distributed evenly. It has a precise structure with four hinges:

Day 1-3 · Obsolescence audit. The first deliverable of every cycle isn't what the client expects. It's a short document declaring what shouldn't be built. It identifies processes that look like automation candidates but are actually already dead (low residual volume, marginal cost already flat, opportunity return close to zero). The obsolescence audit is the filter that prevents us from spending the next eighteen days working on a system nobody will use on day twenty-two.

Day 4-7 · Architecture and first integration. Routing across models is decided (Claude 4.x for reasoning, GPT-5 for high-volume tasks, Gemini 3 for contextual search), orchestration is written, the first real integrations are run — not simulated data, the client's data. On day seven there's the first working demo. Not a "demo" in the slide sense — a system that runs a full loop of the logic on real data and produces a validatable output.

Day 8-14 · Hardening. You find what breaks. Provider fallbacks, output validation, structured logs for deterministic replay, refusal rules below confidence threshold. This is the week that separates a prototype from a system. It's also the most tedious, and the one where most vendors lower quality — because it isn't visible in demo and nobody is measuring it.

Day 15-21 · Production + observation. Ships to production, behaviour on the client's real traffic is observed, corrections are made on the fly. On day twenty-one the system must have moved a concrete metric — a reduced cost, an increased conversion, a shortened response time. Without a measurable number, the cycle doesn't close.

The obsolescence audit · why we do it first

It's the part of the method that surprises clients the most. They expect to pay to build something; they start with us explaining what not to build. Most companies that contact us arrive with a list of three or four processes that are candidates for automation. On average, only one of these actually deserves a system. The other two or three are:

• Processes already in structural decline (volume falling thirty per cent year on year — automating a cost that's disappearing on its own doesn't move cash).
• Processes that generate revenue but not margin (automating lowers the cost, but the price follows down because the market commodifies — illusory advantage).
• Processes that work because they're done by hand (classic example: consultative pre-sales; replacing the human reduces conversion more than it saves).

The obsolescence audit has a cost: three days that don't look like "execution". It has a much bigger benefit: the next eighteen days are spent on the one process that actually matters. When a client accepts this logic, they get measurable results. When they reject it — "we want to automate all three" — they usually end up with three half-built systems, and we've decided this is a deal we no longer sign.

What changes when you commit to 21 days

The temporal constraint forces three behaviours most agencies can't sustain.

First · scope discipline. Three weeks don't allow accessory deliverables. You decide what ships to production and what gets dropped, no compromises. The "we could also do X" of the first week becomes "let's just do Y" on day five, because everyone understands that Y in production is infinitely more valuable than X+Y in demo.

Second · model selection. There's no time to train anything from scratch. You pick the right model for the task — long reasoning, structured extraction, classification, writing, fast tool-calls — and you orchestrate it. The value lives in the orchestration across frontier models, not in the illusion of a "home-grown proprietary agent". The vendor proposing custom fine-tuning before having shown that retrieval isn't enough is selling hours, not a system.

Third · automation-first posture. Every manual step that isn't an explicit client decision is removed. Jigen itself is built that way: engineered and automated internally before externally. Our status calls are recorded notes, not meetings. Our project management is a shared kanban, not a master plan. We transfer it as a method because we did it on ourselves first.

The closing criterion · measurable number, not demo

On day twenty-one the cycle closes on a criterion stated in the contract on day zero. It isn't "the client is happy" — too subjective. It isn't "the system runs" — a prototype also runs, in the lab. The criterion is a measurable metric on the client's business: conversion rate on a channel, average response time on a process, cost per operation of a function, hourly volume of a task. Agreed before, measured after, binary yes/no.

If on day twenty-one the number has moved, the cycle is closed and the system belongs to the client. If it hasn't moved, the contract provides three options: renegotiate scope (the problem was different from what we thought), continue with a second cycle at reduced cost (the diagnosis was right but execution needs a second pass), or clean exit with code handed over as-is and partial refund. The three options are written before signing. They aren't negotiated on day twenty-one with the phone in hand.

Implicit pricing model

The twenty-one-day cycle implies a specific tariff model. No time and materials. No hourly billing. No "I'll send you a breakdown of who worked when". The client pays a fixed price per cycle, decided before signing on the basis of the process to be automated and the target number to be moved. The vendor — us, in this case — takes on the execution risk: if on day fifteen we realise we've underestimated complexity, we lose margin, we don't transfer it to the client.

This model isn't universal, and it doesn't work for every kind of vendor. It works when the vendor has already run enough cycles to predict risk precisely. A vendor at their first or second cycle shouldn't operate on fixed price — they lack the historical data. We can do it because we have cycles behind us. The vendor offering fixed price without ever having closed comparable cycles is improvising.

What doesn't fit in twenty-one days

A complete ERP migration. A multi-tenant SaaS platform from scratch. The rewrite of a banking core. The data governance of a multinational group. For these projects other teams exist, and they do well to exist. Jigen doesn't accept them as a block. Not for technical limits, but for honest positioning: our market is whoever already has a validated process and wants a lever — an automation that cuts a cost, an agent that fills the pipeline, a system that runs an existing workflow at twice the speed. It isn't reduced ambition. It's concentrated ambition.

That doesn't mean we refuse large-scale challenges. We simply attack them differently. If the infrastructure to be built is objectively complex, the project is surgically broken into multiple sequential cycles. Each cycle lasts twenty-one days and closes not with a presentation, but with code in production and a metric moved. This way, six months of work become nine twenty-one-day cycles, each with its own number, each independently evaluable. The client doesn't wait six months to see if the plan works. They see it on day twenty-one of the first cycle, and they can decide whether to continue or stop before having spent the annual budget.

Quick test · is your problem "twenty-one-day"?

An operational grid for the leadership of a company considering an AI vendor. Five questions:

1. Is the process you want to automate already defined on paper? If yes → cycle compatible. If no → needs an obsolescence audit first, then the cycle.
2. Is the data needed accessible today, or does data infrastructure need to be built first? If accessible → compatible. If missing → there's a cycle-zero to do first, dedicated to data access.
3. Is there a single owner for the process, with approval authority? If yes → compatible. If no → there's an organisational issue that precedes AI (see article on "companies aren't ready").
4. Do you have a clear metric that must move, and do you know by how much? If yes → compatible. If no → it needs to be defined, and this becomes the output of the first cycle (audit + target metric).
5. Are you willing to accept that the first cycle may end with "we don't do it"? If yes → compatible. If no — if you expect the vendor to deliver "something" anyway on day twenty-one — we aren't the right interlocutor.

Five yes out of five: cycle compatible, we go. Three or four yes: cycle compatible after a brief realignment. Two or fewer: the problem isn't a twenty-one-day one, it's a prerequisites problem — and no vendor can sell you the prerequisites.

The cost of delay

There's an argument nobody makes, and it should be the first. The AI market moves on cycles measured in weeks. A model released in March is already superseded by July. An outreach pipeline that worked in January starts losing response rate by April. Planning eight months of development means signing a contract based on assumptions that won't be true anymore at delivery. Every day beyond twenty-one is a day of ageing hypotheses.

The clients who understand this point don't ask for time discounts. They ask for rigour. They want to know what ships to production in week three, not week four. They want a system that moves margin, not a dossier that describes a system that one day will move margin.

There's also a less obvious consequence, but more important for whoever runs a company: a short timeline drastically reduces risk. A three-week project can be stopped at week two if the signals aren't right — the loss is contained. An eight-month project, after the third, can't be stopped anymore, because stopping it means admitting the initial quote was wrong. Political pressure wins over technical rationality, and you arrive at delivery by inertia, not on merit. Twenty-one days protect the client's leadership from itself: every cycle is short enough that stopping it never becomes politically impossible.

Twenty-one days. It's the operational contract. Everything else — the models, the stack, client qualification, our internal structure — flows from there. It's the signature number of the Jigen brand because it isn't a marketing claim: it's the industrial constraint that lets us not be another agency. If tomorrow we figured out the right number is eighteen, we'd change it. For now, twenty-one is what holds.