Specialty POS without a back-office companion creates a dangerous split brain: the floor thinks the order is done, operations cannot find the specialty details, and engineers debug from screenshots.

Alongside POS specialty capture, we built and evolved a back-office embedded admin app so staff could view and edit orders that originated from specialty POS flows. No client name. The build details matter.

What the back-office app was for

Associates and ops needed a Shopify-embedded style admin experience to:

  • list and open specialty-related orders
  • inspect the extra domain fields POS collected
  • edit order-adjacent state when reality changed after tender
  • reach settings that controlled how the specialty tools behaved

This was not a second storefront. It was the control room for work the POS started.

Stack that made it operable

The practical stack looked like a real product, because it was one:

  • React UI with Polaris-style admin patterns for familiarity inside Shopify Admin
  • Node/Koa APIs for authenticated app routes
  • MySQL for specialty persistence Shopify did not fully own
  • Sequelize migrations for schema evolution
  • AWS deploy packaging with environment-specific app specs and image definitions

If your specialty state lives only in browser memory or only in a spreadsheet, you do not have a system. You have a rumor.

The hard product problems

Shared identity

Every specialty record had to remain joinable to Shopify order identity. Lose that link and portals become haunted houses.

Edit safety

Ops edits after POS tender are necessary and dangerous. The app needed clear rules for what could change, what required a compensating action, and what should be read-only history.

Auth and install reality

Embedded apps fail in boring ways: bad callback URLs, stale sessions, wrong shop context, incomplete scopes. Specialty retail staff do not care about OAuth theory. They care that Dashboard, Orders, and Settings load.

Deploy seriousness

Multi-environment Docker deploys and migration discipline mattered because specialty order data is operationally sensitive. “Works on my ngrok” is not a release strategy.

How this connected to the wider platform

Back-office sat between:

  • POS specialty capture on the floor
  • associate portals for processing
  • webhook/cron systems keeping external truth moving

Teaching that map was leadership work. New engineers otherwise treated each repo as a separate product and shipped contradictions.

Leadership takeaway

If you invest in POS capture and skip back-office findability, you have only finished the customer-facing half of specialty retail. Build the control room. Document who owns edits. Make the order findable the next morning without paging the original author.

← Back to blog