Launched a field-service product in one quarter.
JobTrack is a lean field-service SaaS product covering job scheduling, technician mobile check-in, and a live dashboard of work in progress — built and shipped as a real, sellable product in twelve weeks of sprints rather than an internal prototype.
They didn't need an internal tool. They needed a product they could run on — and then sell.
The client ran a field-service business entirely on paper job sheets and phone calls. Scheduling lived in the owner's head, completed jobs were tracked by hand, and the moment a technician left the office, visibility was gone. They also saw a bigger opportunity: other operators had exactly the same problem.
A field-service operator ran their entire business on paper job sheets and phone calls — scheduling by memory, tracking completed jobs by hand, and losing all visibility the moment a technician left the office. That's workable with two technicians and one owner keeping track. It breaks down the moment a third technician joins, because there's no shared record of what's scheduled, what's done, or where anyone actually is.
A web and mobile front end handles scheduling and check-in, a multi-tenant database backs the platform, and a hosted backend serves both without per-customer infrastructure.
Jobs are created and assigned to a technician and time slot from the office dashboard.
Technicians update job status from the field on their phones — arrived, in progress, complete.
The office sees every job's status in real time, without a single phone call.
Each operator's data is isolated, so new customers can be onboarded without new infrastructure.
We scoped and shipped a real product, not a prototype:
Build single-tenant for the first customer and bolt on the rest later.
Multi-tenant from the first sprint, so the product could be sold.
The easy way to ship an MVP fast is to build it single-tenant for the first customer and worry about supporting others later — it's a smaller build and gets the first user live sooner. It also means rebuilding the data model later to bolt on multi-tenancy, which is a much bigger job once real customer data is already in the system. We built it multi-tenant from the first sprint instead, which added some upfront design work but meant the product could be sold to a second and third operator without a rebuild — the actual point of calling it a SaaS product.
Working software early, then the full build — with the client using it at every step.
We defined the smallest product that could replace paper completely, and designed the core flows.
Scheduling, mobile check-in and the live dashboard, shipped in short sprints the client used as we went.
Multi-tenant onboarding, polish and hardening for real customers.
Product live with first paying tenants, and code and infrastructure handed over.
Multi-tenancy costs a little up front and a lot to retrofit. Knowing it would be sold changed the first sprint.
Half-digital processes keep the paper alive. The MVP was scoped so the job sheet could be retired entirely.
Invoicing from completed jobs and customer notifications — the features the first tenants are asking for most.
Should we build our own platform or keep paying for an off-the-shelf one?
Our free tool answers it with your own figures — in your browser, no sign-up.
More on automation for field servicesPatient enquiries arrived around the clock but were only triaged once staff logged in.
A staffing firm's consultants spent mornings researching prospects instead of speaking to them.
Every return needed three back-and-forth emails before a label was issued.
We'll tell you whether it's worth automating, and what it would take. A founder or senior engineer replies within one working day.
