A Rapid PoC in a Few Hours. What Did We Actually Build, and What Comes Next?

We took a spreadsheet containing the requirements for a moderately complex business application and gave it to three tools: Claude, OpenAI Codex, and Cursor used with Grok. We wanted to see how far each tool could get from the same description of a business process.

Our reference point was a system whose original development required approximately 1,000–1,500 person-hours. The first working version created with Claude was ready in about four hours.

That difference gets attention. It was not, however, the most important result of the experiment.

Four hours did not replace a complete project covering analysis, testing, integrations, security, deployment, and ongoing maintenance. They were enough to turn a written set of requirements into a working Rapid PoC: an application that could be launched, examined, and compared with the real business process.

This changes how a project can begin. It also raises a new question: if a first version can be created in a few hours, what have we actually built, and what do we still not know?

The same spreadsheet did not produce the same result

Each tool received requirements for the same application. The results differed not only in execution quality, but also in what the tools prioritised first.

Claude represented the process most accurately

In our evaluation, Claude captured the business rules described in the source material more completely than the other tools. Its first version needed visual refinement, but it responded well to subsequent instructions and preserved important elements of the process.

This was also the approach that produced a first working version in about four hours.

OpenAI Codex made the strongest first visual impression

Codex produced the most convincing interface at first glance. It also handled subsequent UI changes effectively.

Deeper evaluation, however, revealed omissions and simplifications in the application logic. On screen, the result looked more mature than the completeness of the implemented process suggested.

Cursor with Grok lost the largest part of the requirements

Cursor used with Grok also generated a first version quickly, but it omitted a significant part of the requirements. In this particular attempt, it produced the least complete representation of the process.

We did not test how the outcome would change if the work were divided into much smaller tasks and taken through more iterations. It would therefore be unreasonable to draw a general conclusion about the model or the tool from this result.

This was not a model ranking

We compared complete working environments, not isolated models under controlled laboratory conditions. The interface, available context, iteration process, execution tools, and usage limits all influenced the results.

We did not use an identical sequence of follow-up instructions or a complete shared set of acceptance tests. This was a practical experiment, not a benchmark.

It does, however, support a conclusion that is more useful than naming a winner: a single score cannot describe application quality.

The following dimensions should be assessed separately:

• completeness of the implemented requirements;
• correctness of the business rules;
• interface quality and usability;
• speed of subsequent changes;
• architecture and capacity for further development;
• testing required before deployment;
• security, integrations, and operational requirements.

A tool that performs best in one of these areas will not necessarily be the best in the others.

A working application can look more complete than it is

A Rapid PoC should show whether an idea can work and what the core process might look like. It does not yet prove that every rule has been understood correctly.

A missing button is easy to notice. It is harder to see that the system does not preserve a history of changes, interprets an exception differently, or relies on an assumption that will become dangerous when real data is introduced. Non-functional requirements are even less visible: access control, resilience, performance, auditability, backups, and the process for updating the system.

The more polished the interface is, the easier it becomes to assume that the underlying logic is equally complete. Our experiment showed that these qualities do not necessarily develop together.

A working PoC should therefore not be evaluated only by asking, “Can we complete the main flow?” Better questions include:

• Which requirements have actually been implemented?
• How will the system behave in edge cases?
• Which assumptions did the agent make without confirmation?
• What was simplified to demonstrate the core process quickly?
• What evidence will we need before we can trust the solution in production?

The agent knew the solution but did not identify the problem

The most interesting moment came during a discussion about the architecture.

The generated solution contained an issue that would affect the application’s further development. When a person raised it, the agent explained the problem correctly and proposed an appropriate approach. It had not, however, identified the issue on its own.

This is an important distinction. A model may have the knowledge required to solve a problem without recognising that the problem is present in a particular project.

The same applies to business requirements. An agent may know how to model data history, permissions, or a multi-stage approval process. If the source material does not describe them precisely enough, the system may produce a credible-looking version without asking the question that an experienced analyst or architect would raise.

Faster code generation therefore does not make specialist knowledge less important. It moves that knowledge to a different part of the process. Increasingly, the valuable skills are the ability to:

• select the right part of the process for prototyping;
• ask questions that reveal hidden rules and exceptions;
• recognise architectural shortcuts;
• test the result against representative scenarios;
• distinguish an impressive demo from a foundation for a production system.

A Rapid PoC changes the requirements conversation

Traditionally, much of the early work on custom software takes place through documents, diagrams, and meetings. The team tries to describe the future system precisely enough to estimate and build it.

If a working prototype can be prepared in a few days, and sometimes in a few hours, it becomes an additional discovery tool. Instead of discussing only a description of the future solution, the client and the technical team can respond to something that already works.

Feedback then becomes more specific:

• “This stage works differently in practice.”
• “We need an additional approval here.”
• “This information must remain available after the data changes.”
• “This user should not be able to see the entire record.”
• “It looks good, but the most important exception is missing.”

A Rapid PoC does not remove the need for analysis. It allows part of that analysis to take place against a working solution, revealing differences between a process description and operational reality sooner.

We explore this role of a PoC in more detail in Your AI Demo Works. Now What? From Rapid PoC to Production.

What can be built in a few hours?

In a few hours, a version may be created that is sufficient to:

• demonstrate the main process flow;
• verify whether both sides understand the requirements in the same way;
• compare interface and workflow alternatives;
• test the feasibility of a critical function;
• uncover missing rules and questions;
• support a better decision about further investment.

This does not automatically mean the system is ready to handle real users and data. The path to production may still require redesigning the data model, adding integrations and access controls, introducing regression testing and error handling, setting up monitoring, preparing documentation, and defining how the system will be maintained.

The PoC code may become the foundation for the final solution. It may also be partially or completely replaced. The value of a Rapid PoC is not a promise that every generated line of code will reach production. Its value is the knowledge gained earlier and at a lower cost than in a traditional, lengthy delivery cycle.

What this changes for the client

Faster prototyping makes it possible to test an idea earlier and reduce the risk of investing in a misunderstood solution. At the same time, the time required to create the first version is becoming a weaker measure of proposal quality.

When evaluating a technology partner, it is therefore worth asking not only how quickly they can demonstrate an application, but also:

• how they will check the completeness of the process;
• who is responsible for architectural decisions;
• how the acceptance criteria will be defined;
• which parts of the prototype must be rebuilt before production;
• how security and integration requirements will be addressed;
• who will maintain the system after launch.

The first version may be fast and inexpensive. The cost of an unnoticed error in a business process can still be high.

From a fast first version to a responsible system

At Inero, we treat a Rapid PoC as the beginning of a structured delivery path, not as a shortcut around engineering.

First, we select the problem, data, and part of the process whose validation will provide the most useful knowledge. We then build a working version, gather feedback, and identify the gaps. Only then do we define the work required for production: architecture, integrations, security, testing, and the approach to ongoing maintenance.

This approach separates three types of work:

1. Rapid PoC and discovery — validating the idea, process, and critical assumptions.
2. Production engineering — architecture, integrations, acceptance criteria, security, and testing.
3. Maintenance and development — monitoring, updates, error handling, and further changes.

AI can significantly accelerate each of these stages. It does not make them the same task.

Code is created faster. Responsibility does not disappear

Our experiment did not provide a definitive answer to which tool is best. It demonstrated something more useful: different tools can quickly generate convincing but different interpretations of the same requirements.

The advantage therefore does not come from model selection alone. It comes from combining domain knowledge, technical experience, effective direction of AI agents, and systematic verification of their work.

We can see a first working version sooner than ever. What matters increasingly is who can identify what is missing, take it to production, and accept responsibility for how it continues to operate.