Mobile mechanic software for the van, not the bay.

Mobile mechanic software runs a van-based repair business from one phone. It takes bookings and missed calls, builds quotes at the car with photos, orders the day stops by route, tracks parts on the van, and takes payment before you leave. The job card is only the first step. The system has to carry the same job from the first call through the repair, the invoice, and the payment without anyone retyping it.

Auto repair shop software assumes a building: a counter, bays, a waiting room, and a car that stays put. A mobile mechanic has none of those. The work happens in a driveway or a car park, the mechanic does the counter job and the repair job from the same phone, and the van is the parts store. Route-ordered stops, quote at the car, parts on the van, and pay before you leave are the mobile workflow, and shop software does not cover them.

Yes, when dispatch and invoicing are the whole job. Jobber and Housecall Pro run scheduling, quotes, and payments well, and Shopmonkey runs shop work orders well. What none of them do is run the van as one record. A quote built at the car with photos on each line, parts tracked on the van rather than in a shop store, labour times pulled into the job, route-ordered stops, and payment taken before you leave still live across separate tools. If that gap is where your day breaks, a general tool alone will not fix it.

The quote is priced off your own labour rate and your real parts cost, with photos on each line. The customer sees it on their own phone, taps yes, and signs, and the time of the agreement is kept on the job. The invoice comes from the approved quote, so the price the customer agreed is the price they pay, and nothing is rebuilt from memory at the end of the day.

A missed call gets a text back with a booking link, so the customer can describe the car and the problem and pick a time without waiting for a callback. The call, the text, and the booking land on the same record, so the job is not lost by eight and nobody has to remember a voicemail. After-hours calls are the jobs a mobile mechanic loses most, and they are the cheapest ones to catch.

The day is ordered by route, not by the order the calls came in. Each stop carries the car, the job, the parts needed, and the time window, and the map shows the way there. A new urgent job slots into the route where it costs the least driving, and the rest of the day reorders around it. The driver sees the next stop, not a list to sort by hand.

The van carries its own stock list, and each job pulls its parts from that list. Your counter comes first, not whatever is cheapest online, and the job records which supplier each part came from. When a part runs low, the reorder is raised from the van record, so the next job is not promised a part the van does not hold.

The invoice is built from the approved quote, and the customer pays by card on site, by payment link, or by tap before the van leaves. The job only closes when payment lands, so there is no end-of-week chase for invoices. A deposit can be taken at booking for bigger jobs, and the balance is collected at the car.

Yes. Labour guides open from inside the job, from your own account with the repair information service you already use. The quote can carry the labour time the guide gives, so the price is built on a number you can defend. We do not resell repair information; your own subscription stays yours, and the system links to it.

Yes. The job card, the quote, and the inspection run on the phone with no signal, and everything syncs when the van is back in coverage. Photos, signatures, and payments queue on the device, so a driveway with no bars does not stop the job. Nothing is lost if the phone dies mid-job; the record is on the device and in the cloud.

Mileage and time are recorded per job, from the route and the job card. The day shows driving time against working time, and each job carries its own mileage, so the books and the tax record agree at the end of the month. Paying the techs comes from the same record: jobs closed, time spent, and parts used, without a separate spreadsheet.

Each customer keeps a vehicle record with the service history, the last quote, and the parts fitted. A fleet account groups several vehicles under one company with one invoice. Repeat customers book faster because the car, the plates, and the history are already on file, and the next quote starts from what was done last time.

Buy an existing product when it handles your workflow with reasonable setup and its pricing makes sense. Build custom when the way you work is itself the advantage, when repeated manual work has a measurable cost, or when a critical connection to your other systems cannot be done cleanly any other way. If the rules of the operation are still changing every week, wait and settle them first.

For a small, well-defined task with someone technical managing it, freelancers are often cheaper. The pattern that goes wrong is a non-technical buyer coordinating several freelancers becoming the project manager, the tester, and the person who discovers the pieces do not fit. A development company earns its fee when the work needs coordination across quotes, parts, routes, and payments: one accountable party, one phase price, and checkpoints against the whole van day. If your need is one screen or one fix, hire the freelancer.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how deep the van day goes, how many kinds of users it serves, what it needs to connect to, whether data needs moving over, whether van tablets are involved, any record requirements, and the condition of existing code. The agreed phase is priced in writing before it starts.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a system covering quotes, route-ordered stops, parts on the van, and pay on site takes longer. The schedule is set once the first van day and what 'done' looks like are clear.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. AI-built prototypes from Lovable, Replit, Bolt, or v0 can be assessed as starting points. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more: the most expensive version is the product that looks finished, clean screens and clicking buttons, while underneath nothing is tested and the security checks run in the browser, where anyone can tamper with them, instead of on the server where they hold.

Security starts with the data, the people, who can see and change what, the systems it connects to, and where it runs. The scope can include access controls, separate testing and live environments, protected passwords and keys, activity logs, backups, recovery plans, and whatever your regulation requires. We write down which protections are included and which evidence your team or an independent specialist must provide. We do not call a product compliant until the technical, operational, and legal requirements are all verified.

We need one person who owns the van day, access to the relevant users and systems, timely answers on business rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.

Ask for the quote to name everyone who will use the system, including your own team. Every platform has two products: what customers see, and what your people use all day: dispatch, the job card, parts, invoicing, mileage, and a record of who did what. When that second product is quoted as an 'admin panel' on a single line, it becomes the overrun. Our quotes treat your team's screens as their own scope, with their own users. Then the phase names the workflow, what 'done' looks like, the price, and the exclusions, all before paid work starts. You review working software at agreed checkpoints, and when new information changes the scope, you hear the effect on price and timing before anything is approved.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the workflow agreed at the start. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.