Five production systems on a proprietary multi-tenant platform.
Architecture, scale, and engineering trade-offs — the reasoning a
one-line résumé can only assert.
01 Reporting &
Sales-Aggregation Engine
Designed & built
Gave 250+ restaurant brands near-real-time sales insight.
Reports that previously ran against live transaction tables —
timing out and causing lock contention on the production
database — now return
a full year of data in under ~100ms. A
standalone .NET engine pre-aggregates the full tenant base
(338K+ workdays, 205M+ transaction line-items) into
purpose-built summary tables, moving analytical load off the
transactional path so reporting no longer competes with
order-taking. Incremental, trigger-driven resync keeps every
tenant current.
02 Payment System
Designed & built
Enabled the company to take online payments and onboard new
providers without a rebuild, on a design built for
money-correctness. Provider-agnostic, and
engineered for the ways payments fail in practice — concurrent
operations, timeouts, disputes, and out-of-order events —
resolved by background reconciliation against the provider, a
full audit trail, and database-level guarantees so partial
failures can't silently corrupt money.
03 Call Center Web App
Built end-to-end
The tool call-center agents use to take orders across multiple
restaurant brands from one screen — now handling
450K+ orders across multiple brands,
replacing an older system. Angular + .NET backend-for-frontend
that keeps auth tokens server-side so they never reach the
browser, multi-company sessions with PIN-based employee
identity, real-time updates, and full EN/AR RTL support.
04 White-Label Ordering Platform
Built end-to-end, incl. payments
A customer-facing ordering app where
one codebase serves many restaurants,
each with its own branding and menu. Angular + .NET
backend-for-frontend, a complete payment flow (card
save/verification, Apple Pay, refunds), and a customer
dispute-to-refund loop wired into the payment reconciliation
flow.
05 E-invoice Storage Offload (DB
→ S3)
Built
Kept the core database fast as invoice volume grew by moving
e-invoice storage out of SQL Server into AWS S3 —
migrating tens of millions of existing e-invoices
to object storage and taking heavy invoice blobs off the
transactional path.