What happens when the prototype looks right, but the plant logic is wrong?

That’s one of the bigger risks in manufacturing software. A prototype can behave exactly as requested and still be unsafe or operationally incorrect because the original requirement omitted a rule that everyone on the plant floor takes for granted.nWe treat those discoveries as more than user feedback. They become explicit business rules, acceptance criteria, and tests. The prototype is there to expose assumptions. Production code should not depend on those assumptions staying in someone’s head.

Do you need write access to our production systems to start?

Usually, no.nIn a brownfield environment, it often makes more sense to separate the read path from the write path. A new scheduling module, for example, can read current jobs and generate a proposed queue without having permission to change the production state.nThat gives planners and engineers a chance to compare the software’s recommendation with what is actually happening on the line. Write access comes later, after the rules, permissions, failure behavior, and rollback path have been validated.

How do you avoid rewriting parts of our MES that already work?

We first look for the smallest layer that actually needs to change.nIf the MES integration and data contract are sound, there is little value in replacing them just because we are building a new feature. If the issue is the scheduling logic, we change it. If operators only need a better way to interact with an existing workflow, the backend may not need to change at all.

Our system has years of undocumented behavior. How do you work with that?

We assume the codebase will tell us only part of the story.nWhat the code often does not explain is why certain behavior must never change.nThose rules have to be made explicit. A statement such as “a job with an active quality hold cannot be reprioritized for production” belongs in the specification and, where possible, in an automated test. That way the rule survives the next developer, the next refactor, and the next AI-generated implementation.

Where does AI actually save time, and where do you deliberately keep engineers in control?

AI is useful for parts of the implementation that are expensive but not particularly unique.nIt is much less useful at deciding what the plant is actually allowed to do.nAn AI coding agent does not inherently know that a PLC state represents a maintenance lock, that a material substitution is valid only for certain product families, or that moving one job forward in welding may starve a downstream assembly process.nThat context still belongs to engineers and production experts. We use AI to shorten the path from a clear technical intent to working software. We do not treat it as the source of the intent.

What has to happen before you consider a change ready for production?

Before cutover, the rules discovered during prototyping should be reflected in the specification and, where practical, enforced through automated tests. The delivery pipeline should check application logic, integrations, critical regressions, and dependencies.nThen there is a category of validation that automation cannot fully replace. Someone who understands the production process has to verify the change in an environment that is close enough to production to expose operational problems.nRAD should be fast during discovery and construction. Cutover is where being deliberately boring is a feature.

How do you know a software improvement did not simply move the problem somewhere else?

We do not limit ourselves to evaluating only whether a function works.nAccelerating schedulers’ work is useful in itself, but it does not provide the overall picture of the production system’s performance.nThe last step in the RAD loop is learning from what happened after deployment. Did planners respond faster? Did queue behavior improve? Did downstream delays increase? Did operators start working around the new feature?nIn manufacturing, a locally successful software change can still be a globally bad production change. The physical process gets the final vote.

How do you work with our engineering team without creating a second engineering organization beside it?

Plant engineers know why a process works the way it does. An external team brings additional engineering capacity and implementation experience. Neither side is a substitute for the other.nThe model works best when ownership stays clear rather than being quietly transferred to the vendor.

If we want to test Devox on one project first, what should we start with?

Pick something important enough to matter, but bounded enough that you can evaluate the result.nGood first candidates are usually software layers where requirements change frequently, and users can give useful feedback quickly: an operator workflow, a quality module, a planning interface, a dashboard, or a targeted MES extension.nA first project is less attractive when the core problem sits inside safety-critical PLC or DCS control logic. Those systems follow a different validation cycle.nThe goal of the first engagement should not be to prove that someone can build a prototype. That is increasingly easy. It should show whether the team can understand your existing environment, uncover rules missing from the initial request, integrate without unnecessary disruption, and safely move a useful change into production.

Rapid Application Development in Manufacturing

Table of content

TL;DR

RAPID application development (RAD) enables manufacturers to deliver working software prototypes within weeks. By prioritizing iterative feedback from shop-floor users and testing with real data, teams minimize wasted development time. Instead of waiting multiple quarters for a finished system, teams can ship validated improvements continuously and solve real operational problems sooner.

RAD Is Back

This time, thanks to AI. In 1982, computer scientist James Martin published a book with a title that sounds almost prophetic today: Application Development Without Programmers. Nine years later, he formalized Rapid Application Development (RAD), an approach built around fast prototyping, short cycles, and continuous user feedback. RAD emerged as an alternative to projects where teams spent months specifying a system before users saw a working screen. Its core idea was simpler: people often understand what they actually need when they can see a system in action. Back then, technology limited this approach. Code generators could speed up simple applications but quickly hit complexity limits. AI coding agents have changed that. Today, teams can have a working prototype in hours, sometimes sooner. That matters in manufacturing: planners can test new queue logic, shop-floor managers can try a new workflow, and engineers can see how the system behaves with real production data before full development begins. However, speed introduces another problem. An application might look correct while violating an unstated rule. Modern RAD in manufacturing has two sides: build working software quickly, then verify exactly what it is allowed to do.

Four Phases of RAD: Quality Inspection Module Example

This example follows the creation of a quality-inspection module.

Requirements planning: The engineering team holds a one-week requirements workshop with quality inspectors. They define the core issue: manual inspection logging causes data silos and delayed feedback.
User design: In week two, developers create a functional prototype. This version allows inspectors to enter data on a mobile device and see the system state change in real time.
Structured user feedback: During week three, inspectors use the prototype on the floor with real parts. They identify flaws, such as the interface failing to account for delays from certain barcode scanners. The team refines the logic based on this usage data.
Cutover: In week four, the team deploys the verified module into production during a planned window, replacing the manual paper process with the new digital inspection system.

Comparison: Development Methodologies

We use RAD vs Agile comparisons here.

Methodology	Time to First Working Version	User Involvement	Change Cost	Fit for Plant Software
Waterfall	Months+	Delayed/Low	High	Poor
Agile	Weeks	High	Moderate	Moderate
Low-code (While low-code platforms are useful)	Days	Low	Low	High (Simple forms)
RAD	Weeks	High	Moderate	Excellent (Complex integrations)

*Note: While custom RAD handles OPC UA integrations, low-code platforms effectively handle simple forms and approval workflows; custom RAD handles complex SCADA data, MES integrations, and strict permission models required for plant-floor operations.*

RAD in Manufacturing: The Prototype Helps Refine the Requirement

In manufacturing software, the initial requirement rarely captures the full process. For example, a production manager might ask: “Let the planner quickly raise the priority of an urgent order.” When the planner sees the feature with real data, new questions arise. What happens to a job that is already on quality hold? Is the necessary material available? Can the selected machine run the job? What happens to the downstream assembly step? But every discovery must move from the prototype into a formal rule. Otherwise, the team will simply ship incorrect logic faster.

The Prototype Shows What Is There. It Does Not Show What Is Missing.

Imagine that an AI agent has already created a new feature to change the priority of welding jobs. The planner opens the prototype, moves the urgent order to the top of the queue, and sees the correct result. But the initial requirement might not have stated that a job with an active quality hold cannot be launched into production. The agent will not necessarily invent this rule on its own. The user can verify what they see on the screen. It is much harder to notice a rule that is entirely missing from the system. In manufacturing, many constraints remain invisible in the UI: machine eligibility, material availability, user permissions, maintenance state, safety conditions, and downstream dependencies. Anything important the team learns during discovery should end up in the specification.

A Reference Implementation and a Specification Solve Different Problems

Working code shows the team how software is built in the existing system. For example, the existing scheduling module can show how the PrimeVue Data Table receives data via the API, how errors are handled, how state management is configured, and how the application is deployed. But the code alone does not fully explain why the system must behave in a certain way. That requires a specification layer that documents:

business rules;
acceptance criteria;
permissions;
integration constraints;
failure behavior;
security requirements;
production invariants.

For example: A job with an active quality hold cannot be automatically reprioritized for production. The reference implementation shows the developer how to implement this rule within the current architecture. The specification explains that the rule must remain true regardless of who or what writes the next version of the code. This matters even more with AI-generated code: implementation is getting cheaper, so the specification has to be more precise.

RAD vs Agile: What Is the Difference?

While both methodologies prioritize iteration, RAD focuses specifically on rapid prototyping to validate requirements early in the project. Agile provides a broader framework for continuous delivery and team collaboration. Manufacturers often use RAD for prototyping and Agile for ongoing development.

How Fast Can a Manufacturing App Be Prototyped?

Teams can often build and validate a working prototype within a few days. With AI-assisted development tools, engineers can produce a working first version within a week, allowing for rapid shop-floor feedback.

Principle 1. Change the Smallest Necessary Layer

A rapid development cycle does not mean that every change must affect the entire system. Instead, the team first determines which parts are already stable and can remain untouched. If the existing MES integration, data contract, or scheduling service correctly reflects the production process, the new feature is built on top of that contract. If the problem lies in the business logic, that specific layer is changed. If only the planner’s interaction needs improvement, the backend might remain completely unchanged. This reduces the blast radius of each iteration. The fewer interfaces, dependencies, and production behaviors a change affects, the easier it is to verify, deploy, and roll back if necessary.

Principle 2. Reuse What Has Already Proven Its Value

A single component works in three different applications. The PrimeVue DataTable handles data display across the scheduling systems. Each module solves its own problem, but they all use the same component to display data. Using the same component across applications makes the software more familiar to users and cuts training time.

Standardization makes that speed repeatable. Using the same libraries, patterns, and architecture makes new modules faster to integrate. Changes in one place automatically propagate across all systems. The team does not waste time inventing new solutions for every task. It uses proven tools that already work.

Principle 3. Work Smaller Than the Project

Each feature reaches the shop floor as a standalone unit. Instead of a single large release that requires the entire system to be fully ready, the team delivers modules one by one. The first module displays the schedule for welding robots. The second adds filtering by status. The third generates a material consumption report. Each step delivers real value without waiting for the entire project to be completed.

An Azure DevOps ticket starts with a minimal scope: problem, affected users, expected outcome, sample data, and known constraints. It does not try to anticipate every detail before the prototype is created. As the production expert verifies the working version, the team adds new acceptance criteria and edge cases to the ticket or spec. Thus, the requirement evolves as the team learns.

Each iteration focuses on the three features that matter most. Keeping the scope small gives the team time to work through the details and still ship quickly. , and each module provides a stable base for the next iteration.

Trust in changes grows when their scope remains small. A small change is easier to verify with real data, troubleshoot when something goes wrong, and roll back without affecting the rest of the production flow. Each small release gives the team more evidence about what works and what to improve next.

Principle 4. Cutover Is Where RAD Should Slow Down

AI can shorten the construction cycle from days to hours. That speed should not remove the production gate. A commit to the repository triggers an Azure DevOps pipeline. First, the pipeline runs unit tests on application logic. Next, integration tests for APIs, data flows, and dependencies run. Regression tests enforce critical business rules from the specification. For example, if the specification states that a job with quality_status = HOLD cannot be moved to the production queue, a new build will fail if this invariant is violated. After automated verification, the build moves into a test environment that mirrors production as closely as possible. Here, the production expert verifies behavior that requires physical or operational context. Only then is the change ready for deployment.

Verification also includes a rollback path. The team must know how to revert to the previous application version or turn off the new behavior if production telemetry shows an unexpected effect. In manufacturing, the ability to quickly halt a change is just as important as the ability to deliver it quickly.

What AI Speeds Up, and What Remains the Engineer’s Job

AI coding agents work well when the intent is clear enough. They can accelerate:

UI scaffolding;
data models;
API handlers;
workflow logic;
repetitive integration code;
test generation;
refactoring;
technical documentation.

However, AI does not automatically understand manufacturing context. It does not know on its own that a specific PLC state means a maintenance lock. It does not know that a particular material substitution is only allowed for a subset of product families. It does not know that a seemingly harmless scheduling change can create a bottleneck in downstream assembly. Engineers spend less time writing every line themselves and more time defining architecture, business rules, integration boundaries, and verification. AI has lowered the cost of turning a description into code. It has not lowered the importance of correctly describing the system.

Brownfield Changes: How RAD Reaches Production

In manufacturing, a prototype rarely starts in a clean environment. It must fit into the existing plant stack and years of custom integration logic. So the first iteration cannot start with the user requirement alone. The team first defines the system boundaries: where data comes from, who owns it, which interfaces can be read, and through which production state changes are allowed. The read path lets the prototype work with real production data without permission to change the production state. The write path comes later, once business rules, permissions, failure behavior, and the rollback path have been verified. For example, a new scheduling module may initially only read current jobs and suggest a new queue. The planner compares the recommendation with the actual schedule. Only after validation does the system gain permission to write the approved priority change back to the production system. .

Why the Approach Fails After the Third Application

Once two developers are supporting five production lines, the workload can become unsustainable. Each new line brings its own integration work and maintenance burden. Developers get stretched thin across projects, so even small changes take longer to ship.

Prototypes accumulate faster than they can be maintained. Each new module adds unique settings, specific algorithms, and its own interfaces. Soon, the team spends more time maintaining old modules than building new ones.

If standards come later, teams are already trying to impose them on a patchwork of one-off solutions. Without shared standards, each module starts to develop its own conventions. Teams create their own libraries, architectures, and deployment processes. The stack becomes less consistent, and maintenance becomes more complex with each new line.

AI makes this problem even more apparent. If every team can generate applications faster, the number of local patterns, libraries, and deployment variants can also grow faster. Therefore, shared architecture, reference implementations, specifications, and common delivery gates must be established before rapid development scales to dozens of applications.

How Work Is Distributed

The manufacturer retains full control over the product, business context, technical leadership, and quality assurance. The internal team sets the strategy, determines priorities, and owns the outcome. Technical leaders share their knowledge of plant processes, equipment specifics, and safety requirements with the external team.

AI can accelerate part of the implementation work, but ownership does not transfer to the AI. The Engineering team defines the architecture, enforces production invariants, approves the specification, and determines which verification gates are needed before deployment.

The external team handles integration with the existing engineering environment. Developers study the current architecture, connect to existing APIs, and work within established standards. They perform the technical implementation, create modules, configure deployment pipelines, and keep the tooling running reliably.

Here is how that split can work: the internal team determines that the welding schedule needs to be optimized because of a change in material supply. The technical leader provides the requirements, data, and system access. The external team analyzes the existing infrastructure, develops a new algorithm, tests it in the environment, and deploys it to the line. The manufacturer verifies the result, confirms quality, and decides whether to scale it. Each side has a clear role so that work can move from a plant need to a production change without ownership gaps.

Self-Diagnosis

Five questions can help assess the current state of the manufacturing system. First: Does deploying new features take more than two weeks? Second: Is there a long lag between a manager’s request and a change on the line? Third: Do different departments use separate tools without a shared platform for accessing data? Fourth: Is maintenance consuming more time than new development? Fifth: Does the team feel that every new module requires a one-off approach with little to reuse?

If you answered yes to two or three of these, the current setup is probably showing signs of strain. At that point, slow software delivery begins to affect plant performance.

The first application can be a practical alternative to a multi-year transformation program. Instead of a large-scale plan that would require years of implementation, the team focuses on a specific process. The first module shows whether the approach works before the team rolls it out to other lines or processes.

One Change Through the Entire RAD Loop

The production manager sees that a critical order is delayed due to a change in material supply. They ask for a way for the planner to raise the priority of a specific welding job.

Requirements planning. The ticket documents the problem, the affected users, the affected scheduling process, and the expected outcome. At this stage, the team does not yet attempt to describe all possible cases.
User design. Using the existing scheduling application as a reference, an AI coding agent creates the first working control for changing priorities. The planner tests it with real data and almost immediately spots a problem: the feature allows raising the priority of a job that is on quality hold. The prototype satisfied the requirement but revealed a missing rule.
Specification. The team adds the invariant: A job with an active quality hold cannot be released or automatically reprioritized for production. The team adds another criterion: the planner must see the reason the change in priority is blocked.
Construction. The agent or engineer updates the scheduling logic and UI according to the new rule. Existing API, shared components, and deployment patterns are reused from the reference implementation.
Verification. The business rule becomes an automated test. Integration tests verify that the scheduling service correctly retrieves the quality state and does not bypass existing controls. The production engineer verifies the feature in the test environment.
Cutover. The verified artifact passes through the deployment pipeline. The change is deployed independently of other planning applications, if the architecture allows it.
Learn. The team measures whether planners respond to priority changes faster and whether the feature caused new downstream delays. This data becomes the basis for the next iteration.

RAD Has Become Faster. Engineering Discipline Has Become More Important

James Martin built RAD around the idea that working software helps users understand their real needs faster. A prototype that used to take weeks can now appear in hours. The goal is to shorten the path from an operational problem to verified production behavior. The prototype helps the team discover what the system actually needs to do. Discovery becomes specification. Critical rules become tests. Tests and domain validation become deployment gates. Telemetry shows whether the change truly improved the physical process. Therefore, modern RAD looks like this: Problem → Prototype → Spec → Build → Verify → Deploy → Learn. Their work simply shifts closer to the part of the system where the biggest risks lie: architecture, context, constraints, and verification. That is where speed becomes an engineering capability—not just faster code generation.

Where RAD Pays Off in a Plant

Operator tools: Custom interfaces for shop-floor data entry, including operator dashboards.
Dashboards and reporting: Real-time visualization of production KPIs.
Quality modules: Digitized inspection workflows and data collection.
MES extensions: Small, targeted modules that add missing plant software functionality to existing systems.

*Note: Validation-heavy control software (PLC, DCS) follows separate formal safety cycles. RAD helps define validated requirements for these systems by clarifying operational needs.*

For more on building plant software, see our manufacturing software development services. You can also explore AI use cases in MES modernization or see how we layer AI onto legacy systems. For a wider market view, see the manufacturing software roundup.

AI-Assisted Delivery

AI coding assistants and test-generation tools shorten the prototyping phase, allowing developers to generate boilerplate code and draft unit tests quickly.

At Devox Software, our AI-assisted delivery work focuses on shortening delivery cycles for MES and dashboard development. Automating repetitive work gives engineers more time to focus on architecture, business rules, and verification. Learn more about our AI development services for manufacturing.

Frequently Asked Questions

What happens when the prototype looks right, but the plant logic is wrong?

That’s one of the bigger risks in manufacturing software. A prototype can behave exactly as requested and still be unsafe or operationally incorrect because the original requirement omitted a rule that everyone on the plant floor takes for granted.

We treat those discoveries as more than user feedback. They become explicit business rules, acceptance criteria, and tests. The prototype is there to expose assumptions. Production code should not depend on those assumptions staying in someone’s head.
Do you need write access to our production systems to start?

Usually, no.

In a brownfield environment, it often makes more sense to separate the read path from the write path. A new scheduling module, for example, can read current jobs and generate a proposed queue without having permission to change the production state.

That gives planners and engineers a chance to compare the software’s recommendation with what is actually happening on the line. Write access comes later, after the rules, permissions, failure behavior, and rollback path have been validated.
How do you avoid rewriting parts of our MES that already work?

We first look for the smallest layer that actually needs to change.

If the MES integration and data contract are sound, there is little value in replacing them just because we are building a new feature. If the issue is the scheduling logic, we change it. If operators only need a better way to interact with an existing workflow, the backend may not need to change at all.
Our system has years of undocumented behavior. How do you work with that?

We assume the codebase will tell us only part of the story.

What the code often does not explain is why certain behavior must never change.

Those rules have to be made explicit. A statement such as “a job with an active quality hold cannot be reprioritized for production” belongs in the specification and, where possible, in an automated test. That way the rule survives the next developer, the next refactor, and the next AI-generated implementation.
Where does AI actually save time, and where do you deliberately keep engineers in control?

AI is useful for parts of the implementation that are expensive but not particularly unique.

It is much less useful at deciding what the plant is actually allowed to do.

An AI coding agent does not inherently know that a PLC state represents a maintenance lock, that a material substitution is valid only for certain product families, or that moving one job forward in welding may starve a downstream assembly process.

That context still belongs to engineers and production experts. We use AI to shorten the path from a clear technical intent to working software. We do not treat it as the source of the intent.
What has to happen before you consider a change ready for production?

Before cutover, the rules discovered during prototyping should be reflected in the specification and, where practical, enforced through automated tests. The delivery pipeline should check application logic, integrations, critical regressions, and dependencies.

Then there is a category of validation that automation cannot fully replace. Someone who understands the production process has to verify the change in an environment that is close enough to production to expose operational problems.

RAD should be fast during discovery and construction. Cutover is where being deliberately boring is a feature.
How do you know a software improvement did not simply move the problem somewhere else?

We do not limit ourselves to evaluating only whether a function works.

Accelerating schedulers’ work is useful in itself, but it does not provide the overall picture of the production system’s performance.

The last step in the RAD loop is learning from what happened after deployment. Did planners respond faster? Did queue behavior improve? Did downstream delays increase? Did operators start working around the new feature?

In manufacturing, a locally successful software change can still be a globally bad production change. The physical process gets the final vote.
How do you work with our engineering team without creating a second engineering organization beside it?

Plant engineers know why a process works the way it does. An external team brings additional engineering capacity and implementation experience. Neither side is a substitute for the other.

The model works best when ownership stays clear rather than being quietly transferred to the vendor.
If we want to test Devox on one project first, what should we start with?

Pick something important enough to matter, but bounded enough that you can evaluate the result.

Good first candidates are usually software layers where requirements change frequently, and users can give useful feedback quickly: an operator workflow, a quality module, a planning interface, a dashboard, or a targeted MES extension.

A first project is less attractive when the core problem sits inside safety-critical PLC or DCS control logic. Those systems follow a different validation cycle.

The goal of the first engagement should not be to prove that someone can build a prototype. That is increasingly easy. It should show whether the team can understand your existing environment, uncover rules missing from the initial request, integrate without unnecessary disruption, and safely move a useful change into production.

We Fix, Transform, and Skyrocket Your Software.

Tell us where your system needs help — we’ll show you how to move forward with clarity and speed. From architecture to launch — we’re your engineering partner.

Book your free consultation. We’ll help you move faster, and smarter.

Achievements

About Us

Careers

Rapid Application Development in Manufacturing: Shipping Plant Software Fast