Is ninety days repeatable on any project?

No. That pace assumes a narrow initial scope, one decision-maker available weekly, and no blocking external dependency. When a regulatory constraint or a third party is involved, they set the timeline, not coding speed.

Is AI-assisted code lower quality?

Quality depends on review, not on which tool produced the first draft. Code that is generated then read, tested and corrected is worth as much as code hand-written then read, tested and corrected. The real risk is accepting without reading, and that is handled by process.

Why bill fixed price rather than hourly?

Because hourly billing penalises speed and rewards stretching. A fixed price per scope gives the client a budget known upfront and gives us an interest in shipping fast and right.

What happens if the scope changes mid-project?

Scope is the adjustment variable, not the date. An addition means an explicit trade-off about what comes out in return, decided at the weekly session. A further milestone becomes a new fixed price.

Shipping a product in 90 days: what AI changes, and what it does not

We state that an investment platform shipped in roughly ninety days, at about one hundred and six thousand lines of code. The figure sounds impressive, which is exactly why it deserves to be taken apart. Here is what it covers, what AI genuinely accelerates, and what it does not accelerate at all.

What “one hundred and six thousand lines” means

A line of code is not a unit of value. That volume includes database migrations, tests, configuration files and tool-generated code. A developer can triple the number by changing formatting style.

What the figure really conveys is the breadth of scope: authentication and role management, an onboarding journey with identity verification, electronic signature, dashboards, an admin back office, transactional messaging, and the deployment infrastructure around it. At a conventional pace, that scope is planned over six to nine months.

One more clarification, because honesty about numbers is part of the job: another of our projects shows a comparable volume, but it is mostly an off-the-shelf e-commerce theme, of which only a small share was written by us. We do not count those lines among our work.

What AI genuinely accelerates

The first draft

Writing a data access layer, a complete form with its validation, an integration test suite: this is known, repetitive work, and it is where the gain is clearest. What took a day takes an hour or two.

Crossing unfamiliar ground

Integrating an API you are discovering used to mean hours of documentation reading. The gain comes less from generated code than from the reduced time spent understanding.

The unglamorous work

Migrations, large-scale renames, dependency upgrades, writing the missing tests. These are low-decision, high-volume tasks, exactly the profile where assistance pays off most.

What AI does not accelerate

This is the part rarely written down, and it is what decides whether a project holds its dates.

Deciding what to build. No assistant will tell you which product deserves to exist. That decision remains the main bottleneck.
Getting business answers. If a functional question takes five days to answer, the project advances at five days per question, whatever the coding speed.
External dependencies. A bank account, access to a regulated API, a legal sign-off: these delays do not compress, and they are the leading real cause of slippage.
The quality of existing data. Taking over an inconsistent history demands analysis that nothing compresses.
Trust. Software handling money or personal data requires checks that take the time they take.

Put differently: AI moved the bottleneck from writing to deciding. That is good news, provided the project is organised accordingly.

The method that makes the pace sustainable

Fixed price, never an hourly meter

Billing by the hour when you write quickly means penalising your own efficiency, and it rewards stretching engagements. A fixed price per scope aligns both sides: we gain from shipping fast and right, you get a budget known upfront.

A weekly session, with something running

No slides, no monthly committee. Every week, a deployed version you can use. That is what lets a scoping mistake be caught in week two rather than month four.

Scope is negotiable, the date is not

When something unexpected happens, the adjustment variable is the feature list, not the go-live date. That forces continuous triage, which is precisely the exercise missing from most projects that slip.

Visibility is built in, not bolted on

Server-side rendering, URL structure, structured data and crawler accessibility are architecture decisions. Adding them later costs several times as much, and it is the situation we meet most often with clients arriving with a product already built. Those choices are detailed in our guide to GEO.

What has to be true for it to work

Three conditions, and all three sit on the client side rather than the supplier side.

One decision-maker, available an hour a week. Not a committee. One person who can settle a question.
A narrow initial scope. A product that does one thing completely, rather than a full platform half finished.
Accepting that some work gets thrown away. Part of the first weeks exists to learn, and will be replaced. That is the price of speed, and it costs less than spending months building the wrong thing.

Without those three conditions the ninety-day pace is not reachable, and promising it would be dishonest.

This way of working has a name: it is the Forward Deployed Engineer role. Our packages and prices are listed on the home page.

How the ninety days actually break down

The breakdown often surprises, because it does not match the curve people imagine. Here is the order of magnitude observed on the investment platform, in weeks.

Period	What happens	Share of time
Weeks 1 to 2	Understanding the business, setting the architecture, first release	15%
Weeks 3 to 7	The functional core, at a sustained pace	35%
Weeks 8 to 10	External integrations, and the waiting that comes with them	20%
Weeks 11 to 13	Edge cases, security, verification, going live	30%

Two lessons. First, the functional core, the part everyone imagines as long, takes about a third of the time. Second, the final third, handling edge cases and security, is as long as the core, and it is the one systematically underestimated in quotes.

The risk peak is not at the start but around week eight, when external dependencies land. That is where an access that does not arrive pushes everything downstream, with no amount of code able to help.

What we threw away

On this project three pieces of work were written and then replaced. Mentioning them is not misplaced modesty: it is the mechanism of the model, and the scrap rate is part of the quoted cost.

A first onboarding journey, designed from what the business described. Contact with the first users showed that two of its five steps had no reason to exist. Three days of work, replaced in one.
A full dashboard, of which three indicators out of eight were never opened. We removed them rather than maintain them.
An abstraction layer built to support several signature providers, when only one was retained. A textbook case of premature generalisation, and the only one of the three that could have been avoided.

Across the project this scrap amounts to roughly one week out of thirteen. That is the price of speed, and it stays far below the cost of spending months methodically building the wrong thing.

What the fixed price implies on our side

Quoting a firm price on a partly known scope means accepting three constraints, which it is fair to state.

We turn some projects down. When the request arrives as a frozen forty-page specification, the model does not apply and a traditional supplier will do better. We say so rather than take the engagement.

We price in the unexpected. A fixed price with no margin is a fixed price that gets renegotiated, which amounts to billing by the day with an added round of conflict. The margin is included from the start, and that is also why our price is not the lowest on the market.

We arbitrate continuously. At constant scope and fixed date, every addition means a removal. That trade-off happens at the weekly session, with the decision-maker, never at the end of the project.

What we do not promise

A product shipped in ninety days is not a finished product. It is a product in production, in use, whose next steps are decided on real usage rather than assumptions. The difference is considerable and rarely stated.

Nor do we promise the pace transfers to a project where a regulator, a banking partner or a legal department sets its own calendar. In those cases the constraint is no longer how fast software gets written, and claiming otherwise would be selling you a deadline we do not control.

Key points

A line of code is not a unit of value. What a code volume measures is the breadth of scope covered.
AI accelerates the first draft, unfamiliar APIs and repetitive work. It accelerates neither decisions, nor external dependencies, nor the quality of existing data.
The bottleneck moved from writing to deciding. What needs reorganising is the project, not just the tooling.
Scope is the adjustment variable, never the go-live date.
Three client-side conditions: one decision-maker available an hour a week, a narrow initial scope, and accepting that some early work gets thrown away.