School uniform commerce
A production-ready commerce platform for school uniform retailers. Already built. Already peak-tested at term-start. Configure it to your schools, your catalog, and your ERP – you don’t rebuild it from scratch.
11 weeks kickoff to live – not 11 months. Covers parent-child-school accounts, school-gated catalogs, sized uniform PDPs, ERP integration, fitting appointments, returns with coupon refunds, and term-aware delivery.
The platform is already built. Configure it to your business
Production code, proven architecture, battle-tested through a full back-to-school peak. Configure it against your schools, your catalog, and your back office – instead of spending 18 months discovering what uniform retail actually needs.
Eight modules that ship together
- 1Parent, child, and school as first-class entities
- 2Catalog access scoped to enrollment
- 3Products built around sizing, sets, and personalization
- 4Flexible ERP integration layer
- 5Fitting appointments built into the account
- 6Returns that kill phone calls, not create them
- 7Delivery rules that respect the school calendar
- 8Commerce baseline, done right from day one
What you get on day one
- Live in
- 11 weeks · kickoff to production
- Connects to
- REST · GraphQL · SOAP · webhooks · message queues · SFTP · CSV
- ERP-ready
- SAP · Navision · Odoo · NetSuite · custom
- Sign-in
- SSO · SAML · OIDC · email + password
- Term-start
- Battle-tested through a full back-to-school peak
- You keep
- Runbooks · architecture docs · admin training
Live in 11 weeks. Configured to your schools and your ERP, not built from scratch.
Start the acceleratorGeneric commerce platforms weren’t built for uniform retailers
Uniform retail is not fashion retail. A parent buys for three children across two schools, each with its own catalog, grades, sizing rules, and calendar. The ERP owns pricing and inventory. Fittings are seasonal and in-person. Every uniform retailer we speak to recognises all three problems below.
Your developer is retiring
Half the uniform retailers we speak to run on a platform built by one freelancer a decade ago. When that person stops picking up the phone, everything breaks. The business case writes itself.
Multiple sources of truth
A custom admin for the website. The ERP for everything else. Staff manually key in the same data twice. When syntax does not match, orders sit in the exception pool and a human has to unblock them.
One account, many children, many schools
A parent buys for multiple children across multiple schools. Each child has their own catalog, grade, gender, and personalization. Default customer models treat them as one context.
Seasonal by design
Fitting appointments, name tape personalization, deferred term-start delivery, international-student flows. None of this ships as default in Shopify, Magento, or BigCommerce.
We have 125 schools under contract. Someone could spend a million dollars on SEO and they still wouldn’t sell anything to our customers, because our customers can only buy from us.
The parent, child, and school are three separate entities. So is the architecture
Every feature in this stack flows from one modeling decision. Treat the parent, each child, and each school as distinct, linked entities. Generic platforms get this wrong. It is what makes every downstream feature work.
Multi-child account
parentsOne parent manages many childs across many schools. Each child has their own grade, school, and personalisation. The child switcher drives cart, catalog, and context.
School-gated catalog
productsProducts scoped to schools, campuses, and grades. Parents only see what the selected child is authorised for. Guests see limited views with prices hidden.
Operational integration layer
adaptersReal-time bidirectional sync with the ERP. Fallback cron jobs, retry logic, and audit logs built in from day one.
Eight modules. All in production.
Every module is live today on Canada’s leading school uniform provider. Not concepts. Not roadmap. Configure them against your schools, your catalog, and your back office – that’s the project.
One account. Many children. Many schools.
A custom child entity linked to the customer and the school. Parents manage multiple child profiles, each with its own attributes. A header-level child switcher changes the cart, the catalog, and the context.
- Child profiles with name, DOB, gender incl. non-binary, grade, and name tape (20-char embroidery limit)
- Customer → Child → School relational data model, one parent to many children to many schools
- Header child switcher with auto cart-clear – prevents grade-9 kilts landing in a grade-2 cart
- Multi-child registration in one flow, with International Student and Returning Family flags
- School entity with Campus sub-entity for multi-location schools (junior + senior, north + south)
Parents only see what their child is authorised for
Each school is a category with its own catalog, grade ranges, gender rules, and language setting. Parents only see what their selected child is authorized to buy. Guests see restricted views with prices hidden.
- PLP gating by enrollment, grade, and gender – a grade-3 girl never sees grade-11 boys' blazers
- Guest mode: catalog browsable, prices and add-to-cart hidden until login + child selected
- Per-school flags: French Immersion, International Baccalaureate, Closed/Merged, New School (first-year onboarding)
- Grades as a managed entity, mapped to schools and SKUs (JK-12, plus alumni)
- Per-school pricing on shared SKUs – same polo, different price at private vs parish school
Uniform shopping is not fashion shopping
Uniform shopping is sizing accuracy, full-uniform bundles, sizing videos, name tape add-ons, and shopping lists by grade. The product model and PDP reflect that – not a generic apparel template forced to fit.
- Uniform taxonomy with sizing chart, fit notes (slim · regular · husky), and shopping-list attributes
- Bundle products for full-uniform sets at package pricing – one click, full kit by grade
- Configurable products with size + colour, single-colour preselect when the school only allows one
- Name tape & crest embroidery as add-ons, with a “no returns on customized” flag enforced at checkout
- PDP sizing video and per-product care/wash instructions, surfaced inline not buried in tabs
Connects to your back office. Not the other way around.
Products, customers, orders, and returns flow bidirectionally between your storefront and whatever runs your back office – ERP, WMS, POS, PIM, OMS, 3PL. Pick the right protocol per data type, not one stack for everything.
- Protocol-agnostic adapters: REST, GraphQL, SOAP, webhooks, Kafka/SQS, SFTP/CSV, EDI – mix per integration, not per project
- Bidirectional real-time sync for products, media, stock, customers, orders, returns – all flowing both ways
- CSV/SFTP kept where it belongs: seasonal bulk price updates, vendor catalog drops, anywhere a buyer refuses to retype 3,000 SKUs in a UI
- Fallback cron jobs, retry queue, and dead-letter logger – no silent back-office outages eating orders
- Exception pool in admin: mismatched SKUs and failed syncs surface for review, not lost in a log file
- Single-school cart rule respects one-school-per-order constraints downstream, enforced at add-to-cart
- Adapter pattern extends to NetSuite, SAP B1, MS Dynamics, Odoo, custom WMS, and in-house systems
Integration adapters
REFERENCE BUILD- Protocols
- REST · GraphQL · SOAP · webhooks · Kafka/SQS · SFTP/CSV · EDI
- Direction
- Bidirectional, real-time
- Entities
- Products · media · stock · customers · orders · returns
- Resilience
- Cron fallback · retry queue · dead-letter logger
- Admin tooling
- Exception pool for mismatched SKUs and failed syncs
- Proven against
- NetSuite · SAP B1 · MS Dynamics · Odoo · custom WMS
Parents book fittings. Per child, per school, from My Account.
Parents book fittings per child, per school, directly from My Account. Admin manages capacity by fitter count and slot duration. Reminders drop no-shows. No third-party SaaS stacked on top.
- Parent-facing booking flow from My Account – pick child, school, fitter, and slot in under a minute
- Admin UI for fitting periods, room/fitter rosters, slot length, and a live bookings grid by day
- Capacity = fitters × slot duration, configured separately for new vs returning students (new = longer slots)
- Reminder cadence: instant confirmation, 24h email, 6h email, plus optional SMS reminders – cuts no-shows
- Printable daily run-sheets per school per day, plus CSV export for the fitting room iPad
A return cycle that runs in minutes, not days
Customer files the return from My Account. Admin approves. The ERP triggers the refund. A one-time coupon is auto-generated and emailed. Entire cycle is visible in the customer profile.
- Self-serve returns form in My Account – reason codes, RMA number, prepaid label, no phone tag
- Admin returns workspace with status pipeline (Requested → Approved → Received → Refunded) and SLA timers
- ERP-triggered refund reflected as a credit memo on the storefront, so finance and storefront agree on the cent
- Auto-issued store credit coupon emailed on approval – keeps the dollar in the store, parent-friendly
- “Custom embroidery is final sale” rule enforced automatically; defective embroidery still refunds
- Full return history on the customer profile, searchable by support so the next call resolves in 30 seconds
Returns flow
ERP-NATIVE- 1 · Filed
- Parent files in My Account · reason code + RMA · prepaid label
- 2 · Approved
- Admin reviews in returns workspace · SLA timer running
- 3 · Received
- Warehouse receives + scans · status updates parent automatically
- 4 · Refunded
- ERP triggers refund · credit memo issued on storefront
- 5 · Coupon
- One-time store credit auto-emailed to parent
- 6 · History
- Full return record on customer profile · searchable by support
Three delivery methods. Per-school. Term-aware.
Three delivery methods, per-school configuration, a seasonal “when to deliver” window, and an International Student flow. The logic parents expect, without custom work for every school.
- Three delivery methods: Pick up in store, Home Delivery, Ship to School (consolidated drop, term start)
- Per-school shipping rates and free-delivery date ranges – back-to-school free, off-peak charged
- Seasonal “when to deliver” window (e.g. Apr 1 – May 31, configurable): Deliver Now vs Hold for Term Start
- International Student flow: hidden home address, billing only, ship-to-school enforced
- “New School” toggle suppresses the seasonal window for first-year openings – orders ship immediately
- Closed-school grace period: alumni can still order PE kit and crests for a configurable window
Delivery configuration
PER-SCHOOL · TERM-AWARE- Method 1
- Pick up in store
- Method 2
- Home Delivery
- Method 3
- Ship to School · consolidated drop · term start
- Free window
- Configurable per school · back-to-school free, off-peak charged
- Hold window
- “Deliver Now” vs “Hold for Term Start”
- Edge cases
- International Student · New School · Closed-school alumni grace
The unglamorous foundation – included, not billable
The custom work goes only where uniform retail actually needs it. Performance, observability, deployment, and handover are built in – so day-one issues never reach the customer and your team owns the stack from day one.
- Mobile Lighthouse 90+ at launch – tested under term-start traffic, not on a blank dev environment
- Only the proven extensions ship – no plugin bloat, no surprise renewals
- GA4, GTM, and server-side observability wired before launch – term-start traffic spikes don't blindside ops
- CI/CD with environment parity (dev → stage → prod), one-command deploys, automated DB sanitization
- Documented handover: your team owns the code, the runbook, and the on-call – not us, not a hostage agency
Cut a year off your roadmap. Start with the workflow costing you the most.
Start the acceleratorLive in production. Canada.
A family-owned uniform retailer serving ~200 Canadian schools since 1986 from its Montreal base. They came to scandiweb with three fires burning at once: a legacy platform hand-built by a single freelance developer about to retire, an ERP running on 30-minute CSV dumps, and a hard term-start deadline.
A legacy platform built by one person
Custom admin, single-developer codebase, a decade old, the developer about to retire. Downtime risk compounding every term-start.
ERP running on 30-minute CSV dumps
Pricing and inventory in the ERP. Catalog on the website. Two sources of truth, syncing every half hour, with manual exception handling on every mismatch.
A hard term-start deadline
Back-to-school is the peak. Every parent buys, every school turns over, every system gets hammered at once. The old stack barely survived the previous one.
These modules sit on top of your existing commerce platform. Not instead of it. You keep everything commerce already does well. You get the parts that uniform retail needs to operate.
Skip the discovery year
Multi-child accounts, school-gated catalogs, sized uniform sets, term-aware delivery, ERP-triggered returns – already built. You inherit the proven stack, configured to your schools and your back office.
- Agency learns what a school-gated catalog is on your budget
- Customer model built from first principles, multi-child structure discovered late
- Sizing, sets, and personalisation invented per project
- ERP integration patterns negotiated stack by stack
- Term-start edge cases discovered in your environment, during peak
- Multi-child account, school-gated catalog, sizing and sets – already in production
- Customer model designed for parent-child-school from day one
- Term-start tested through a full back-to-school peak · zero incidents
- Fitting appointments, returns with coupon refunds, term-aware delivery – included
- ERP adapters extend to SAP, Navision, NetSuite, Odoo, custom
Eight modules in production from day one – saving you a year of build time.
Start the acceleratorTestimonials
“This was the smoothest go-live of my entire life.”
“First 5 transactions processed by 10:50am ET. Call volume already settled down by 11am.”
“We are no longer dinosaurs. Customers are getting emails. It’s everywhere. Customer service is loving it because it saves so many phone calls.”
Start with the one workflow that costs you the most
Diagnostic sprint
We map your schools, your catalog, your ERP, and your delivery rules. Identify the single highest-cost workflow. You get a phased plan, including where the accelerator does not apply.
Pilot to production
Eight modules configured against your environment, your ERP, your schools. Term-start aware schedule. No big-bang risk. Measurable launch by the end of the pilot.
Scaled rollout
Extend across regions, brands, or adjacent workflows. Each phase funded by what the previous proved. Legacy stays live throughout.
You own the stack after launch
The engagement hands over everything your team needs to run the stack on its own – code, documentation, runbooks, training. No black box, no vendor lock-in, no post-launch silence.
- 1
Migration plan
Scripted cutover from your legacy systems. Dry-run tested. Zero-downtime fallback.
DOC - 2
Architecture documentation
System diagram, data model, integration adapters, auth flows. Versioned with the code.
DOC - 3
Runbooks
Peak-season ops, recovery procedures, known-issue registry. Written for your on-call team.
DOC - 4
Admin training
Three-session handover covering portal, exports, ID cards, SSO, and audit access.
SESSION - 5
30-day post-launch
Joint on-call with your team through the first peak window. Fix-forward, not hand-off-and-disappear.
SUPPORT
Code, docs, training, post-launch on-call. The whole package.
Start the acceleratorThe questions that actually come up
What is the tech stack, and can it be adjusted?
Does it work outside the school uniform vertical?
What if we have hundreds of schools and tens of thousands of SKUs?
Will it work for our market and language?
What does an eleven-week kickoff-to-launch actually cover?
What if our ERP is SAP, Navision, or something else?
What happens to our existing customers, orders, and data?
Who owns the code after launch?
Who runs it after launch?
Can we see a live demo before committing?
See if the accelerator fits your business
Thirty minutes. We map your stack, find your highest-friction workflow, and tell you whether the accelerator fits. If it does not, we will say so.
“The hard parts of uniform commerce are already solved – multi-child accounts, school-gated catalogs, ERP fallbacks, term-start traffic. You configure them to your stack in 11 weeks.”
- Response within one business day
- 30 minutes · fit assessment, no sales pitch
- Full reference case study on request
- If we are not the right fit, we will tell you
We respond within one business day.
