WK Selected work
Two platforms, both still running.
We would rather show two products we built and still operate than a wall of logos. Both are live, in daily use, and maintained by the team that wrote them.
/ Built on
02 Case study / Business platform
myEzData
A multi-tenant retail operations platform. One system covering commissions, payroll, scheduling, support, and reporting for a distributed network of stores.
The problem
Multi-location retail operations run on numbers that arrive from several systems that were never designed to agree. Sales come from point of sale. Commissions come from a carrier settlement feed. Hours come from a workforce scheduling provider. Each one uses its own identifiers, its own periods, and its own idea of what counts.
The result is a monthly reconciliation done by hand, disputes that cannot be settled because nobody can show their working, and managers making staffing decisions from numbers that are already a week old.
What we built
A single platform that ingests all of those feeds, reconciles them against one another, and becomes the system of record. Each business on the platform gets isolated data with its own branding, its own module set, and its own permission structure.
On top of the reconciled data sit the things the operation actually needs day to day: commission calculation with lock and approve controls, chargeback detection with a documented priority order, payroll with rate history, scheduling with a time clock, a support desk, a form builder with electronic signature, and dashboards for each level of management.
Notable engineering
Tenants are separated at the database level rather than by a column filter, so one customer's data cannot leak into another's through a forgotten query. Sensitive tables are additionally namespaced per tenant.
Staff sign in through Microsoft Entra ID, with one registered redirect URI serving every tenant subdomain. Outbound mail goes through the Microsoft Graph API so replies come from the real mailbox, and inbound mail is parsed back onto the ticket it belongs to. Uploads sit in Cloudflare R2 on tenant-scoped paths, and billing runs on Stripe reconciled against webhooks.
Partner integrations use HMAC-signed request authentication against staging and production environments, poll on a schedule, and report a received count on every run so a partial failure surfaces immediately instead of quietly under-reporting.
Money paths are treated differently from everything else. Once a commission period is locked and paid, the records are immutable and any recalculation must filter locked periods out before it runs.
Operations
Commission engines, chargeback detection and dispute handling, payroll import and rate history, scheduling with clock-in, and contest and bonus programmes.
Support and records
A ticketing system with service level tracking and separate internal and external conversation lanes, an inbound and outbound email pipeline, document storage behind authentication, and a form builder with electronic signature.
Insight
Period comparison, ranked performance tables, forecasting, a report builder, and dashboards scoped to what each role is allowed to see.
Reach
A staff web application, a self-service portal, and a mobile client shipped to the Apple App Store and Google Play, backed by a versioned API, one FCM v1 push pipeline reaching both platforms at parity, and device trust so a lost handset can be revoked.
03 Case study / Consumer mobile
Collectors Camp
A sticker album collecting app for the 2026 World Cup. A cross-platform mobile client on top of a backend we designed, built, and host.
The problem
Sticker album collecting is a social activity that had no good digital home. Collectors track what they own on paper, work out their duplicates by hand, and arrange swaps through group chats where the same sticker gets promised to three people.
What we built
A mobile application where collectors track the album, see their duplicates and missing stickers computed for them, find people holding what they need, arrange trades, and meet up safely to complete them. Around that sits a community layer with boards, reactions, and realtime chat.
The backend is ours end to end: the versioned mobile API, authentication including sign-in with Google, Apple, Facebook and Discord, realtime message delivery over websockets, push notifications, moderation tooling, in-app account deletion, and the scheduled collection that keeps album and player data current.
It is a deliberately different shape of product from myEzData, and it is on this page for that reason. Consumer mobile has different constraints from business platform work: app store review, social login, abuse handling, and a user base that will not read instructions.
Notable engineering
Trading is the hard part. Matching people by what they hold against what they need, keeping offers consistent when several are in flight, and making the handover safe are product problems as much as engineering ones.
Realtime chat runs on private per-conversation channels so message delivery is scoped to participants rather than filtered on the client.
04 Confidentiality
What we
leave out.
The descriptions above are deliberately about system shape and outcomes. We do not publish our customers' data, the names of businesses operating on platforms we built, internal schemas, or anything that would help someone attack a system we are responsible for.
If you are evaluating us and need more depth, we will walk you through architecture, code, and running systems directly under an appropriate agreement.
Ask us for detail