Four days to a production ERP: staying the customer

A new project used to mean a new stack, and a new stack used to mean downtime — the IDE, the host, the database — before anyone wrote a line of the product. In this cycle Grok Build was the IDE, the design desk, and the database console. Implementation went to the agent. We stayed the customer. The ERP was ready for production, with the migration complete and checked, in four days. This article explains what that split of labor was, what the four days contained, and what the result is not.

Purpose and prerequisites

The purpose of this article is to describe a delivery cycle in which the owner remained the customer and an agent performed the implementation on a new stack. Enterprise software has always moved. Languages change, release methods change, and the box in the closet becomes a region in Azure. Every few years a new project is the occasion to pick a stack that will still be relevant when the system has to live for a decade. That choice was never free. It purchased a modern solution, and it billed a hidden week, sometimes more, of becoming comfortable before the work the business actually paid for could start. The remainder of this article is about the removal of that hidden week, not about a claim that judgment can be automated.

Someone used to have to absorb the particulars: how the latest IDE wants a person to move, how the host is wired, how this generation of database wants money and identity to be modeled. Only then could that person architect the right shape, design the code the team would live in, and start making it happen. That ramp was treated as a cost of doing the job. It was also the part of the job that never appeared on a customer invoice as “learning Blazor.” The cycle described here still required an owner who knew the business. It did not require that owner to become fluent in the screwdriver before the house could be discussed.

What was different in this cycle

The last cycle did not skip the new stack. It skipped the downtime. Grok Build sat in the repository as the environment: editor, design desk, database console, test runner, and deploy loop. We decided where the system would run, granted the permissions it needed, and used the chat the way a customer uses a kickoff: here is the requirement, here is what “done” means, proceed. We did not have to become fluent in the particulars before the product existed. The agent already was. We did not translate the business into tickets so a team could start. The chat was the ticket. A written customer request would have been enough; typing it in the box was optional ceremony. That split of labor is different from AI autocomplete in an IDE the team already knew. Autocomplete still assumes a person who has already chosen the files. This cycle was closer to hiring a very fast implementer who already knew the tools, and keeping the only role that cannot be hired: the customer who knows what the firm actually does.

The customer stays the customer

For more than thirty years of shipping enterprise software, the person who knew the business also had to be the person who knew the stack well enough to steer it. That double job is why new-stack projects felt expensive even when the license cost was small. The firm was paying senior time to re-learn the screwdriver so the house could be built. In this cycle the owner stayed the owner. Requirements, permissions, a posting rule that is wrong, and a migration that is not done until balances match are customer work. File layout, schema, Razor, pipelines, and the ordinary path from a sentence to a running screen are implementation. Offloading implementation does not offload judgment. It stops charging judgment for the privilege of typing. If nobody can say what cash-basis means in the firm, the result will not be books; the result will be a tutorial. The agent will not save a vague customer. The agent will save the week that used to be spent before the customer was even allowed to talk.

Four days, with the migration actually done

The result was a new ERP for this company: purpose-built books, not a stretched package, ready to go into production. The migration from the old file was complete. The numbers were checked. Four days is not a slogan for a demonstration on Friday. Four days is calendar time from the statement of the system we need to the statement that we can run the business on it. Those four days contained architecture that matched how we sell, a working application, data moved, and validation that the moved data was the business rather than a pretty empty schema. They did not contain a week of IDE tutorials, a separate spike to learn the host, or a design phase whose only output was a deck. Those used to be the first invoice a new stack sent to the calendar. They still required an owner who would say no. Production-ready means the owner looked. It does not mean the agent was sure of itself. The product shape of that ERP is a different article. Readers who want the books, the portal, and the conditions under which we would build the same class of system for a customer should start with the purpose-built books piece. This page is about the delivery, not the chart of accounts.

Cost, including the subscription

Grok SuperGrok Heavy is not a free tool. It is still cheaper than the way we used to do this work. The old bill was senior hours spent consuming a stack, then more senior hours implementing, then the calendar delay while that happened. The new bill is a subscription plus the owner’s time in the chat — requirements, permissions, review — and four days of elapsed time instead of a project plan that assumed ramp-up. Cost-effective does not mean that the model is inexpensive. Cost-effective means the expensive person is no longer doing intern work in a new IDE. If the firm already had a team that knew the stack cold, the savings would be smaller. Most small firms do not have that team sitting idle. They have an owner, a deadline, and a package that will not bend. The subscription is justified when it buys that reallocation of senior time, not when it is treated as a cheaper developer.

The story that holds up is not that AI built an ERP. The story is that the customer was allowed to remain the customer. Implementation is what we used to spend the first week failing to start because the stack was new. That week is gone. The review is not.

What this cycle is not

Several interpretations of this cycle are adjacent and still wrong. The cycle is not a substitute for an owner; if nobody can tell whether the migration is right, four days will produce a confident wrong system. The cycle is not a reason to fire developers; it is a different use of the people who understand the business, who spend their time on rules, exceptions, and whether a posting matches how the firm actually gets paid. The cycle is not the same as Copilot in the editor the team already lives in; completions make a known stack faster and do not remove the need to know the stack. The comparison of those tools is in Using AI in software development. The cycle is not a reason to skip git, tests, or a human diff. Fast implementers still produce diffs. Someone who can read them still has to. Those limits are part of the delivery, not footnotes to it.

When software should be built this way

A customer who wants this split of labor should bring the requirement, not a technology preference, say where the system has to run, and be available to answer whether a rule is the rule the same day, the way a real customer would. That customer should expect to review the result as an operator, not as a person who just learned the framework. We will say if a package already does the job. We will say if the thing wanted is a four-day build or a six-month one. We will not pretend a chat box removes the need for someone who knows the business. It removes the need for that person to also be the one who just installed the new IDE. Organizations that want that split may talk with us. Organizations that want the books example rather than the delivery story should start with the purpose-built application.