Replacing paper job sheets for a field-service company

The problem

Field engineers completed work and filled in a paper job sheet — parts used, hours, customer signature. Those sheets travelled back to the office in a van, where two administrators rekeyed them into an accounting package each evening. Invoicing lagged the work by a week, sheets went missing, and nobody could see the day’s status until it was already history.

The owner knew the process was costing money but could not describe the software that would fix it. That is the normal starting point, and it is exactly what a short discovery is for.

Constraints

• Engineers work in poor signal — the app had to work offline and sync later.
• The existing accounting package was staying; the new system had to feed it, not replace it.
• The administrators were sceptical of “another system”, having been burned before.

What we built

A mobile-first job-sheet application the engineers complete on a phone, plus a small office view for reconciliation. The smallest useful version served one primary user — the field engineer — properly, rather than serving everyone adequately. Parts, time and a captured signature go in on site; the record syncs when signal returns.

The office no longer rekeys anything. Completed jobs flow into a review queue, an administrator confirms them, and an approved job produces an invoice draft in the existing accounting package through its API.

Architecture

A modular monolith on ASP.NET Core with a PostgreSQL store, deployed to Azure. The mobile client is a Blazor application with an offline cache and a sync queue, chosen because the interaction is rich and the team is a Microsoft-stack shop. Integration with the accounting package sits behind a single adapter module, so a future change of package touches one boundary rather than the whole system.

We deliberately did not build scheduling, inventory, or a customer portal in release one. Those were written down as out of scope so that the first release could ship and be learned from while the cost of being wrong was still low.

How we delivered

Twelve weeks, in two-week iterations, with working software demonstrated every one. The administrators — the sceptical users — were in those demos from the second iteration, which is how a tool they expected to resent became one they helped shape.

Lessons

The binding constraint was never the engineers’ data entry; it was the evening rekeying and the week-long invoicing lag. Naming the real cost up front kept the first release small and focused on the thing that actually hurt, rather than on the longer feature list everyone could imagine.