Gaffer
From the first enquiry to the finished job.
An operations platform connecting customers, sites, jobs, quotes, invoices and field-service workflows.
Build something like this
Real product screen with demo data. Figures shown are illustrative, not project results.A business problem
worth solving.
Trade businesses coordinate people, customers, sites, paperwork and money while the work is happening away from a desk. A quote has to become a scheduled job; changes in the field need to reach the office; completion has to connect to an invoice. Gaffer brings that operational chain into one business-scoped platform.
The connected solution.
An API-first operations platform for service and trade businesses. The core covers customers, sites, jobs, quotes, invoices, messages, attachments and sync. Web and native clients use the same underlying business operations. Specialist trade workflows extend that foundation where the work needs additional records and evidence.
The decisions behind
the experience.
Business-scoped data boundaries and policy checks control access to operational records. Controllers delegate write orchestration to services, with domain events coordinating side effects. Access and refresh tokens support the client sessions. Sync contracts address stale writes and repeated uploads, while operational integrations use retry paths and recorded failure states.
The job is the connection between office and field.
Gaffer’s product model connects customers, sites, quotes, jobs, invoices and supporting evidence. Its architecture keeps business operations available through the API so the web interface and native clients consume the same rules. Specialist trade workflows can extend that common job model rather than bypassing it.
The specification has to account for more than a happy-path form submission: who may change the record, which business it belongs to, which states it may move between, and what should happen when a field client reconnects. Those requirements shape the service layer and the sync contract as much as the visible interface.
The right change, once, against the right version.
The implementation checks legal state transitions rather than accepting every requested status change. Sync uses an unmodified-since condition to identify a stale write, returning a conflict instead of allowing an older client to silently overwrite newer work. Attachment uploads use a client upload identity so a repeated upload can be recognised.
Integration failures are recorded for retry, with bounded attempts and backoff. Access and refresh-token lifecycles support web and native sessions, while business-scoped policies restrict which records an action can touch. This is operational engineering: making changes consistent even when people, devices and external services do not all respond at the same time.
Check the boundaries and the transitions.
The canonical implementation registry records targeted coverage for cross-business access, valid and invalid state transitions, integration failure contracts, sync conflicts and attachment replay handling. It separates built features from work requiring hardening or deeper workflow completion.
For a trade operations platform, these are meaningful validation questions: can another business access the record, can a job skip an invalid transition, can an interrupted upload be safely retried, and can an external failure be diagnosed? The documented checks examine those behaviours directly rather than relying on the appearance of the dashboard.
Where the detail matters.
One operational chain
Customers and sites connect to quotes, jobs and invoices so the office can follow the work through its lifecycle.
Web & field access
API-backed web and native clients, messages, attachments and synchronisation support work beyond the desk.
Workflow discipline
State transitions, access policies, business scoping and integration retries support dependable operational behaviour.
The experience behind the interface.
Binary Beach, part of TGF Digital, explores this build through its user journeys and product-design decisions.
Read the product experience study ↗Capability you can
put to work.
Demonstrates API-first engineering, operational product design, field workflows, permission boundaries and synchronisation contracts.

Another view of the product, using demo data.
Similar challenge?
Let’s make your version.
A field-service platform or bespoke operations tool that fits how your team works.
Discuss your project Explore the other builds