Ordering for hospitals: a web shop and an operating-room scanning app

Context

A large purchasing cooperative in German healthcare pools purchasing for its member hospitals. From mid-2025, a backend developer and I built two new products for it:

• an ordering web shop where heads of purchasing and strategic buyers order their hospital’s daily and weekly supplies. Filled baskets go to the existing ordering system, which places the order.
• a scanning app for nurses in the operating room: scan items where they are used and reorder them, manage cabinets, record inventory.

My part

My colleague decided and built the backend architecture (.NET). Everything else was mine to decide, plan, build and administer: the web frontend (React, TypeScript), the mobile app (React Native with DataWedge for the hardware scanners), the database (PostgreSQL), and cloud services and infrastructure on Azure.

My responsibility ended at the question of what to build. At first I did not know how buyers work. The business definition therefore sat one level above me, with someone who knew both IT and purchasing: how processes had to be modelled, what the workflows look like, where they had to be as light as possible and where detail and flexibility mattered.

The hard decision: removing the BFF

At first, a backend-for-frontend (BFF) in Java/Spring Boot sat in front of the React frontend, built on the pattern of an existing portal of the cooperative. It handled authentication, cookies and routing.

Over time, routing moved into React Router, and what remained of the BFF was essentially a proxy between frontend and backend. I proposed removing it. The main reason was the team: with two developers, Java next to .NET and TypeScript meant a third language and runtime to maintain, deploy and expect from anyone taking over. Without the BFF, the stack is .NET in the backend and TypeScript in the frontend, and the frontend talks to the API directly and type-safely. That makes it much easier to find a successor for the project.

Authentication itself never depended on the BFF: before and after, it ran on a central identity provider. Today the frontend signs in there directly with OAuth 2.0 and PKCE.

Collaboration

• Backend colleague: aligning the API between backend and frontend.
• Technical leadership: design and planning of the project.
• Pilot hospital: a meeting every two weeks with the head of purchasing of a member hospital, to collect feedback from day-to-day use.

Outcome

Status when I handed over in July 2026:

• Scanning app: the parsers for HIBC, GS1, EAN and GTIN were complete, covered by several hundred unit tests. The app reads the codes that actually appear on medical products.
• Web shop: article search across more than a million articles, the hospitals’ organisational structures, a permission system, and creating and filling lists and baskets.

Looking back

The BFF should never have existed. It came from routine, because an existing portal had been built that way, not from planning for this project. My lesson: every layer needs a reason at the start that comes from this project, not from the last one.

---

I leave out product and customer names, internal figures and screenshots on purpose. I’m happy to tell you more in a conversation, as far as my confidentiality obligations allow.