Insights
By Ege Engin Özdaş (Co-Founder & CEO), Şener Özer (Co-Founder & CTO) & Gökçe Özyurt (Co-Founder & CPO) — Staterics · Published 2026-08-03 · Updated 2026-08-03 · 14 min read
The short answer: AI implementation takes anywhere from two weeks to five months or more. McKinsey puts most generative AI applications at one to four months to deploy, with custom-model projects roughly 1.5 times likelier to run five months or longer. In Staterics builds the dates are fixed: AI employees live within 14 days of data handover, the complete operating system within 90 days, counted from handover rather than signature.
How long does AI implementation take? In Staterics builds, the answer is two dates: your first AI employees are live within 14 days of data handover, and your complete AI operating system within 90 days. Day zero is the day your data and system access arrive — not the day you sign.
The calendar behind those dates runs like this: what happens in each stretch of days, and what is due from you and when. It also covers why the phase most roadmaps spend longest on does not exist here, what makes a timeline slip, and what happens if we miss.
Implementing AI in a business depends on three things: whether the system needs custom-trained models, whether your data has to move into new software, and how fast your side approves.
The most useful public anchor is McKinsey’s research on generative AI uptake: 78% of organizations use AI in at least one business function. Most generative AI applications are deployable in one to four months, and custom-model projects are roughly 1.5 times likelier to run five months or longer. The long timelines cluster around model training. An AI operating system built on existing models sits at the other end of that range.
Those questions bracket you before any vendor opens a calendar. Of the three, the middle one moves the most days: replatforming is software-project work, and it turns a weeks-long build into a months-long one.
A range without a start date is not a timeline. It is a mood.
A fourth question decides more than those three, and almost nobody answers it: what starts the count?
Ask any vendor one question before comparing timelines: what event starts your count? Signature, kickoff, and data receipt can sit a month apart, and a plan counted from an unnamed Monday can never be late — it never started.
Our answer is data handover. It is complete when we hold all five of these:
An incomplete handover moves the start, never the finish.
The day the last item lands is day zero. If the rest arrives ten days later, day zero is ten days later; we would rather move the start than miss the finish.
What you hand over stays yours: trained only on your data, never pooled, and handed back if you leave.
Here is the calendar in days, with each stretch’s owner named.
We turn your handover into explicit rules: what the AI answers, what it routes to a person, and what it never says. It never guesses at a price it has not been given, gives medical advice, or commits on your behalf. The rule set arrives in writing on day 3, and correcting it is your only job this week.
Your AI employees are built against the corrected rule set and connected to the systems you already run, in the languages agreed during your build. Nothing changes platform: the connections work where your data already lives. We need little from you beyond same-day answers.
We run your AI employees against real cases from your history — the awkward call, the ambiguous booking, the customer asking for a price you never quote by phone. Your staff mark what is wrong. Corrections here are wording and authority, not architecture, so they land same-day.
On day 14 your AI employees take real traffic, and recurring billing starts that day, not before. From day 15 the rest is built around them: department interfaces, owner reporting, and the remaining workflows one at a time, until the whole system is live within 90 days of day zero.
Two things this calendar does not contain: a data-migration phase, because nothing migrates, and a development invoice. The build costs $0 and recurring billing starts at go-live, so every day we add is a day we are not paid for.
Any AI implementation asks three things of the buyer: one person who can decide, credentialed access to the systems the AI has to reach, and staff time to correct its answers before customers see them. The third is the one buyers underestimate: an uncorrected system goes live guessing.
A build here costs less time than a software rollout and more than a subscription: one named owner, three to five hours a week for two weeks, then about an hour a week through day 90. Nobody on your side writes anything technical.
| Ours | Yours — and by when |
|---|---|
| Turn your documents and transcripts into an explicit rule set, in writing on day 3. | Complete the handover list before day 0. Read and correct the rule set by day 5. |
| Build the AI employees and connect them to the systems you already run. | Issue access to a named account, and answer build questions within a day. |
| Rehearse against real cases from your history, correcting wording the same day. | Two people, two short sessions, days 11 to 13. Bring the calls you dread. |
| Take the system live on day 14 and watch the first real traffic. | Tell your team it is live, and route the awkward cases to it in week one. |
| Build out the remaining departments through day 90. | An hour a week: approve each department's rules before it goes live. |
That is the whole ask. If you are weighing this against adding a person, the comparison is on its own page; the timeline half is short, because a hire needs a posting and a notice period.
In the standard five-phase plan — discovery, data preparation, build, integration, testing — integration is the phase that contains the least AI. It is where your data is exported into a vendor’s system and your team is retrained on new screens.
We removed that phase rather than shortening it. There are no software migrations in our builds: the platform connects to the tools you already run and works where your data lives.
| A migration build | A no-migration build |
|---|---|
| Your data is exported, mapped, and loaded into the vendor’s system first. | Your data stays where it is. The AI works through the systems you already have. |
| Your team learns new screens, so adoption becomes a training project. | Your team keeps its screens. What changes is how much work reaches them. |
| Integration is billed like build time, and it is where estimates quietly slip. | The phase does not exist, so it cannot slip. Those days are the difference between weeks and months. |
That arithmetic is most of the distance between a 14-day answer and a six-month one. What we cannot delete is the phase before it: turning what your team knows into rules a system can act on. That is the longest stretch inside our 14 days.
It is data: its state, and how fast a human answers questions about it. Every build waits on rules that have to be found, written down, and approved before a system can act on them. A rule that lives in one person’s head is the slowest kind to extract. Scope creep runs close behind: the first build works, somebody sees a second use case, and the date absorbs it.
Integration with existing software carries the widest range of any phase in a standard plan, and it is not the AI that stretches. It is the plumbing around it: credentials held by an outside vendor, fields mapped one at a time, a cutover staffed on a weekend.
One caution about phase durations, ours included. Most published implementation timelines give week counts with no study behind them. Ours are commitments with a stated consequence if we miss, which is a different kind of number.
Five triggers are what a Staterics calendar budgets against. Each carries the days it allows for and the move that removes it. These are allowances, not observed averages: the company was founded in 2026, and we do not dress estimates up as data.
Two of those five are ours to prevent and three are yours, which is why your obligations above carry dates. A sixth risk moves no date and costs the most: nobody sends the system work in week one. Agree what it answers and what it routes before day 14, so week one is real traffic rather than a pilot.
Timeline pages tier by project type: chatbot fast, enterprise platform slow. That is the wrong axis. What moves your dates is the state of your business on the day you hand over.
Company size is not the axis: we build for single locations and for enterprises alike. A single-site clinic with a current price list moves faster than a fifty-site group running twelve systems. The larger group’s dates are just as fixed once day zero is named; what stretches is the days 15-to-90 build, not the 14.
We do not publish return figures or client performance numbers. A payback period quoted for a system that does not exist yet is a guess with a decimal point on it. What can go on a calendar is when the measurable things start to exist.
Day 14 answers the first calls and handles the first messages, and from that day you have counts: what came in, what was handled, what was routed, and at what hour. Days 15 to 45 give you a first continuous month: after-hours volume, response times, which questions repeat. At day 90 the complete system is live, and reporting draws on the whole operation rather than one channel.
Live on day 14, measurable from day 14, comparable from around day 45, complete at day 90. There is no pilot phase in that sequence, because a pilot that never converts produces no numbers at all. The first build goes live into real traffic, or it has not gone live.
Be clear about what that reporting is. It surfaces what already moves through your operation: calls, messages, bookings, and the hours they land in. It does not read minds, and it promises no result.
Annual plans are the one exception to go-live billing: the annual platform fee is split into a deposit up front and a balance on delivery — still platform fee, not development cost. If delivery runs past day 90, you choose: 100% of the deposit back, or pay the balance only on delivery. The trigger is the calendar date, not an assessment of progress.
Two more numbers belong beside a timeline. Billing has two lines: a platform fee from $750 per month depending on system complexity and number of users, and AI usage metered in RIC Tokens. The token meter runs across voice and text together, billed monthly in arrears. Development costs $0, and apart from that annual deposit, recurring billing starts the day you go live. The cost article breaks down what moves each line.
One scheduling limit we publish rather than bury: up to 10 new builds a month. Current deployments include Doruk İşitme and IMTEK Cryogenics, and each holds a place in that queue for its 14 days. If the month is full, your day zero moves, and you hear it before you sign.
If you want your own dates, start where we start: the free 45-minute Operations X-Ray. You leave with a friction map: where the manual work sits, and the three workflows a system would take first. It is yours whatever you decide, and after it the only date left to set is day zero.
It depends on whether custom models are trained and whether your data has to move into new software. McKinsey’s research puts most generative AI applications at one to four months to deploy, with custom-model projects roughly 1.5 times likelier to take five months or more. In Staterics builds, AI employees are live within 14 days of data handover and the complete operating system within 90 days.
It depends on the vendor, so ask which event starts the count: signature, kickoff, and data receipt can sit a month apart. In Staterics builds the clock starts at data handover, the day your operating documents, system access, handling rules, and a named decision-maker are all in hand. If part of the handover arrives late, day zero moves later rather than the finish date moving earlier.
Usually faster than large ones: fewer systems to connect, shorter approval chains, and one person who knows every rule in the business. In Staterics builds the constraint on a small operation is rarely complexity — it is finding three to five hours a week from the owner during the first two weeks.
Longer to agree than to build. What stretches is reconciling rules that differ by site and collecting approvals from more than one decision-maker; the technical work barely changes with site count. In Staterics builds the 14-day date for the first AI employees holds once day zero is named, and what extends is the days 15-to-90 rollout across the remaining sites and departments.
Not for an implementation built on existing models. That work needs decisions and system access from you, not data scientists, and the engineering sits with the vendor. Custom-model projects are the exception, and they are also the ones McKinsey associates with schedules past five months. Staterics builds train existing models on your own documents and rules, so nobody on your side writes anything technical.
On a conventional AI implementation it is a phase in its own right: export, field mapping, cutover, and a period of running the old and new systems in parallel until the switch. In Staterics builds there isn’t one. Your data stays in the systems you already run, and the AI reads and writes there, so there is no export, no cutover, and no parallel-running period to staff.
Two different things get called training. Training a custom model on your data is the case McKinsey associates with the longest schedules: those projects are roughly 1.5 times likelier to run five months or more. Giving an existing model your documents, rules, and past conversations takes days. Staterics builds do the second, inside the 14 days rather than after them. Mapping runs days 0 to 3, building days 4 to 10, and rehearsal against real cases from your own history days 11 to 13. The system is trained only on your business’s data, and that data is never pooled with anyone else’s.
Any AI implementation needs three things from the buyer: one person who can decide, access to the systems the AI has to reach, and time to correct its answers before customers see them. A Staterics build asks for one named decision-maker, three to five hours a week for the first two weeks, and about an hour a week through day 90 to approve each department’s rules before it goes live. Two people join two short rehearsal sessions on days 11 to 13.
Four moves shorten almost any implementation: hand over the data in one pass, name one approver who can decide without a meeting, request system credentials before handover, and keep new ideas out of the first build. In a Staterics build those new ideas route into the days 15-to-90 lane instead of the first 14, which is where most missing days come from.
Most implementation timelines carry no stated consequence, so ask what happens when the date passes. On a Staterics annual plan you choose: 100% of the deposit back, or you wait and pay the balance only on delivery. The trigger is the calendar date, not an assessment of progress. That deposit is the one exception to go-live billing: it is part of the annual platform fee, split into a deposit up front and a balance on delivery, not a development cost. Development costs $0, and billing otherwise starts the day you go live. It has two lines: a platform fee from $750 per month depending on system complexity and number of users, and AI usage metered in RIC Tokens.