01 · FLAGSHIP CASE STUDY · TESTING / STAGING
Ordo Systems
Making operational work easier to trust
Ordo Systems brings fuel records and trade plate workflows into one mobile workspace.
The project connects everyday operational tasks with the system decisions behind them: who can act, which record is authoritative, how work synchronises, and what the available evidence actually proves.
Testing / staging — not customer production
Testing / staging
iOS + Android test channels
Verified AS-IS · 30 Sep 2026
Ordo Systems brings fuel records and trade plate workflows into one mobile workspace.
02 · PROBLEM
Reliable records across people, devices and workflows
Fuel receipts and trade plate movements have different processes, but both need a consistent, attributable history.
The design challenge was to keep identity, permissions, synchronisation and reporting coherent across clients without allowing each interface to invent its own business rules. A pending action must also remain distinguishable from a confirmed server record.
03 · USERS, PAIN AND BUSINESS VALUE
Start with the people and the work
Operations users need to capture permitted records and understand what happened. Administrators need clear access boundaries and accountable history.
The intended value is clearer plate custody, more reliable records and less duplicated reconciliation work. Retry ambiguity, duplicate submissions and incomplete evidence become explicit system problems to address.
Operations users
Capture fuel evidence, borrow or return permitted trade plates, and understand pending, rejected and completed actions.
Organisation administrators
Manage people, departments and module access while preserving tenant-specific accountability.
Technical and support operators
Diagnose bounded technical signals without treating support access as unrestricted customer administration.
04 · MY ROLE
Connecting the problem to the whole system
I worked across problem framing, requirements, architecture, implementation, validation and documentation.
My focus was on the connections between workflow, data, authority and operations—not only the interface. I used AI development tools as part of a structured build–validate–stabilise workflow while retaining system-level decision making and quality control.
FOUNDER & SYSTEMS DESIGNER · 2026–PRESENT
05 · FROM PROBLEM TO ARCHITECTURE
Decisions follow the workflow
I work from the operational problem toward the technology, keeping each decision tied to a requirement or constraint.
For example, a trade plate return is a state transition with access rules, attribution and possible offline conflicts. That leads to an API-owned transition, scoped data and explicit reconciliation rather than relying on what the client currently displays.
Problem
Users
Pain
Business value
Requirements
Conflicts
Constraints
Processes
Data
Rules
Non-functional requirements
Architecture
Technology
Implementation
Operations
Evolution
06 · REQUIREMENTS AND CONSTRAINTS
Useful behaviour needs explicit boundaries
Shared product behaviour, authoritative server rules and honest offline states shaped the design.
• Keep Fuel Expenses and Trade Plates within one product while preserving each module’s domain rules.
• Enforce tenant, department, role and action scope in the API.
• Treat local drafts and queued work as pending until the server reconciles them.
• Store structured history with relational constraints and keep operational files private.
• Separate customer administration, technical diagnosis and support authority.
07 · HIGH-LEVEL AS-IS ARCHITECTURE
One authoritative backend, distinct responsibilities
iOS and Android clients share a modular API for authentication, permissions, Fuel, Trade Plates and Reporting.
The verified testing runtime uses PostgreSQL for structured records and private Cloudflare R2 object storage for files. The internal responsibility boxes describe one backend, not separately deployed microservices.
AS-IS mobile overview
• iOS and Android testing clients
• One modular API
• PostgreSQL records
• Private R2 files
• Bounded readiness evidence; client traffic unobserved
08 · ARCHITECTURE DECISIONS
Three decisions that keep the system coherent
Each choice addresses a concrete responsibility and carries an explicit trade-off.
PostgreSQL as the relational store
Reconstructed current decision
Tenant ownership, relationships, uniqueness and transactional state belong in a relational store. Typed constraints coexist with bounded JSONB payloads.
TRADE-OFF
The current collection-rewrite bridge is a scaling limitation. Targeted transactional SQL is an evolution option to validate through measurement.
Private object storage for operational images and files
Reconstructed current decision
Keep file bytes private while PostgreSQL holds ownership, lifecycle and integrity metadata. Authorise access through the API.
TRADE-OFF
Metadata and files can fail independently. Upload, cleanup and recovery must reconcile both stores.
A modular backend before microservices
Reconstructed current decision
Keep authorisation, domain transitions, idempotency and persistence behind one API while separating internal responsibilities.
TRADE-OFF
Preserve module boundaries and revisit service splitting only when measured scaling, ownership or release needs justify its operational cost.
09 · DATA MODEL / ERD
Model the records—and the relationships that actually exist
The focused model separates identity and organisation, operational records, and file/report evidence.
ERD mobile overview
• 13 selected tables of 41
• Identity and access
• Operational records
• Evidence and reporting
• 161 columns · 31 physical foreign keys · 27 drawn relationships
10 · PRODUCT INTERFACES
Interfaces shaped around operational responsibilities
The selected testing screens show the product’s navigation, capture options, plate workflow and administration surfaces.
MOBILE WORKSPACE
Ordo Systems brings fuel records and trade plate workflows into one mobile workspace.
CAPTURE-OPTIONS DETAIL
Ordo Systems offers barcode, photo and manual entry routes for fuel receipt capture.
TESTING STATE
Ordo Systems brings borrowing, returns and account-scoped plate status into one operational view.
ADMINISTRATION
Ordo Systems provides dedicated administration for organisations, people, module access and devices.
DISPLAYED SETTINGS
Ordo Systems displays account and device sign-in controls, including MFA, passcode and Face ID status.
11 · PORT.IO ARCHITECTURE CATALOGUE
Make responsibilities and evidence inspectable
The architecture catalogue records component identity, lifecycle, architecture state and the evidence behind each relationship.
This focused view centres on the API, its two mobile clients, four internal responsibilities and two data resources. It makes the model readable without adding unverified operational connections.
Port catalogue mobile overview
• 9 selected entities around the Ordo Systems API
• Manual descriptive catalogue
• Recorded relationships, not live traffic
12 · IMPLEMENTATION AND DELIVERY
Build, validate, stabilise—and retain the evidence
Shared contracts connect the mobile clients to API-owned rules, persistence and reporting.
I used AI development tools within a structured build–validate–stabilise workflow, retaining responsibility for system decisions and quality control. Implementation evidence is kept separate from deployed-version and mobile-release evidence.
• A shared web/Capacitor foundation packages the current iOS and Android clients.
• The testing backend and database have a verified deployed version and matching migration state.
• TestFlight and Google Play provide testing channels; they do not establish public production release.
13 · VERIFICATION
Architecture is not true because the diagram says so.
I treat source, configuration, runtime observations and release artifacts as different classes of evidence.
The 30 September 2026 checkpoint compared read-only testing database metadata with the expected product schema, reconciled migration checksums and recorded bounded provider/runtime observations. Stronger evidence improved specific claims without promoting every feature to live.
SELECTED-SCOPE VERIFICATION
13
selected tables
161
columns matched
31
physical FKs
20
applied migrations
14 · MOBILE PROVENANCE / EVIDENCE LIMITS
A test build is evidence—with limits
Testing distribution is established. The complete source-to-native-build chain is still incomplete.
Android
Partial
The uploaded artifact was recovered and all 18 prepared web assets corresponded to an immutable source revision. That improves component provenance; it does not prove the whole native-build source SHA.
iOS build 10
Unresolved
Provider build identity and distribution metadata were established. The original source/archive linkage remains unresolved, so no exact source SHA is claimed.
15 · WHAT IS NOT LIVE / INTENTIONALLY INACTIVE
Boundaries are part of the result
The portfolio distinguishes working evidence, retained capability and future intent.
• Customer production is not established; the business lifecycle is testing/staging.
• Push notifications are intentionally inactive as a product feature. Retained registration and transport/test capability is not active customer notification behaviour.
• Monthly-report email was disabled at the verified checkpoint.
• Foreground location capture remains gated off.
• Retool is paused; Jira and Sentry product wiring remain planned/not live.
• Device/hardware development is paused, and native-first V2 remains proposed.
16 · WHAT I LEARNED
The quality of the boundary matters
Reliable systems depend on making authority, state and uncertainty visible.
Local intent is not committed state
Offline convenience needs explicit pending states and server reconciliation, especially when another user can change the same record.
Metadata and files form one recovery problem
Separating bytes from records creates useful boundaries, but restore and cleanup must account for both.
Version evidence needs its own discipline
Source code, a running deployment and a signed mobile build can each be valid while representing different versions.
An honest gap is actionable
Recording what remains unproven creates a precise next step and keeps the architecture from becoming a claim stronger than its evidence.
17 · TARGET / V2
Evolve the constraints with evidence
The proposed direction retains authoritative API rules and improves client reliability, data access and operational control.
TARGET / PROPOSED
TARGET / PROPOSED
TARGET / PROPOSED mobile overview
• Native-first evaluation; no framework selected
• Authoritative API rules
• Targeted SQL where measured
• Recovery rehearsal
• Controlled operations
• All elements proposed
• Evaluate a native-first client direction through representative workflow prototypes; no framework is selected.
• Measure and replace hot collection rewrites with targeted transactional access where justified.
• Complete release provenance and keep testing and future customer-production boundaries explicit.
• Rehearse database/object recovery and define controlled support and observability responsibilities.
18 · WHAT THIS PROJECT DEMONSTRATES
A way of thinking across the system
Ordo Systems demonstrates how I connect operational needs with software structure, data rules and verification.
• Systems analysis that starts with actors, processes and authority.
• Data modelling that distinguishes enforced relationships from application rules.
• Architecture decisions explained through consequences and constraints.
• AI-assisted implementation with retained decision making and quality control.
• Evidence discipline that keeps current state, proposed state and unresolved questions separate.
19 · NEXT STEP
Let’s talk about useful, dependable systems
I’m interested in work at the intersection of AI systems, technical operations and systems analysis.
Explore how I work, read my resume, or get in touch to discuss the thinking behind Ordo Systems.
