Service

Repair shop software development

For owners of phone, computer and appliance repair shops who need a system built around the ticket: what came in, in what condition, what was found, what the customer agreed to, which part was used and what warranty the repair carries.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A repair shop takes in other people's property and gives it back changed, which is why every argument at the counter is about what was true at intake.

A laptop arrives with a cracked hinge; the counter writes a ticket number on a card, the customer's phone number on the back and nothing about the scratch on the lid.
Two weeks later the customer is certain the scratch was not there.
The technician's diagnosis sits in a notebook, the quote was given over the phone, and the agreement to proceed is a verbal yes that nobody can produce when the invoice is questioned.

Where it gets harder

Parts make it worse.

A screen is ordered for a ticket, arrives, and is used on a different ticket because it was on the shelf and the technician was in a hurry; the first customer is told to wait another week.
Stock is counted when the shelf looks empty.
The warranty on a repair is a line on a receipt the customer has lost, so a return is argued from scratch.
Customers ring to ask whether their device is ready, and the counter stops serving to look it up.
Mail-in customers post devices with no label, the box arrives with no ticket, and the return goes out under whatever tracking number someone remembered to write down.

Scope of the service

What the build covers

A custom repair shop build takes the trade core in its counter form. The service area becomes the question of walk-in, courier or mail-in; the quote request becomes a device intake form with make, model, serial, fault description and condition photos taken at the counter; job records become repair tickets moving through received, diagnosed, quoted, approved, in repair, ready, and collected or posted; quotes and invoices carry the diagnostic fee, labour and parts with online approval by the customer; before and after photos sit on the ticket; and the review request goes out at collection. Scheduling is light, because most work is a queue rather than an appointment, though bench capacity and promised dates can be modelled where the shop wants them.

The repair-specific layer is the ticket's lifecycle and what hangs off it. A diagnostic fee is taken or waived according to your rules, the technician records findings and builds a quote, and the customer approves or declines from a link; a declined quote returns the device with the fee applied as you set. Parts ordering ties a part to the ticket it was ordered for, with stock levels for common items and a warning when a reserved part is picked for another job. A warranty record is created per repair with the period you choose by repair type, and a return is matched to it. A public tracking page lets the customer see the status from the ticket number without ringing. Mail-in customers print a label, the box is matched to the ticket on arrival and the return shipment is recorded against it.

Deliberately out of scope

Accounting and payroll, manufacturer warranty claim portals unless a specific one is scoped, and the sale of accessories as an online shop

When the scope grows

Scoping scenario

A shop with two branches and six technicians repairs phones, laptops and small appliances, takes mail-in work from across the country and wants parts stock shared between branches with reservations per ticket. A single-counter phone repair shop wanting intake photos, a tracking page and quote approval by text needs a far smaller build, and the scope document names which is being made.

Deliverables

What you receive

Discovery notes from a walk-through of a walk-in ticket and a mail-in ticket from receipt to return
A scope document naming each ticket status, the fee and approval rules and what stays outside the system
Design of the counter intake screen, the technician bench view, the customer approval page and the public tracking page
The build, deployed to your hosting or hosting we manage
Migration of customers, open tickets, parts stock and warranty records from spreadsheets or an existing app where relevant
Training for counter staff, technicians and the manager, with a written guide
Handover material and ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

Onboarding

Access to your current ticket book or app, fee and warranty rules, parts suppliers and the list of staff and branches, with one named contact.
Project stage: Onboarding
Planning

Discovery with the manager and a senior technician; the status flow, diagnostic fee rules, parts model and warranty periods are agreed in the scope document.
Project stage: Planning
Design

Clickable designs of the intake screen with camera capture, the bench queue, the approval page the customer sees and the tracking page.
Project stage: Design
Development

Intake and tickets first; then quotes, fees and approval; then parts and stock; then warranty, tracking and mail-in.
Project stage: Development
Client review

Your counter and bench run a test fortnight on real tickets alongside the old book, including a declined quote, a warranty return and a mail-in.
Project stage: Client review
Revisions

Findings are corrected and re-checked against the scope document and your fee rules.
Project stage: Revisions
Ready for launch

Open tickets and stock imported, notifications tested against numbers you control, label printing checked, launch list signed.
Project stage: Ready for launch
Delivered

Tickets run through the system; hosting and maintenance continue under their own agreement if chosen.
Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

Card payment providers for diagnostic fees, deposits and collection payments
SMS and email providers for status notifications and quote approval links
Parts supplier catalogues and ordering where a supplier exposes one
Courier and label services for mail-in receipt and return shipments
Accounting software for invoices, stock purchases and payments
Barcode and label printers at the counter and the bench

How we would approach it

Worked example

Concept demo

A two-branch repair shop with shared parts stock and mail-in work

The situation

A repair shop was losing parts to the wrong tickets and its counter spent much of the day answering "is it ready yet".

Why it is a custom build

Parts reserved to tickets across two branches is what makes this a custom build; general ticketing tools track status but have no idea which screen on the shelf belongs to whom.

The scope we would propose

An intake screen that captures serial, fault and condition photos before a ticket number is issued
A bench queue per branch with the diagnostic recorded against the ticket and a quote sent for approval by text link
Parts reserved to the ticket they were ordered for, with shared stock across both branches and a warning when a reserved part is picked elsewhere
A warranty record per repair with the period set by repair type
A public tracking page by ticket number
Mail-in labels generated at booking with the return shipment recorded against the ticket

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

Number of branches and technicians and whether stock is shared between branches
Device types repaired and the intake fields and photo capture each needs
Diagnostic fee rules, quote approval flow and the payment provider
Parts ordering, stock levels and any supplier catalogue connection
Warranty periods by repair type and the returns process
Mail-in service, label generation and the courier integration
Volume of open tickets and stock to import
Hosting choice: your own hosting or ours

FAQ

Frequently asked questions

How do you decide between a custom build and the package?

If your intake, ticket flow, parts and warranty fit the way the repair tracking package works with configuration, we quote for the package and say so. Custom work is the honest route when stock is shared across branches, when a supplier or courier must be connected directly, or when a manufacturer warranty portal is part of the flow. Discovery is where we tell you which.

Can condition photos be taken at the counter?

Yes. The intake screen uses the counter tablet or phone camera and attaches the photos to the ticket before the number is issued, so the condition record exists from the moment the device is accepted.

What happens when a customer declines the quote?

The ticket moves to declined, the diagnostic fee is applied according to your rule, and the device is marked ready for return or collection with the customer notified. Nothing is thrown away by the system; the decision stays yours.

Can parts stock be shared between branches?

If scoped, yes. Stock is held per branch with reservations per ticket, and a transfer between branches is recorded so both counts stay right.

Who owns the system afterwards?

You do. Source code and all ticket, stock and warranty data are handed over at delivery. Hosting and maintenance are optional and separately agreed.

Get a project quote for technical repair software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership

Repair shop software development

What goes wrong today

What the build covers

Deliberately out of scope

When the scope grows

What you receive

How a project runs

Onboarding

Planning

Design

Development

Client review

Revisions

Ready for launch

Delivered