There’s a version of OutSystems delivery that looks like this: a team gets a spec, builds the screens, ships it, moves on. Clean, fast, forgettable.
That’s not what enterprise operational software looks like in practice.
We’ve spent the last few years building on New Zealand’s largest OutSystems platform — a system used by over 10,000 people daily, powering operations for companies including McDonald’s NZ. What we built wasn’t a prototype or an internal tool. It was production-grade operational software that restaurant teams depend on every single day. Stock gets counted, deliveries get reconciled, sales data gets exported to global systems — all of it running on OutSystems O11, all of it built to survive the messiness of real operations.
Here’s what that actually looks like.
The work
We delivered four interconnected workstreams across a live multi-restaurant estate.
Stock control. The problem sounds simple: track what you use versus what you should have used. In practice it means building a consumption pipeline that runs nightly, takes product sales data, traces it back through recipes to raw ingredients, and produces a variance figure per item per restaurant. The pipeline needs to be idempotent — safe to rerun under any failure condition without double-counting. It needs to scope correctly across a multi-tenant estate. And it needs to produce a view that an operations manager can actually act on the next morning.
Delivery management. Every supplier delivery needs to be tracked, edited, audited, and — critically — reversible. State machines, full audit trails, rollback-safe stock movements. The kind of system where nothing gets lost and everything is traceable, because in a food service environment traceability isn’t optional.
Datahub exports. McDonald’s NZ feeds daily operational data into a centralised global system. Cash sheets, quarter-hour brand sales, bank deposits — all formatted to specification, all scheduled, all production-grade. One detail worth mentioning: missing time slots in quarter-hour data need explicit zeros, not nulls. Downstream systems treat them differently. We built the gap-fill in from day one because we understood what the data was actually for.
KPI and sales reporting. Multi-view dashboards for accounting and operations teams, with day-part breakdowns, role-based access, and country-specific defaults. Three reporting views switchable without a page reload. One data fetch, no unnecessary round trips.
What makes this kind of work different
Anyone can build a screen in OutSystems. The harder skill — the one that actually matters at enterprise scale — is understanding what you’re building before you build it.
The stock variance system isn’t a software problem. It’s a business problem about shrinkage, supplier accountability, and operational visibility. You can’t design the consumption pipeline correctly until you understand why the variance number matters to the person reading it at 7am before a shift starts.
The delivery management system isn’t a CRUD app. It’s a trust system. Every state transition, every audit record, every rollback exists because someone needs to be able to answer “what happened to this delivery” six months later.
That translation — from business need to technical design to shipped software — is what separates delivery that compounds from delivery that creates debt.
What we’ve learned building at this scale
Design for failure first. Idempotent pipelines, rollback-safe operations, explicit zero-filling — these aren’t edge cases. In live operational systems they’re day one requirements. The question isn’t whether something will fail. It’s whether the system recovers cleanly when it does.
Multi-tenant architecture is a constraint, not an afterthought. When your system runs across dozens of restaurants, every query, every aggregate, every scheduled job needs to scope correctly. Getting this wrong early means expensive refactoring later. Getting it right means the system scales without rearchitecting.
The data layer is where OutSystems projects succeed or fail. Most O11 delivery problems we’ve seen — performance issues, incorrect aggregates, reporting that doesn’t match reality — trace back to decisions made in the data layer. Window functions, proper scoping, understanding how O11 translates queries to SQL — this is where the work actually happens.
Documented delivery beats heroic delivery. Production software trusted by 10,000+ daily users doesn’t get there on the back of one person. It gets there through repeatable processes, clear architectural decisions, and a team that understands the why behind what they’re building.
Why we’re writing this
We’re a boutique OutSystems O11 consultancy. We work with enterprise clients who need software that actually ships and actually works — not demos, not prototypes, not projects that need rebuilding in 18 months.
If you’re building on OutSystems O11 and you need a team that has done this before — at scale, in production, for clients where failure isn’t an option — we’d like to talk.