In specialty retail, the POS moment is where money, compliance-ish workflow, and customer patience collide. I helped build an embedded Shopify POS application for specialty order capture so associates could start and complete regulated product workflows on the sales floor, without bouncing into a back-office tool mid-line.
I will not name the merchant. I will explain what was built, because the architecture is the useful part.
What “POS prescription app” actually meant
On paper it was an embedded Shopify POS app. In practice it was a small product:
- React UI for associates inside POS
- Koa/Node APIs for domain actions
- MySQL persistence for specialty order state that Shopify alone did not model well enough
- AWS hosting with environment-specific deploy definitions for east/west style rollouts
- Sequelize migrations so schema changes were not tribal knowledge
Cashiers did not need a platform lecture. They needed a tile/modal flow that felt native, failed clearly, and left an order state operations could finish later.
Why Shopify POS alone was not enough
Native POS is excellent at cart and checkout. Specialty workflows often need extra state:
- prescription or specialty identifiers attached to the sale
- associate steps that must happen before tender
- handoff into an operations portal after the floor moment
- inventory and order visibility that spans Admin, POS, and internal tools
If you force all of that into cart attributes and hope, you get silent corruption. If you build a parallel app that ignores Shopify ids, you get reconciliation hell. The work was bridging both: POS for capture, app database for specialty domain, Shopify for commerce primitives.
What the floor experience had to do
A good specialty POS flow is ruthless about time:
- Associate opens the POS entry point without hunting menus
- Required specialty fields are captured with validation, not free-text chaos
- The sale remains tied to Shopify cart/order identity
- Failures show a recoverable message, not a blank modal
- After payment, operations can find the same work item in a portal
That sounds obvious. It is hard under network lag, partial API failures, and staff who will invent workarounds if your UI hesitates for three seconds.
Back-office companion was part of the same product
The POS app did not live alone. A back-office Admin experience (React, Polaris patterns, Node, MySQL) existed so staff could view and edit specialty-related orders that originated from POS. Floor capture without ops visibility is how tickets become archaeology.
Deploy-wise these were treated as real services: Docker images, CodeDeploy-style app specs, environment configs. Specialty retail cannot treat POS tooling like a weekend prototype.
Leadership lesson inside the build
The technical risk was only half the story. The other half was teaching:
- what belongs in POS UI vs API vs portal
- which failures are retryable
- how associates escalate when specialty data is incomplete
- how engineers change schema without breaking open tickets
Weekly sharing and pairing around this stack mattered more than another clever component. When only one engineer understood the specialty state machine, every POS incident became a page for that person.
What I would still build the same way
- Keep POS thin and fast
- Keep specialty domain rules server-side and explicit
- Give operations a portal that shares identity with POS
- Deploy POS companions with the same seriousness as storefront
- Document the happy path and the “cashier is stuck” path
Specialty POS is not a tile. It is a product surface on the money path. Build it like one, lead the team like one, and the floor stays calmer than the domain deserves.