A field measurement tool built around a specialist telecoms workflow
Final Measures was created to make as-built measurements easier to capture in the field and turn them into structured records that could support later commercial review.
Rather than forcing the process into a generic package, the application was shaped around the project references, measurement items and working practices used in the job.
Turn field activity into usable commercial data
Telecoms civils measurement work can involve project references, work items, quantities and commercial codes spread across several sources. Capturing the physical measure is only one part of the job; the information also needs to be recorded consistently enough to be reviewed and reconciled later.
Final Measures was developed around that operational gap: give the person in the field a focused interface, capture the required project context and create structured records rather than another disconnected note or spreadsheet.
A focused system around the actual workflow
Project setup
The workflow captures the project and operative context needed before measurements are recorded, including structured project-reference validation.
Measurement capture
Field measurements are entered against the relevant work item so the record has the context needed for later review rather than existing as an isolated quantity.
Commercial item matching
The application works with structured SOR / Bill of Measure information so measured activity can be associated with the appropriate commercial item.
Supabase data layer
Supabase was used as the central database layer for structured records, giving the application a practical backend without building a database service from scratch.
Resilient field use
The application includes local queueing and connectivity-aware behaviour so the field workflow is not designed around the assumption of a perfect connection at every location.
React and Vite at the front, Supabase behind it
The application was built as a React web app using Vite, with Supabase providing the central data service. The interface handles field setup, validation and measurement entry while the data layer stores the structured records needed by the wider process.
That separation kept the field interface focused while still giving the underlying information a consistent structure that could be used for later checking, comparison and final-account work.
A small piece of software designed around a very specific job
Final Measures demonstrates the kind of work Atinamos is interested in: understanding an awkward operational process, identifying the part that software can improve and building a focused tool around the people who actually have to use it.
Have a workflow that does not fit an off-the-shelf system?
We can look at what people are doing now, where the friction sits and whether a focused piece of software could make it simpler.