A Working App Is Not a Production-Ready App

One of the most confusing things about AI-generated software is how convincing the first result can be.

You describe an application, wait for a while, and receive something that opens in a browser. The buttons work. Data appears. A form submits. During a demonstration, it may look complete.

That is an impressive technical achievement.

It is not evidence that the application is ready for production.

I learned this while building InvoShift. Its main functionality appeared quickly, but everything required to operate it responsibly came afterward: quality checks, security review, deployment automation, monitoring, backups, and customer support.

The application was the visible part. Most of the work needed to trust it was not visible at all.

"Working" needs a definition

When I say a feature should work without bugs, I do not mean that anyone can prove software will never contain a defect.

I mean that every promised feature must behave as promised.

If the product includes an invoice generator, it must generate invoices according to the agreed behavior. If it includes a time tracker, it must track time correctly. The promise is the definition of expected behavior.

This sounds simple, but many software projects begin before the promise is clear.

Business owners often know the outcome they want without having a complete view of the application. They may describe the central idea while expecting missing workflows and details to be guessed by the technical team.

AI makes this misunderstanding easier. A request can sound precise in conversation while leaving dozens of unanswered questions. "Build a green and white website that does a backflip" may be understandable as a sentence, but it is not yet an implementable specification.

ARAG's responsibility is to identify incomplete areas, ask the client to decide what matters, and offer reasonable completions where useful. The client remains responsible for business decisions. The technical team is responsible for making the unanswered questions visible before they become expensive surprises.

Design is part of the agreement

This is also why I do not see design as decoration added after requirements.

Before development begins, ARAG plans to provide three Figma design directions. The selected design should show page structure, element arrangement, visual hierarchy, and important interactions.

This avoids a familiar type of disagreement:

"The menu contains everything we discussed, but I wanted it on the other side."

"The red is technically correct, but it is not the red I imagined."

"The feature works, but I thought the page would shine when I clicked it."

Written requirements alone cannot communicate every visual expectation. A design gives both sides something concrete to approve.

It also protects both sides. The client can see the intended result before paying for implementation. ARAG can distinguish between a defect, where the delivered result contradicts the agreement, and a new request, where the client wants to change the approved result.

A demonstration is allowed to be incomplete

A demonstration has a different purpose from a production application.

It may exist to prove that one workflow is possible. Features outside that workflow may be missing or unstable. It may not yet include complete monitoring, backups, security checks, or failure handling.

That can be acceptable if everyone understands what is being demonstrated.

A production application has a different standard. Before I am willing to put my name behind it, the agreed features must work, critical findings must be resolved, automated checks must pass, and expected failure scenarios must be considered.

The surrounding operational system must exist too.

That includes:

• controlled source code and releases
• automated quality and security checks
• repeatable deployment
• monitoring and alerting
• backups and a way to restore them
• failure handling
• maintenance and incident response
• customer support

None of this is especially exciting during a product demonstration. It becomes very important when the product holds real customer data or supports a real business process.

The hidden work behind fast delivery

Fast implementation does not remove the work. It changes where the work happens.

Behind an AI-built application are often hours of discussion and requirement clarification. Prompts need to be prepared and refined. Generated changes need to be reviewed. Sometimes a coding agent works for twenty minutes and produces nothing useful. Sometimes it fixes one issue and introduces several others.

Integrations that are well understood in traditional development can still require repeated corrections. A GitHub Actions workflow may fail several times before the first successful deployment. A security tool may reveal a pattern that appears throughout the generated code. A feature that works once may fail with invalid input or an unavailable external service.

The client should not need to manage that process.

This is the difference between selling access to an AI coding tool and providing a software delivery service.

Going live is not the end

Production responsibility continues after deployment.

At minimum, an operated application needs monitoring, backups, maintenance, incident response, and customer support. New features remain separate work because they change the agreed scope. Defects created by ARAG should be covered by a defined warranty, although the exact commercial terms still need to be finalized before they become a public promise.

The important principle is accountability.

If an agency builds an application, deploys it, and disappears, the client has received code but may not have received a dependable system.

My background is not primarily in writing application code. It is in keeping systems available, secure, recoverable, and understandable to the people operating them. That experience shapes how I think about software built with AI.

AI can make implementation much faster. It does not remove the need for engineering discipline, operational experience, or honest conversations about what has actually been promised.

What ARAG is trying to provide

The phrase I initially used was "corporate-grade workflow for small and medium businesses."

A clearer way to say it is this: ARAG brings practices commonly found in larger engineering organizations to businesses that may not have their own development, security, infrastructure, and operations teams.

The client gets one relationship, but the application still passes through structured design, implementation, testing, security checks, deployment, monitoring, backups, and support.

I do not want a potential client to believe ARAG will promise everything.

I want them to believe that ARAG will be honest about what can be delivered, define it clearly, and then deliver everything that was promised.

That is a more meaningful standard than simply saying an app works.