Pharmacy portal development: where the ordering logic breaks
Pharmacy portal development almost always runs up against not the storefront, but three places where the ordering logic diverges from reality. The first is stock.
The drug catalog shows availability from a cache that updates every few minutes or once a day, while at the register the item has already been sold or written off due to expiry.
A customer reserves an item, shows up, and it's not there — trust in the portal is lost from the very first such case.
The second is pharmacy geo-search. If it's built on straight-line distance to a point rather than the actual route, the portal sends the person to the pharmacy that's nearest on the map but actually takes longer to reach than the one next door.
A separate problem is being tied to imprecise coordinates: the address is determined by the center of the district, and the results shift by a kilometer, even though there's a location nearby with the needed medication.
The third is reserving an item without confirmation. The request goes nowhere: the pharmacy doesn't see it in its queue, the customer believes the item is being held for them, and the reservation has no time limit.
None of this is storefront cosmetics — it's the gap between the interface and the pharmacy's inventory system.
Let's break down how this gets closed: real-time stock synchronization with the inventory system, route-based geo-search, and a confirmed reservation with a clear lifespan.
What a portal with a catalog and booking provides
Finding the right medication in seconds, not in a phone call
The catalog with stock levels is built on regular synchronization with the pharmacy chain's accounting system: items, pack sizes, analogs, and availability at each location are updated at a set interval.
A visitor enters the active ingredient or brand name and immediately sees where the medication is available right now — without follow-up calls or trips "on a hunch." Searching across pharmacies by district, operating hours, and proximity to the route shortens the path from query to a specific location to one or two minutes.
Booking without a call and a predictable confirmation rate
A booking is made in the interface: the customer selects a pharmacy, locks in the item, and receives confirmation, while the employee sees the order in their queue.
The booking hold period is configured to match the chain's logistics, so the product doesn't "sit" on the shelf, and the share of confirmed bookings grows thanks to automatic stock verification at the moment of booking.
If the item isn't available, the system suggests the nearest location or an analog — the customer doesn't leave with an empty result.
The load on operators drops for routine inquiries
Typical questions — "is it in stock," "how late are you open," "can you hold it" — are handled by the portal without human involvement. Operators switch to complex cases: prescription items, delivery, complaints.
With the same staffing, the chain handles more inquiries during peak hours, and line response time doesn't grow.
Manageability instead of manual reconciliations
The administrator sees statistics by location: what people search for, what they book, where refusals happen most often. This data feeds into purchasing and the distribution of stock between pharmacies — the assortment adapts to real demand rather than last year's reports.
Ways to link the catalog with pharmacy stock
Linking the catalog with real stock is the most fragile part of the portal: if availability data lags, the buyer reserves something that is not on the shelf, and the call to the pharmacy turns into a refusal.
The choice of synchronization method determines how often stock is updated, what happens when the accounting system is unavailable, and how much manual work falls on pharmacy staff.
We have worked with all three schemes and see them as follows.
| Option | When it fits | Limitations |
|---|---|---|
| Direct integration with the accounting system | One or two pharmacies, a single accounting software vendor, a stable communication channel | Any failure of the accounting system brings down stock on the portal; updates are tied to its schedule; as the network grows, the number of integration points grows explosively |
| Intermediate layer | A pharmacy chain, different accounting systems, a need for update frequency higher than the accounting loop provides | Requires a separate service and its maintenance; discrepancies between the layer and the accounting system must be handled by a defined process |
| Manual updates | A small assortment, infrequent changes, no access to the accounting system | Stock becomes outdated within the day; data entry errors; reservations for unavailable goods |
Why the intermediate layer usually wins
It pulls data from the accounting system on a schedule, normalizes it to a unified form, and serves it to the catalog.
The update frequency is set separately from the schedule of the accounting loop — stock can be refreshed noticeably more often, and when the system is unavailable, the portal keeps working on the last snapshot, marking the data as "being updated".
What we resolve at the design stage
We determine which events count as a stock change, how conflicts between the layer and the accounting system are resolved, and what the buyer sees if the data is outdated. Separately, we fix the reservation rules: how long the hold lasts and when it is automatically released.
How we build the portal: stages of work
Work proceeds in iterations of 1-2 weeks: each ends with a demonstration on a test environment, not a report in a document. This way the client sees a working geo-search and reservation long before the final delivery and can adjust priorities while changes are still inexpensive.
- Data and current systems audit. We gather where products and stock come from: exports from the accounting system, supplier price lists, manual spreadsheets. We record the update frequency, duplicate items, discrepancies in units of measurement, and the rules for matching pharmacies to addresses — this is the foundation on which the entire catalog then rests.
- Integration schema design. We determine what we pull in real time and what in batches on a schedule, how we handle source unavailability, and what we show the user if stock data hasn't arrived. Separately, we describe the behavior when a reservation is canceled and an item is returned to sale.
- Catalog and geo-search assembly. We implement search by name, active ingredient, and dosage form, ranking by distance and availability. We test on real addresses: how the results behave at the boundary of districts, with imprecise coordinates, and at peak load.
- Reservation setup. We define the reservation lifetime, limits per item and per user, repeat reservations, and notifications about order readiness. We coordinate scenarios with pharmacists: what to do with partial availability and how to release a reservation if the customer doesn't show up.
- Scenario testing. We run end-to-end paths: search, pharmacy selection, reservation, confirmation, dispensing. Separately — failures: empty stock, a closed location, loss of connection with the accounting system, simultaneous reservation of the last package by two customers.
- Portal handover. We deploy to the production environment, set up backup and availability monitoring, hand over access credentials and documentation. We train pharmacy staff to work with the reservation queue.
In parallel with development, we keep a decision log: why this synchronization interval was chosen, how distance is calculated, what happens when stock conflicts occur. At handover, it becomes a manual for your team — the portal can be developed further without us.
What the client receives
A pharmacy portal does not exist in a vacuum: it has a business-side owner, an on-call engineer, and a contractor who joins for further development.
To keep handover from turning into archaeology through someone else's files, we deliver the project as a set of artifacts — with a description of how the system is structured and how to maintain it.
- Data schema — relationships between products, pharmacy locations, stock, reservations, and users, with a description of keys and integrity constraints.
- Environment configurations — connection parameters for the catalog, geo search, and external drug directories, separately for the test and production environments.
- Update procedure — the process for deploying a new version, verifying migrations, and rolling back to the previous release if the checks fail.
- Portal documentation — integration points, exchange formats, behavior when an external service is unavailable, and the logic for recalculating stock.
- Access policies — roles for pharmacy staff and administrators, data visibility boundaries, and rules for handling customer personal data.
- Reservation description — the lifecycle of a request from creation to pickup or cancellation, including the reservation expiration period and re-release of the product.
- On-call shift instructions — what to check when there is a complaint about search or a reservation, and by which signs to distinguish a catalog failure from a problem on the pharmacy side.
Such a set removes dependence on specific people: a new engineer gets up to speed on the project through documentation, not through chat history. Describe your task — we will come back with an estimate and a plan, including the composition of the materials to be handed over.
Case: pharmacy chain portal with geo-search
A chain of several dozen pharmacies came with a classic problem: stock in the catalog diverged from the actual availability on the shelf. A customer would choose a product, travel to a specific location — and not find it.
The share of such requests reached a third of all reservations, and pharmacists spent their shift on calls and manual confirmation instead of working with the customer.
We rebuilt the data exchange between the point-of-sale loop and the portal.
Stock for each location began updating based on sale and receipt events rather than on a schedule once every few hours, so an item leaves the available-for-reservation list almost immediately after a sale.
Geo-search ranks locations not by a straight line but by the actual route and opening hours: if the nearest pharmacy is closed or the product is not there, the customer immediately sees the next suitable one.
Pharmacy chain received a portal where a reservation is confirmed automatically, and disputed items go to a pharmacist in a separate priority queue.
The average confirmation time dropped from several hours to minutes, the share of cancellations due to "product not available" fell almost to zero, and the shift workload decreased by roughly a quarter thanks to the eliminated calls.
We separately addressed the partial order scenario: if two out of three items are confirmed, the customer sees this before the visit and decides whether to pick up the remainder. This step removed the main cause of negativity at the checkout and relieved the support team.
How does a hold differ from a reservation in a pharmacy portal?
A hold and a reservation are different entities, and confusing them in a pharmacy portal is costly. A hold records the customer's intent: the order is tied to a specific person, it has a hold retention period, after which the item returns to the available stock.
A reservation is the physical holding of a package on the shelf for an already confirmed order, and it reduces the available stock for all other buyers immediately. While the item is in reservation, an offline cashier cannot sell it and another portal visitor cannot reserve it.
The difference shows up at the moment a hold is cancelled. If the customer declined before confirmation, the system simply removes the hold — the stock returns to the catalog, and no staff action is required.
If a confirmed reservation is cancelled, however, a return scenario is needed: the warehouse operator removes the physical tag, the item becomes available again, and the transaction history remains in the log for reconciliation.
Without this, discrepancies between the portal's data and the actual on-hand inventory accumulate within just a few days.
The choice of mode depends on the pharmacy's operating model. For pickup with a short window, a reservation for a few hours is sufficient: it protects against double-selling, but requires staff to remove expired holds on time.
For delivery and pre-orders, a two-stage scheme makes more sense — first a hold with a clear retention period, then conversion to a reservation after stock availability and payment are confirmed. This way the portal does not block stock for orders the customer will not purchase.
Both modes have limitations. A reservation without automatic timeout removal freezes the shelf and reduces turnover. A hold without real-time stock verification leads to cancellations at the picking stage, when the item is already out of stock.
We build separate statuses, timers, and hold cancellation rules with customer notification into the data schema — otherwise the portal and the pharmacy begin living in two different realities.
Common technical concerns
Before starting, clients usually ask the same questions: will the portal withstand peak load, how will it connect to the pharmacy's inventory system, and what happens to the data when stock levels change every few minutes. Below are the answers, to the point, without generic filler.
Will the portal withstand a seasonal surge — for example, during a rise in illness rates?
The catalog and product pages are served from cache, while search and stock checks go to the database — heavy queries don't block page delivery. This separation of roles keeps response times stable when concurrent visitors are many times higher than usual. We confirm capacity with a load test on a profile close to real-world conditions.
How does the portal get up-to-date stock and prices from the pharmacy's inventory system?
The exchange goes through an integration layer: it pulls changes from the inventory management system and distributes them across the catalog. Data is updated on a schedule and by events — an item that's out of stock isn't shown as available for reservation.
If the external system is unavailable, the portal runs on the last snapshot and doesn't show the customer a knowingly incorrect status.
What about support after launch — will fixes take weeks to wait for?
Support follows a regulation with urgency levels: a failure in reservation or payment goes to the front of the queue, planned enhancements go in an agreed order. We roll out updates through automated builds and checks, so a typical fix doesn't turn into a lengthy operation.
Access credentials, logs, and the deployment scheme remain with you; we don't lock the portal to ourselves.
Can the portal be extended later — adding delivery, a loyalty program, a second chain?
The architecture is split into independent parts: catalog, search, reservation, personal account. A new module connects to them without rewriting what exists, and a second pharmacy chain is added as a separate data source. That's why growing the portal is an enhancement, not a new project from scratch.
Describe your task — we'll come back with an estimate and a plan for load, integrations, and support.
Let's discuss your portal's task
To make the estimate accurate rather than "give or take," before starting development of a pharmacy portal, it's important for us to understand your scenario in full: how stock across locations is structured, who is responsible for card content, whether there is integration with your accounting system, and how you envision booking — with or without payment.
The more specific the inputs, the fewer assumptions in the plan and the more predictable the timelines.
What's worth preparing for the conversation:
- a list of pharmacy locations with addresses and operating hours — for geo-search and delivery zones;
- an export of the product range: names, dosage forms, dosages, analogs, and flags for prescription-only items;
- data on stock and the rules for updating it — how often and from which system it reaches the portal;
- a description of the booking scenario: how long a request is held, pharmacist confirmation, cancellation, and notifications;
- requirements for roles and access — catalog administrator, location operator, support;
- examples of portals you like in terms of search logic and product card.
After reviewing the task, we'll come back with an estimate and a plan: we'll break the work into stages, pin down what we do on your side and what we take on ourselves, flag risks around integrations, and propose a launch order — first the catalog and geo-search, then booking.
Describe the task in whatever format is convenient, and we'll come back with specifics on timelines and scope of work.
