Is it a prototype or an engineering project?
You’re working on a project or prototype that could very well revolutionize the world. At first, it’s exploratory: a test bench, a model, a script, a proof of concept, a setup that works as long as no one sneezes nearby.
Then, the prototype starts to come together. You want to connect it to a real process. Test it in the field. Use it with real data. Have colleagues work with it. Integrate it into a system.
Things are picking up speed. We’re talking about more serious testing, a pilot project, a potential client, maybe even a market launch. The project isn’t just a good idea sitting in a corner of the lab anymore—it could become a reality. Yeah!
But then somebody bursts your bubble with a question you can’t dodge: Are there technical decisions that need an engineer’s supervision or approval?
Here’s what changes everything: the potential consequences
As long as you’re testing an idea in a controlled setting (in a lab, workshop, simulation environment, or with fictitious data), you can still break things, start over, compare results, and learn without exposing the real world to what could happen if the prototype fails.
But as soon as you move into field testing, a pilot project, or real equipment, you need to consider the potential consequences. Could someone get hurt? Could equipment get damaged? Could a process be disrupted? Could a decision be skewed? Could your team, a client, a patient, or the public be affected?
If so, certain technical decisions might need to be supervised or validated by an engineer. The key word here is consequences. Not the level of enthusiasm surrounding the project. Not the fact that it’s still called a “prototype.” What matters is what could happen if something goes wrong.
What might need an engineer’s review
At this stage, not all project- or prototype-related activities suddenly become reserved. Only certain technical elements may need an engineer’s review, for example:
- loads, thresholds, tolerances, or safety factors
- the acceptability of a result
- the compliance of a system
- the operating conditions
- the logic that controls a process
- the recommended technical solution based on testing
| The situation | The intended use / consequence | The right reflex |
|---|---|---|
| You’re testing a sensor on a test bench, in a lab | The results will be used to compare options internally | Not necessarily a reserved activity. Document your tests and confirm the intended use with your supervisor |
| You’re integrating a sensor into equipment used by a team | An incorrect reading could cause a shutdown, damage the equipment, or endanger someone | Have an engineer approve the critical parameters |
| You’re coding a tool that organizes data or produces a dashboard | You’re coding a tool that organizes data or produces a dashboard The tool helps visualize information, without determining compliance Not necessarily a reserved activity; make sure the tool’s intended use is clear | Not necessarily a reserved activity; make sure the tool’s intended use is clear |
| The tool you’re coding will be used to determine whether a system is compliant | The result influences a technical decision or certification | Have an engineer review the logic and criteria |
| You’re developing a mechanical prototype in the workshop | You’re developing a mechanical prototype in the workshop It remains under controlled testing, with no real-world use You can continue to test, compare, and improve | You can continue to test, compare, and improve |
| The prototype you’ve developed will be connected to a machine or a production line | It may have real-world consequences for people, equipment, or a process | Bring in an engineer before field testing |
| You’re compiling field data | The data is used solely to better understand the situation | Not necessarily a reserved activity |
| You’re using data to recommend a design, implementation, or safety measure | You're moving from observation to technical recommendation | Have an engineer review the analysis |
The key habit
Recognize when the prototype is no longer just a learning tool, but is being used to make decisions or recommendations—or to assess something that may have real-world consequences.
R&D is about exploring, testing, failing, fixing, and starting over. That’s precisely what makes it useful. But when a prototype starts to leave the lab, the GitHub repository, or the corner of the workshop, the right question is no longer just: “Does it work?”
It’s also: “What happens if it doesn’t work?”
That’s often where the real engineering question arises.
See also
You can launch a startup in engineering before you get your...
Yes, you can become an entrepreneur. But you can’t just call yourself an engineer.
Programming a PLC: coding or engineering?
Short answer: coding isn’t deciding everything
Reserved activities: What you can do without breaking the ru...
You’re a CEP or doing an internship. Your manager asks you to update a plan before it’s sent to the client. You’re [...]
