No. 11 · Technical

AI Factory Case Study: From Five Months to Four Days

A by-the-numbers analysis of what the AI Factory produces six months in.

The first is the Remote Area Heating Allowance application, originally coded by hand in Java twenty-five years ago, which took five months to write and was rebuilt in four days using the factory. The second is the Alberta Classroom Information Portal (ACIP), the first enterprise-grade AI application released publicly by the Government of Alberta, delivered in eleven weeks for approximately $108,000 against a traditional delivery estimate of $1.3 million to $1.9 million.


## §01 What vendors were not telling us

(Note: this narrative is from Chris Wright, who by day is the Director of Integration Services, but who joined the AI Factory team to support Project Pronghorn in January 2026, just five months ago.)

Before joining the Pronghorn program, I was managing a team to support technical debt remediation and system integrations. In many of my conversations with vendors, I heard a consistent narrative with respect to addressing and remediating our legacy applications: AI has significant limitations for this kind of work.

I was skeptical of that position, but I did not have any evidence to test or contradict their positions. I had not used these tools at depth myself. I could not push back with anything concrete. And to be fair to the vendors: what we are capable of doing now would not have been achievable twelve months ago. The models were not there. The technology moved faster than most organizations, including our vendor partners, could track. Alberta was investing heavily into our staff through the AI Academy and building capabilities and solutions in house rather than waiting for the market, which gave us a first mover advantage.

That was part of why I signed on to Project Pronghorn which became the overarching AI Factory model. I wanted to find out firsthand what was possible. The Alberta AI Academy added to that foundation. Between the two, my understanding of what AI can actually do shifted substantially, and with it my ability to have a different kind of conversation with the vendors we work with.

The gap between what vendors described as the limits of AI and what the tools actually produced in practice turned out to be significant. The two applications described in this paper are evidence of that gap.


## §02 The Remote Area Heating Allowance application

Twenty-five years ago, I wrote the Remote Area Heating Allowance application for Alberta Agriculture. I coded it myself in Java. The application handles a subsidy program for Albertans who live so far from the natural gas network that they heat their homes with oil or propane. At the time, people in those locations were not expected to have internet access, so the application was built as an internal portal only. Staff in Agriculture receive mailed documentation from applicants, enter it into the system, and issue a cheque.

That application, with security patches applied over the years, is still running today. It has not been replaced. It is a straightforward example of the technical debt that exists across the government estate: functional systems, written in an older era, maintained but not modernized.

During the Pronghorn program, this application came up as one of the examples to work through. I recognized it immediately. I know exactly what it does, what it is supposed to produce, and how long it took to build the first time. I put it through the factory. The rebuild took four days, and the new version includes a public-facing online portal that the original never had, along with additional features, including a direct document submission option that replaces the mail-in process.

Delivery time 5 mo → 4 days. The Remote Area Heating Allowance application took five months to build by hand in the early 2000s. The same application, rebuilt with added public-facing functionality through the AI factory, took four days.

"Five months the first time, four days the second time, and the rebuilt version does more than the original." · Chris Wright, Technology and Innovation

The Remote Area Heating Allowance rebuild was a prototype. Its value is as a proof of capability. Because I wrote the original code, I could evaluate the output with direct knowledge of what it was supposed to do. The quality held up. The speed of delivery was a different order of magnitude.


## §03 What changed for me

When I started on this work, my understanding of AI was limited to what most people experience: a chat interface that can help with a document. That is a useful tool.

What I can do now is evaluate what AI is genuinely capable of and where it has real limits. I can challenge vendor claims with specific knowledge rather than suspicion. I can look at a complex application estate and see a concrete delivery path rather than a wall of accumulated work. That shift took time and it took hands-on practice, but the direction of it is one way. I do not think there is a role in this department whose work should not change because of this technology.


## §04 The Alberta Classroom Information Portal

(Note: the remainder of the text is written by Chris Wright and Sheldon Bauld, with support from Michelle Dias.)

ACIP is a new application, built from scratch using factory methods, and it went live on June 1st, 2026. Built for principals and teachers across Alberta, it required the full complement of enterprise controls: privacy protections, security review, identity management, and production infrastructure.

Prior to ACIP, Alberta had released AI-assisted utilities to the public, but nothing that required the full governance, security, and privacy protections of an enterprise application. ACIP is the first. It is not a tool someone could afford to get wrong, and it was delivered to the same standard as any application that would have come out of a traditional product team.

The difference is in the time and cost. A traditional product team would have taken approximately a year to a year and a half to deliver an application of this complexity. ACIP was delivered in eleven weeks. The cost of the factory build came to approximately $108,000. The equivalent traditional delivery would have cost between $1.3 million and $1.9 million.

ACIP: factory delivery vs traditional $108K vs $1.9M. The Alberta Classroom Information Portal was delivered in eleven weeks using factory methods at a cost of approximately $108,000. Traditional delivery of an equivalent application would have cost between $1.3 million and $1.9 million and taken up to eighteen months.


## §05 What the factory investment actually means

The work that went into building the factory was substantial. More effort went into creating the factory than into getting the first applications out the other end. That front-loaded investment is easy to question until you see what it produces.

The factory is now reliable. The harness, the agents, the pipeline, the standards are stable enough that small, lean teams can run multiple applications in parallel. The infrastructure is reusable and re-deployable. The foundational work does not need to be repeated for each application, which is where the taxpayer savings compound. Quality controls are built in. The refactoring required in the early builds has been done. The factory has been built and tested around case management, the pattern that underlies the majority of government services. Nearly every program the government runs involves the same two-sided problem: a citizen submits information to create or update a record, and staff process that record through a defined lifecycle. Benefits, enforcement, licensing, and grants are all variations on this. Building the factory around that pattern means the efficiency gains extend to the full backlog of government services that share the same structure, not just the applications already delivered.

Each application that comes through now benefits from every previous build. The patterns are established. The common problems have been solved. What used to require constant adjustment now runs consistently. That is the point of a factory: the investment in the line pays back across everything it produces.

The factory is also set up so that anyone can run it. New people can drop in and start delivering applications within a day or two. The work is instructional and well-documented. You are not dependent on any one person being available, and you are not starting from zero when someone new joins. That kind of staffing flexibility matters in government, where continuity cannot be assumed and institutional knowledge tends to walk out the door. This is a large part of why the work to build the factory matters as much as any single application it produces. The documentation, the standards, and the institutional knowledge are captured in the line itself rather than held in any one person's head, so when someone moves to another department or builds a career outside government, the capability stays with us. The aim is to grow the strongest people we can while keeping the knowledge that runs our systems firmly in our own hands, so that we remain in control of what we build.

"There was more work put into creating the factory than into getting the apps out the other end. But now you can take fewer people and pump out multiple apps." · Chris Wright, Technology and Innovation


## §06 The scale of the problem and what this means for it

The Government of Alberta has an enormous backlog of applications that need to be rewritten, modernized, or replaced. Addressing that backlog through traditional delivery would take decades and cost billions of dollars. That path leads nowhere useful.

The factory changes that calculation. Applications that would take a traditional development team a year can be delivered in weeks. The cost differential between factory delivery and traditional delivery, demonstrated in ACIP, runs to an order of magnitude. Across a full government estate, that adds up.

If this approach were extended across the federal and provincial governments in Canada, the savings would run to tens of billions of dollars. The number is an extrapolation from costs already demonstrated in production.


## §07 What this investment actually means

Alberta made a bet. The decision to invest in building this capability in-house, rather than waiting for the vendor market to deliver it, was not a safe or obvious call. Most governments have not made it. The math on that decision is now visible: the cost savings are real, the numbers check out, and the applications are running in production as a demonstrated delivery model.

Traditional product teams run five to nine people, most commonly around seven. For larger portfolios, you might have four or five of those teams working in parallel, with headcount and budget climbing quickly. AI factory delivery changes that ratio entirely. The same small team currently running Pronghorn is delivering five applications in parallel.

The efficiency gains are not coming at the expense of the output. The standards built into the factory produce results that meet the same bar as traditional delivery, at well under a tenth of the cost.

Government technology delivery has gone through three eras. Large vendor contracts, the kind that cost tens of millions of dollars, ran for years, and often returned little, gave way to product teams. Product teams cut time and cost roughly in half and were a genuine improvement. AI factory delivery makes a larger jump than that. The efficiency gain is a different order of magnitude, and the arc is familiar: each era looked like the ceiling until the next one arrived.

"The best is yet to come. Right now we mostly see the problems, the things that still need fixing. By end of August, Pronghorn will have launched four more applications. That is the same lean team, five apps in two or three months. In a government context, these speeds are rarely achieved." · Sheldon Bauld, Technology and Innovation

Tags: factory, delivery, applications, technical-debt, modernization

Open the interactive version