Specialty retail does not end when POS tenders. Someone still has to process specialty orders, reconcile inventory, export data, cancel stale pending work, and keep storefront events honest. Around the POS work I described elsewhere, we built and maintained that operations layer.
No client names. Just the system.
The pieces that made up the operating system
1. Associate portal (Next.js + Lambda APIs)
Associates needed an internal portal to process specialty orders after floor capture. This was not a theme page. It was a Next.js frontend talking to Lambda-backed APIs, deployed with the same multi-region style image definitions as the other services.
What it had to do well:
- find the specialty work item by stable ids
- show enough order context to act without guessing
- apply processing steps that POS should not attempt mid-line
- fail in a way support can explain
Portals fail when they are treated as “just UI.” The product is the workflow state machine behind the buttons.
2. Back-office admin for order visibility
A back-office Shopify-embedded style app existed so staff could view and edit orders tied to POS specialty flows. Polaris/React on the front, Node/Koa-style APIs, MySQL, migrations. The point was continuity: floor → ops → Admin without three conflicting truths.
3. Express webhook platform
Storefront and POS reality changes through events. We ran a Node/Express webhook platform whose job was to receive, acknowledge, and route Shopify-related events into the domain tools that needed them.
Webhook platforms look trivial until you pay the real costs:
- duplicate deliveries
- out-of-order events
- slow downstream handlers
- signature verification and environment split
- “we processed it” vs “Shopify thinks we failed”
The platform had to be boring and observable. Boring is a feature.
4. Cron fleet for work Shopify will not do for you
Cron suites covered the unglamorous backbone:
- back-office maintenance jobs
- cancel-pending flows for stale specialty work
- CSV export jobs
- FTP exchange jobs
- portal-oriented sync jobs in staging and production flavors
If you only build event-driven paths, you still need scheduled truth-tellers. Crons are where teams either become disciplined or quietly corrupt data overnight.
5. Inventory and admin API companions
Inventory POS companions and admin API services sat beside the same domain so stock and administrative mutations did not depend on one overloaded monolith route. Specialty retail inventory mistakes are not cosmetic. They become customer trust problems.
What “built” meant day to day
This was not a single repo hero story. It was a portfolio of deployables:
- Docker images and app specs per environment
- east/west style deployment definitions where needed
- MySQL schemas with migrations
- Next.js and Node services with clear owners
- runbooks for which job or portal owned which failure
Leadership work was keeping that map teachable. New engineers should not need six months of Slack archaeology to know whether a missing specialty order is a POS bug, a portal bug, a webhook miss, or a cron that did not run.
Failure modes that taught us the most
- Portal and POS disagree on identity → duplicate specialty records
- Webhook succeeds locally, downstream write fails → Shopify retries, you double-apply
- Cron assumes perfect upstream CSV → corrupt exports look like “successful jobs”
- Only one engineer knows cancel-pending rules → vacation becomes an outage
Every one of those is both an engineering fix and a teaching fix.
Leadership takeaway
Specialty commerce platforms grow when the operating system is explicit: portals for humans, webhooks for events, crons for scheduled truth, POS for capture. They stall when that system lives in one brain.
Build the pieces. Name the owners. Share the map weekly. That is how the company scales past the first specialty launch.