No More Shortcuts

For the first two months, it looked like any other software project. Meetings with the customer. Requirements gathering. Wireframes. Backlog. A new architecture. The goal was to transform an existing solution, simplify the product and prepare it for the next stage of its evolution.

Nothing suggested we were about to build a completely different kind of system. Not because the requirements changed, but because the expectations of how the software should be built suddenly did.

Two Months Later, Everything Changed

A company specializing in medical device certification joined the project. I remember the first workshop. I expected discussions about standards and formalities. Instead, we were told that from this point forward, almost every decision we made would become part of the certification process.

It wasn't about writing better code. It was about proving that the entire development process was repeatable, intentional and fully traceable.

We were no longer transforming just the product. We had to transform the entire team.

There Was No Room For Shortcuts

Every development team knows these sentences.

"It's just a small change."
"We'll test it in the next release."
"An email is enough."

Overnight, none of them were acceptable anymore. Not because someone wanted to slow us down, but because the software was becoming part of a process supporting the diagnosis and therapy of children. Quality was no longer a competitive advantage. It became a responsibility.

Code Was Only Part Of The Product

The biggest change wasn't the technology. It was the process around it. Jira stopped being just a project management tool. Every task became part of the project's history. Every decision required a clear justification. Every test had to prove a specific requirement. Every change needed to be understandable months later by someone who had never participated in the project.

For the first time, I worked on a system where the process was just as important as the software itself.

Two Different Worlds

One of the most interesting parts of the project had nothing to do with programming.

We explained technology to the customer. The customer explained medicine to us. We had to understand concepts like signal-to-noise ratio, learn how therapeutic exercises should be designed and even how specific sounds should be generated.

None of those problems could be solved with code alone. Before building the solution, we first had to understand the world it was being built for.

The First Audit

Several months later, the first audit finally arrived. We had spent weeks preparing for it, knowing that the auditors wouldn't evaluate only the product. They would evaluate the entire journey that led to it.

I expected a long list of findings. Instead, we heard that they hadn't seen such a well-prepared software project in a medical certification process for a long time.

That moment stayed with me. Not because someone praised our work, but because it proved that all the extra effort, discipline and attention to detail had actually mattered.

Final Thoughts

Most software projects will never become certified medical products. And that's perfectly fine.

But every project reaches a point where quality stops being a nice-to-have and becomes a responsibility. Since then, one question has stayed with me:

What happens if this system stops working?

From that project on, two words almost disappeared from my vocabulary: "Good enough."