The client wanted a web shop. We thought a step further.

At a glance

• Starting point: A pharma manufacturer wanted its own small web shop that would warn them before an item ran low in the warehouse.
• Solution: Instead of a full web shop, we built a lean eService, multi-tenant from day one, that reconciles stock levels several times a day and warns automatically when a threshold is breached.
• Outcome: The service runs in live production and is ready to onboard further clients without significant extra effort.

The starting point

A pharma manufacturer keeps its trade range with a GDP-certified logistics provider. Its concern is simple and serious at the same time: no item should fall below a critical quantity unnoticed. An out-of-stock situation costs supply capability, and remanufacturing a medicine needs lead time you only have if you spot the gap early enough.

The client came with a concrete idea: their own small web shop that does exactly one job, the stock alert. That idea didn't come out of nowhere. In the gated ordering portals we've run for this provider and its clients for years, an automatic stock alert is a proven, heavily used module. The client knew the feature from daily use and wanted it in isolation.

Our approach

A full web shop for a single alert function would have been overhead: setup, master-data maintenance and dependencies the purpose didn't justify. We advised against it. Instead, we proposed a dedicated, self-contained eService on a current Symfony foundation. One job, solved cleanly, simple to run.

A second decision went beyond the brief: we designed the service to be multi-tenant from the start, even though only one client had asked for it. The reasoning came from experience, not from a spec document. A feature built into every ordering portal and used everywhere isn't a one-off, it's a recurring need. A need like that is worth building as a standalone, reusable service.

We took the pragmatic route technically too. The interface we'd initially assumed we'd need turned out to be unnecessary: the stock data already existed as a standard warehouse report, delivered as a file several times a day. No new data channel, no extra load on the provider. We connected what was already there.

The solution

• Multiple daily stock reconciliation. The service reads the warehouse report automatically and keeps article master data in sync, with no manual maintenance.
• Precise stock logic. Alerts fire only on the quantity actually available. Reserved, blocked and quarantine stock are correctly separated and shown for context, so an alert never leads you astray.
• Thresholds per item. Reorder point and recipients are maintainable per item; falling below the threshold triggers an automatic email alert.
• Self-maintaining master data. New items arrive with the import, discontinued ones disappear automatically. The backend stays clean without anyone having to tidy it up.
• Clean tenant separation. Each client sees only its own items and recipients.

The turn

A feature the client wanted in isolation has become a standalone asset, a service built not for one client but to hold up for many.

Because we've known this provider's industry and ordering portals for years, we spotted the leverage before anyone said it out loud: the same stock alert that practically every warehouse client needs sooner or later can be offered as a central service, turning an internal feature into added value the logistics provider can offer its own customers. We didn't just deliver the technology; we delivered a well-founded, current plan for how this new asset can generate recurring value, so it pays for itself quickly and then keeps earning.

That's the role we fill here: external, but with the eye of an in-house employee who thinks development, strategy and project management together and anticipates business decisions instead of just ticking off tasks.

The outcome

• Running in live production, confirmed in real tests against real stock, not a dummy setup.
• Robust detail logic built from real requirements, such as the correct handling of deleted items and predictable behaviour when adjusting thresholds.
• Ready to onboard further clients without significant extra effort. The foundation for scaling is in place.
• Runs on the warehouse interface that already existed, with no extra data channel.

What this story shows

The fastest way to tick off a task is rarely the best one. Knowing a client's systems and business for years lets you make the right cut: not the web shop they asked for, but the service that fills exactly the gap between warehouse system and client that would otherwise stay open, and one that can be replicated.

The same way of thinking we use to manage product ranges and stock in e-commerce holds up in the regulated pharma world too. One way of working, two worlds.

Thinking a step further before building isn't chance, it's method, as our consulting & architecture page for pharma logistics explains.