Agile, Waterfall, or NRE? Choosing a development methodology

Four collaboration models, one framework for picking the right one

Key takeaways:

• The collaboration model chosen at the start of a project often shapes its outcome more than the technology decisions that follow.
• Agile suits projects where requirements are expected to evolve, giving the customer high control but a gradually forming result rather than a fixed one.
• Agile Capped combines agile flexibility with a fixed budget, which means scope is continuously reprioritised rather than guaranteed in full.
• NRE is not a project management methodology but a financing model: the customer funds a one-off modification to an existing ACRIOS catalogue product, which remains part of the product portfolio.
• Waterfall works best with a complete, stable specification, offering predictable scope and timeline but making changes harder to absorb once the project is underway.
• A collaboration model is not fixed for the life of a project. It can shift, for example from a feasibility study into agile prototyping and then into planned stages, as requirements and technical understanding evolve.

‍

Product custom development doesn't start with picking technologies or writing the first lines of code. A project's success often depends on the collaboration model chosen right at the start. Agile, Agile Capped, Waterfall, and NRE each make sense in different situations, with their own advantages and limits, and recognising which approach fits a given project is the first real decision to make.

Why the collaboration model is never just a formality

When planning IoT device custom development, budget, timeline, and technical requirements tend to get most of the attention. Less thought usually goes into how the project will actually be managed. Yet that choice can shape the whole course of the project.

If requirements are expected to change during development, a rigidly defined process becomes an unnecessary constraint. Conversely, on projects with a precise specification, an overly flexible process can add more administration than value.

Similarly, a new product does not always have to be built from scratch; in some cases it is faster, more economical and less risky to modify an existing solution. There is no single best collaboration model. There is a model that best fits a given project, its goals and its level of readiness.

Before technology or architecture decisions come up, it helps to answer following basic questions. The answers to these questions usually reveal more than a feature list ever could.

• Is the specification complete, or will it still be refined during the project?
• Is this a completely new product, or a modification of an existing solution? Not every project needs to be built from scratch; adapting an existing platform can significantly shorten development time and reduce costs.
• What is the highest priority: speed to market, a fixed budget, or a precisely defined scope?
• Are changes expected during development? If so, a model that accommodates ongoing change is the better fit.
• Does technical feasibility need to be verified first? On more complex projects, it is often more efficient to validate architecture, technologies, or technical constraints before full development begins.

Agile: the fastest route from idea to result

Agile works well on projects where experimentation, hypothesis testing and gradual refinement of requirements are part of the process. Work happens in short iterations, and each one ends with a real step forward, a prototype, a feature or a test. The project mirrors reality this way, and it is possible to respond to change without rewriting the whole specification. Agile tends to be a good fit when:

• a new product or technology is being built,
• the technical solution needs ongoing validation,
• requirements are expected to be refined gradually,
• fast feedback is the priority.

‍

The customer retains a high degree of control, but the result takes shape gradually rather than being fixed in advance. Agile also requires active customer involvement, since decisions are made continuously.

Agile Capped: agile development with guardrails

Agile Capped combines the flexibility of agile development with a clearly defined budget cap. It is a good compromise when speed and adaptability matter, but the investment still needs to stay under control. Priorities are set together with the customer, and the most important features move into sprints first. Agile Capped is a good fit particularly when:

• the project budget is fixed,
• the customer wants to keep adjusting priorities as the project goes,
• delivering every originally envisioned feature is not essential,
• maximising the value of the result matters more than a fixed scope.

‍

It is not a universal solution, though. A fixed budget does not automatically mean a fixed scope; if new requirements emerge during development, other features need to be deprioritised or pushed to a later phase. Where a company needs a guaranteed, complete result, this model may not be the right fit.

NRE: tailoring a catalogue product

Not every project requires developing a new product; often it is enough to extend or adjust a solution that already exists. In industrial electronics or IoT, that can mean adding support for a new communication protocol, adjusting a hardware interface, extending firmware, or adapting a product to a customer's specific requirements.

This is exactly the situation NRE (Non-Recurring Engineering) is designed for. Unlike Agile or Waterfall, it is not a project management methodology, but a way of financing one-off development work. The customer funds a specific modification to an ACRIOS catalogue product, while the product and its further development remain part of the product portfolio. NRE tends to be a good choice when:

• a new feature needs to be added to an existing device,
• support for another communication interface or protocol is needed,
• a product needs adapting for a specific integration,
• developing a new product from scratch would not be economical.

‍

Before deciding to develop a completely new device, it is worth checking whether the same goal can be reached by modifying an existing platform. At ACRIOS, this route is part of our end-to-end custom development and OEM manufacturing, where NRE is a common form of collaboration.

Waterfall: when the specification is fixed

Waterfall is a linear, predictable approach. We use it when the specification is fully described, is not expected to change, and the project can be broken down into clear steps: analysis, design, development, testing, and deployment. Waterfall tends to be a good fit when:

• a complete technical specification already exists,
• requirements are stable, and no major changes are expected,
• the project is subject to strict processes or certification,
• predictability of scope, timeline, and documentation is the priority.

‍

Its strength is complete predictability; its weakness is that any change during the project slows the whole process down. If new requirements do emerge, incorporating them tends to be harder under Waterfall than under agile approaches, which is why solid upfront preparation matters even more here.

How to choose the right collaboration model

The decision depends mainly on how well prepared the project is, how much room remains for change, and whether it is a completely new product or the evolution of an existing solution. The diagram below summarises the decision logic step by step.

‍

‍This table is indicative; the right model always depends on the specific project, its goals and its technical constraints. Some projects combine more than one approach; a collaboration model is not set in stone and can evolve alongside the project.

A collaboration model can change during a project

A project is not static. As requirements get refined or technical solutions get validated, the most suitable way of managing the project can change too.

A typical example is a project that starts with a feasibility study, moves into agile development of a prototype once the technical concept is validated, and then, once requirements are stable and the architecture proven, shifts into precisely planned stages. Equally, analysis can reveal that modifying an existing product through NRE would be more efficient than developing a new device. A collaboration model should therefore never be a goal in itself; it should support the project at every stage. And what are the most common misconceptions about custom development methodology?

• Agile is not always the best choice
  • If requirements are clearly defined from the start and no changes are expected, Waterfall can be more efficient and more predictable.

• A fixed budget does not automatically mean Waterfall
  • A project with a fixed budget can still be run successfully with an agile approach; what matters is setting priorities correctly and accepting that scope may shift during development.‍
• ‍A new requirement does not necessarily mean a new product
  • If a suitable platform or catalogue product already exists, extending it can be faster, more economical and less risky than designing a completely new device.

Why it pays to start with a feasibility study

A feasibility study tends to be the first step, particularly on more complex projects or where the optimal technical solution is not yet clear. Its goal is not to produce a final product design, but to verify whether the intended solution is achievable, what risks it carries, and which approach will be most efficient. A feasibility study typically assesses:

• the technical feasibility of the proposed solution,
• the suitability of the chosen technologies,
• possible technical or legislative constraints,
• the need for certifications or specific standards,
• integration options with other systems,
• the expected complexity of development.

‍

A well-prepared feasibility study often uncovers potential issues before development even begins, which can save time, cost, and later project changes.

How we typically work at ACRIOS

Every project is different, but the first steps tend to look similar. First, we need to understand what the customer wants to achieve; only then do technology or project management decisions come into play.

• Getting to know the project: goals, requirements, and expectations.
• Assessing technical feasibility: verifying possibilities, constraints, and risks.
• Recommending a suitable collaboration model based on the nature of the project, not on one preferred methodology.
• Designing the architecture and development plan.
• Delivering the project according to the chosen model.

Key points in brief

• If requirements are likely to change, consider Agile.
• If flexibility and a fixed budget both matter, consider Agile Capped.
• If an existing product is being modified, consider NRE.
• If the specification is complete and stable, consider Waterfall.
• If the technical solution is not yet clear, start with a feasibility study.

‍

Custom development is not just a question of technology; choosing a collaboration model that fits the nature of the project, its goals, and its level of readiness matters just as much. Agile, Agile Capped, Waterfall, and NRE are not competing approaches; each addresses a different situation. At ACRIOS, we do not start by picking a methodology; we start by understanding the project, and only then, based on its technical requirements and possible risks, do we recommend the collaboration model that makes the most sense.

Glossary of terms used

• Agile – an iterative development approach where requirements are refined gradually, and each iteration delivers a real output. It is based on the principles of the Agile Manifesto from 2001.
• Agile Capped – a variant of agile development with a predefined budget cap, within which the most important features are prioritised.
• NRE (Non-Recurring Engineering) – a one-off modification of an ACRIOS catalogue product, tailored to a specific customer or project.
• Waterfall – a linear development approach where a project proceeds through clearly separated stages: analysis, design, development, testing, deployment.
• Feasibility study – an initial analysis carried out before a project starts, identifying technical constraints and the most suitable path forward.
• Sprint – a short, time-boxed period in agile development during which a team delivers a specific piece of functionality ready for validation or further development.
• Iteration – a repeated cycle of design, development, testing and evaluation that allows the resulting solution to be improved continuously.
• Project scope – the set of features, requirements and deliverables to be completed within a project.
• Proof of concept (PoC) – a practical validation that a proposed technical solution is achievable, without the goal of producing a final product.

‍