The server owns the transaction state machine
Clients can request valid actions, but cannot decide that funds were secured, delivery was accepted, or a dispute was resolved. Central ownership keeps every surface aligned.
Loading portfolio
Product and backend / Current
XcroTrust
Peer-to-peer transactions need an agreed record, understandable milestones, identity and payment checks, delivery proof, disputes, notifications, and support intervention without any client becoming the authority over a financial outcome.
I implemented the website, mobile app, API, and operations dashboard from designs supplied by another team. The engineering centres on a controlled escrow state model, provider reconciliation, transaction history, dispute handling, clear consumer-versus-operator boundaries, and consistent contracts across every surface.
- Role
- Website, admin dashboard, backend, and mobile engineering
- For
- DZND LTD
- Stage
- Pre-launch
Walkthrough
Watch it run
The website's clickable recreation of the app, played from both sides: the buyer creates a lock, the seller accepts, the buyer funds it, delivery starts inspection, then the sale ends in release or a dispute. Recorded on a local build with fictional people and funds.
My part
What I built
- Translated supplied designs into responsive web, mobile, and administrative interfaces without claiming design authorship.
- Built shared transaction language so users, operators, notifications, and reports present consistent status and next actions.
- Implemented agreement, funding, delivery, confirmation, cancellation, dispute, review, and support workflows.
- Integrated external payment, identity, storage, communication, and notification services behind internal boundaries.
- Developed operations tooling for review, intervention, disputes, reporting, user oversight, and launch administration.
- Built an interactive recreation of the mobile app for the website, so a visitor can play buyer and seller through a full escrow before installing anything.
Decisions
The choices that shaped it
Money is represented for repeatability
Currency calculations avoid ambiguous floating-point behaviour and derive user-facing totals from the same rules used by transaction processing.
Provider events are reconciled
A callback is one signal in the lifecycle. Provider context is compared with internal state before a sensitive change is applied.
Operations are a separate trust boundary
Support staff need capabilities consumers should never inherit. Operational actions are isolated, permissioned, and recorded.
What has been shown to work
- Exercised buyer, seller, and operator journeys across the full transaction lifecycle.
- Checked repeated provider events and stale-client requests against server-owned transition rules.
- Validated consumer-versus-operator role separation.
- Tested messaging, notification, and support histories across web and mobile.
- Reviewed error and retry behaviour so provider or network failure does not invent a financial result.
- The website's interactive app preview runs on a tested reducer that refuses wrong-participant actions and terminal replays, with amounts handled in integer kobo. It is live at xcrotrust.com/demo.
Current stage and limits
- The website, mobile app, backend and operations dashboard are substantially complete, but the product is not presented here as publicly launched.
- Store release of the mobile app depends on business verification and developer-account requirements that are still being completed.
Screens
From the product
Phone screens
At phone size
Technical detailOpen the system view
SYSTEM ARCHITECTURE
XcroTrust system view
I implemented the website, mobile app, API, and operations dashboard from designs supplied by another team. The engineering centres on a controlled escrow state model, provider reconciliation, transaction history, dispute handling, clear consumer-versus-operator boundaries, and consistent contracts across every surface.A modular TypeScript workspace separates public web, mobile, backend, operations, and shared domain contracts.
The backend owns escrow transitions, payment-adjacent decisions, timeout behaviour, and operational intervention; clients render state and request authorised actions.
Financial values use integer-safe handling and repeatable summaries rather than floating-point UI calculations.
Provider adapters isolate external services from core transaction rules.
External callbacks are reconciled with internal state before sensitive outcomes change.
- 01Input / actorconnects toInterface
- 02Interfaceconnects toCore service
- 03Core serviceconnects toOperational boundary
- 04Operational boundaryconnects toState / outcome
Security and privacy
- The case study excludes internal routes, schemas, credentials, prompts, provider configuration, thresholds, and operating runbooks.
- Customer records, unpublished commercial terms, and launch-sensitive implementation details are not used as portfolio material.
Built with
Links
More work
eventOSA live ticketing and event operations platform covering public discovery, ticket sales, organiser tools, payouts, offline door scanning and a headless API that other websites use to sell tickets.Live in productionNutrifluxA Nigerian-first nutrition mobile app and API combining deterministic health state, structured AI planning, offline-resilient writes, social features, reminders, observability and review-gated safety controls.Pre-launchKilogbede RecordsDesigned and built Kilogbede Records' production platform across the public label site, roster and release storytelling, media infrastructure, events, commerce connections, and a purpose-built operational CMS.Live in production