Beriflapp

We value your dreams and continue to take on challenges to create innovation and achieve great goals.

22/10/2026

Software dependencies are usually evaluated on what the product needs today: capability, security, integration effort, cost.

The harder question is what happens if that technology reaches end-of-support while the medical product is still deployed.

By then, replacing it may involve far more than changing code. Existing customer environments may need retesting, rollout coordination and support while the product continues operating in the field.

That future work is easy to underestimate when the dependency is first selected because the installed base does not exist yet.

For long-lived MedTech software, understanding how a critical dependency can eventually be replaced is part of understanding its real cost.

15/10/2026

A new hospital, device or workflow can look like a rollout problem.

The implementation questions are obvious: integration, compatibility, configuration, training. The performance question is easier to miss.

If the new environment changes the type or quality of data reaching the model, the results used to validate that model may no longer describe the deployment as closely as expected.

That can turn an expansion decision into additional evaluation work, even though the model itself has not changed.

For MedTech teams scaling AI-enabled products, the useful question is simple: what changed around the model, and could that change the performance we are relying on?

12/10/2026

That’s a wrap on KOSICT 2026! 💚

Over the weekend, we had the chance to meet and connect with many businesses, professionals, and students, exchange ideas, and have great conversations about technology, careers and what’s being built across the industry.

Thank you to everyone who stopped by the Beriflapp booth, shared their ideas with us, or simply came over to say hello.

It was great being part of KOSICT for another year and connecting with the people shaping what comes next.

07/10/2026

Our KOSICT 2026 giveaway winners have been selected! 💚

Congratulations to the winners. We’ve already reached out via DM with everything you need to get your tickets.

Thank you to everyone who participated and followed along. If you didn't receive a message from us, we wish you better luck next time!

And if you’re heading to KOSICT 2026, make sure to stop by the Beriflapp booth and say hello. We’d love to meet you there!💚

05/10/2026

🎟️ KosICT 2026 ticket giveaway!

Beriflapp will be at KOSICT 2026 in Prishtina with our own booth and we’re giving away tickets so a few of you can join us there.

To enter:
• Make sure you’re following us
• Like this post

Winners will be selected and contacted via DM on October 7 to receive their tickets.

See you at KOSICT💚

01/10/2026

A UI request can look straightforward during estimation.

Moving a value, changing a visualization or simplifying a screen may require little development work. The wider impact often becomes clear only when someone asks how the new presentation affects clinical use.

Could it change what the clinician notices first? Does important context become less visible? Could the same result now be interpreted differently?

If those questions come after the change is already designed and scheduled, the team may need to revisit the design, testing or release scope.

For clinical interfaces, that impact is worth understanding while the change is still being planned.

24/09/2026

The first transmission of a clinical result usually gets most of the design and testing effort.

Corrections and amendments happen less often, so they are easier to leave for later.

By the time one is needed, the original result may already exist in an EHR, patient portal or another connected system.

Now the correction has to do more than change a value. It has to reach the right result, make the current version clear and preserve enough history to understand what changed.

That flow can stay invisible for months because everything works until a result actually needs correcting.

For connected MedTech products, that is a difficult moment to discover that each system handles the update differently.

17/09/2026

A customer-specific change can look small when the decision is made.

A different integration, hardware setup or configuration may solve a real customer need without requiring much development.

The longer-term commitment is harder to see.

That variation may still need attention several releases later. Product may need to decide when it can be retired. Engineering may need to account for it in future changes. Support may need enough context to understand why that customer behaves differently from the standard setup.

The cost of a custom configuration is therefore not limited to building it.

It also includes the time the organisation is willing to keep it visible, testable and supportable as the product evolves.

10/09/2026

A recurring training request can be a product signal.

If the same user action keeps causing confusion after onboarding, updated instructions or another training session, the team should look at what the product is asking the user to do in that moment.

Training can explain the intended workflow. The interface still has to support the decision while the user is actually making it.

That matters when someone is under time pressure, switching between tasks or relying on cues that seemed obvious during design review.

A useful question for Product, Quality and Engineering is:
What makes the wrong action plausible at the exact moment it happens?

If every recurring use issue ends with another training request, the team may be resolving individual cases while leaving the same interaction unchanged.

That is worth checking before the next case is closed the same way.

03/09/2026

A customer request can look ready long before the organisation has fully assessed it.

Sales sees demand. Product sees a useful expansion. Engineering confirms that the work is feasible.

Clinical, Quality and Regulatory also need to be involved early enough to assess whether the use case fits the current device scope and evidence.

If that review happens after a timeline has already been discussed or the work has entered the roadmap, the team may have to revisit the scope, evidence requirements or regulatory path with customer expectations already in place.

New clinical use cases should be reviewed across the relevant functions before anyone commits to delivery.

Can we build it?
Does it fit the product direction?
Does the current device scope support it?
Does the existing evidence support the use being discussed?

Answering those questions early gives the team a more realistic scope and timeline before expectations are set.

Adresse

Technoparkstrasse 1
Zürich
8005

Website

https://beriflapp.com/

Benachrichtigungen

Erfahren Sie als Erste/r von Neuigkeiten und Aktionen: Wir schicken Ihnen eine E-Mail, wenn Beriflapp etwas veröffentlicht. Ihre E-Mail-Adresse wird für keinen anderen Zweck verwendet, und Sie können sich jederzeit abmelden.