A $70-a-month production app replaced a $5,000-a-month platform: What production-grade AI coding looks like

The number that stopped me was $70.

Fran Muñoz had just told me that minimal, the application he built to run core delivery operations at Zyte, now costs about $70 per month in Google Cloud infrastructure. I asked him to repeat it. The platform it replaced had cost roughly $5,000 per month.

By then, minimal had grown to support project portfolios, revenue forecasting and recognition, renewals, churn, infrastructure costs, dashboards, and a collection of smaller workflows that used to live in spreadsheets. Fran estimated that its test suite contained approximately 3,600 tests. He could have an idea, build it in an hour, and deploy it five minutes later, sometimes several times in the same day.

Fran is Zyte's head of data delivery engineering. He trained as a computer science engineer, but he had spent nearly 30 years in management rather than day-to-day software development. Minimal began in late October 2025 as a personal experiment with an AI coding agent. Nine months later, people were using it to do real work.

When we sat down, I wanted to understand more than what Fran had built and which tools he had used. What had changed inside him when he realized he could build production software again?

To reach that question, we began with the name.

Why it was called ‘minimal’

What had the previous platform held together for Zyte, and where did its limitations appear in the team's everyday work?

Before minimal, Zyte used a wide professional services automation platform to manage delivery. Fran estimated that the team relied on perhaps 20% of what it offered, primarily two functions.

The first was project portfolio management. Work created through sales had to move into delivery, where teams needed a clear view of customers, projects, and their progress. The second was revenue management: forecasting what each project would generate, then recognizing the appropriate revenue as the work advanced.

Those two requirements defined the first version. Minimal was supposed to provide the smallest system that could handle them without carrying the cost and complexity of everything around them.

This was familiar territory for Fran. It was not the first time he had built a tool to support his own delivery work, and he knew the questions the system would eventually be asked. He prefers anticipation to improvisation. By the time someone asks for a particular delivery number or view, he wants the answer to exist already.

The next question was how much of this Fran had seen in advance. Did minimal begin with a complete blueprint, or did the system reveal itself one useful feature at a time?

"I didn't have a full plan," Fran told me. "I find it more convenient to know what the core features are, then keep adding features that you see would be useful."

The experiment grew from the spreadsheets around it

Within a few days, Fran could see that the agent understood the functional logic he was describing. Adding a useful feature often took hours rather than weeks, so he began looking at the work that still sat outside the main system.

There were spreadsheets for churn, renewals, and infrastructure costs. Those moved into minimal. He added dashboards for bookings, revenue, and project progress, along with automations for tasks that had previously been handled manually. One created placeholder identifiers when sales opportunities reached the appropriate stage. Another projected future renewals so the team could see expected revenue beyond the current engagement.

Minimal stopped being minimal in the ordinary sense of the word. Its name still described the way it grew: a small core first, followed by features pulled from work people were already doing.

Fran said he would build it the same way again. Starting with a minimum viable product made the next requirement easier to see, while the application itself tested whether the underlying design could support it. Each spreadsheet that disappeared was evidence that the system had found another part of its real boundary.

The features multiplied, but Fran did not follow them into the code.

Fran let the agent touch the code

I had seen people give an agent a prompt, add feature after feature, and end up with a mess they could no longer navigate. What separated that kind of AI-generated codebase from a production system people could safely depend on?

"I don't have a sentimental link with the code," he said.

Fran had not manually changed an application setting or added an API key himself. He asked the agent to handle those details, including work that many developers would instinctively take back when a project became complicated.

That distance from the code left him watching something else. Was the application behaving consistently? Did a new feature follow earlier architectural decisions? Could the agent remember how it had solved the same kind of problem before?

In the beginning, it often could not. Fran found himself repeating instructions and correcting inconsistencies as the codebase grew. His response was not to write longer prompts. He asked the agent how they could stop forgetting decisions they had already made.

They began recording architectural rules and recurring patterns in Markdown files. Later, when Fran encountered specification-driven development, the practice gave those documents a more deliberate role. Instead of asking the agent to build a feature from a prompt, he used the conversation to create a specification, then asked the agent to implement that specification through an established workflow.

Javier described a similar approach in our conversation about the moment AI started to feel like a superpower. His documents carried the decisions from one session to the next, even when the model or chat changed. In both cases, the written specification did more than help the agent remember. It kept a record of what the human had decided.

The moment minimal became a system

Specifications brought consistency, but testing changed what Fran was willing to do with it.

Tests became part of the standard implementation workflow. When the agent built or changed a feature, it also had to create the checks that would catch a regression. By July 2026, Fran estimated that minimal had approximately 3,600 tests.

Early versions had produced occasional application errors. When we spoke, Fran could not remember seeing one in the previous four months, and he said a feature change had not broken another part of the application in five or six months. That record gave him the confidence to work in continuous deployment: an idea could become a feature in an hour and reach production minutes later.

The test count is the visible part. Underneath it is a change in the relationship between Fran and the agent. He did not need to trust that the model would always make the right change. He needed a workflow capable of revealing when it had not.

That is also the difference between a successful AI demonstration and evaluated software. As we found when looking at why AI skills need to be treated like software, a result that works once tells you very little about what will happen after the inputs, implementation, or model changes. A repeatable evaluation loop gives the system a way to challenge its own apparent success.

Minimal had acquired that loop. The specification narrowed the task. Architectural rules constrained the implementation. Tests confronted the result.

His agent skills remember the process

Once a process proved useful, Fran turned it into an agent skill.

That made me ask: when does a repeated task deserve to become a skill, and how do you keep the skill improving after you create it?

By the time of our conversation, he had created around 10 of them. Their names were ordinary because their jobs were ordinary: create a specification, build from a specification, fix an issue, refactor, review database indexes, and optimize the database. Most were process-oriented rather than tied to a narrow technical trick.

The refactoring skill began when Fran noticed that he had asked for the same kind of work several times. He asked the agent to capture the method so future refactoring would happen consistently. When he later noticed a missing step, he added it to the skill.

This is less like downloading an ability and more like preserving a routine. The skill holds what should happen every time, while the specification holds what this particular change needs to accomplish.

It also explains why more instruction is not automatically better. Konstantin Lopukhin made that case when we discussed why the best agent skill may be the one that says the least. Useful guidance gives an agent the right knowledge, constraints, tools, and standard of quality. It does not need to dictate every local decision, especially when the model may see a simpler path.

Fran's skills grew from repetition. They were small pieces of operating memory built after the work exposed a need for them.

Production started at $10 a month

Long before minimal was ready to replace anything, Fran knew it needed somewhere real to run.

He had never personally deployed an application to Google Cloud before, but production infrastructure was not an afterthought he could postpone until the code looked finished. He asked the agent to help choose the services and initial sizing, then began with the smallest setup that appeared sufficient. It cost about $10 per month.

As minimal accumulated features, Fran ran load and stress tests and increased the capacity a couple of times. He added memory and CPU alerts that would tell him if the current setup was becoming constrained. The monthly infrastructure cost eventually reached about $70, where it remained when we spoke.

His rule was to start small, observe the system, and increase capacity when the evidence required it. The same rule ran through the rest of the project: build the necessary core, watch what happens in use, then add what the system proves it needs.

Fran was careful with the comparison to the roughly $5,000-per-month platform. Minimal also consumes some of his time, and internal ownership moves responsibility rather than making it disappear. Now that the application is stable and most of its required features exist, that attention has become small, but it remains part of the cost.

The $70 bill is striking because of everything it does not show: the requirements, architectural decisions, tests, alerts, maintenance, and judgment that allow a small infrastructure footprint to carry important work.

What the agent could not supply

By this point, I could see a possible thesis for what Fran had built. Was minimal really a story about AI coding, or about what happens when domain knowledge, systems thinking, AI leverage, and human judgment meet?

I offered those ideas to Fran. He refined them into three things: domain knowledge, systems thinking, and AI leverage.

Domain knowledge meant he did not need to begin by extracting the delivery and finance logic from someone else. He knew how projects moved from sales into delivery, how recurring engagements affected forecasting, what happened at month-end, which questions leaders would ask, and which spreadsheets exposed holes in the main system.

Systems thinking connected those requirements to everything around the interface. The application needed a database, infrastructure, external services, alerts, cost controls, architectural patterns, and a maintenance process. Fran had been away from hands-on development, but he still had what he calls technical instinct: a sense of the pieces a production system could not do without.

AI leverage collapsed the distance between that understanding and an implementation. Fran began with GitHub Copilot using a Claude Sonnet model, then moved to Claude Code as its memory and workflow support became a better fit for the way he worked.

The tools changed while the operating method survived. It lived in the specifications, architectural rules, tests, and skills rather than inside one model or chat history.

Can technical instinct be taught?

The question I could not let go was whether the judgment behind minimal could be passed on. If technical instinct can be taught, what would it take to move someone from a first conversation with an agent to deploying something production-ready?

Fran is now helping colleagues learn to build applications with an agent, but he does not begin by letting them change minimal. He starts with another application so they can see the decisions that a finished system tends to hide.

The first question is simple: what do you want to build? From there, the learner asks the agent which framework suits the application, decides where it should run, establishes the specification workflow, and works through architecture, infrastructure, and deployment with a human mentor beside them.

Fran estimates that moving someone from no application-building experience to deploying a production-ready tool would take at least 10 sessions of one to two hours. He does not claim that those sessions can reproduce decades of judgment. They can make the thought process visible long enough for someone else to begin practicing it.

When I asked him for a systems-thinking book, he offered a different resource.

"Find a good peer who can guide you through the way."

The answer stayed with me because Fran had spent the previous hour describing everything an AI agent had helped him do. It had selected infrastructure, written code, created tests, changed settings, and turned repeated routines into reusable skills. When the question became how a person learns to see a system, he recommended another person.

AI did not erase the years before it

Fran began this experiment with some of the anxiety many people bring to AI. Could these tools eventually take people's jobs?

Building minimal moved him in the opposite direction.

"I see that it is really something that makes you much more powerful as a developer, an engineer, an architect, or whatever," he said.

He did not need the largest model available, and he never found the perfect prompt that built the application in one attempt. Minimal emerged from a person who could recognize the problem, describe the work, anticipate the questions, preserve decisions, and notice what a production system was still missing.

The agent wrote the code. The years before it are what made the code useful.