DUDEDone Done Services · case study · 2026
I run a service company. This is the software we run it on.
DUDE tracks every job from the first phone call to the closed invoice — for about 25 people, the field techs among them working on iPads. It sits on top of the QuickBooks and Google Workspace accounts we were already paying for. It has been the company's official platform since 14 August 2026, and since September our first client has had a portal of their own.
What it is
One app, sitting on top of the systems we already had
Done Done Services is a construction, remodeling and maintenance contractor. Before DUDE, a job lived in four places at once: QuickBooks for the money, QuickBooks Time for the schedule, Google Drive for the paperwork, and somebody's memory for the status. Nothing agreed with anything else.
DUDE is the one place work is created. The office takes in every lead — including third-party dispatches — and one press promotes it: a QuickBooks sub-customer is created, a time jobcode is bound to it, a Drive folder tree is built, and an estimate template is copied in. From then on the job has one identity across three systems, and nobody types the same thing twice.
It is deliberately not a book of record. Hours and expenses are read live out of QuickBooks rather than mirrored, because the moment two systems both claim to hold the truth about money, one of them is lying.
Since September there has been a second product beside it: a client maintenance portal, where a client's facility staff file requests from their phone and watch what happens — while the work itself still runs in DUDE.
The three things it had to get right
Written down first, and never traded away
Status is always right
Fifteen job statuses, and every change is an admin action. Nothing in this app moves a job on a timer, a webhook or a guess — the system never guesses where a job is. Every change writes a history row inside the same transaction, so "days in this status" is honest by construction.
Documents land in the right folder
Uploads were a defining failure of the software this replaced. So the person uploading never names a destination: they make one small choice — before, after, or today — and the server resolves it to a real folder. Job folders are created once and never moved.
Nothing fails silently
A half-finished promote shows you exactly where it stopped, with a button that finishes precisely the missing part and is safe to press twice. Every failure mode we have hit has a name and a repair button, instead of a support call and a hand-written SQL statement.
Before and after
What actually changed on the ground
Before
- Getting a customer signature meant a six-step juggle between Drive and the iOS markup tool — the single biggest pain point in the company.
- Job folders were moved between four status-based shared drives by script. A failed move meant a lost or misfiled folder, and permissions that no longer inherited from the right place.
- Every new enquiry was created in QuickBooks first, so dead leads polluted the accounting file.
- Nobody could see the status of every job at once.
- Vehicle and equipment spend landed in one undifferentiated bucket. No maintenance history existed in any structured form.
- A client with a problem texted me, and then rang to ask whether anything had happened.
After
- The tech taps once, hands over the iPad, the customer signs, he drags the signature into place, and the stamped PDF files itself into
Signed Docs/. - One shared drive, tiered by customer type. Folders are created once and never move.
- Leads live in DUDE until they are real work. QuickBooks only ever sees jobs.
- One tracker, five filters, and the filter state is the URL — so a view is a link you can paste to somebody.
- A fleet module with per-machine service intervals, a maintenance queue and cost per machine — loaded with the real fleet, with every active vehicle entered, foldered and labelled.
- The client files it themselves, gets an email when it's scheduled, and can see where it stands without ringing anyone.
Who built it
Not a software company. Not a developer.
I am the owner and the sole decision-maker here, and I am not an engineer. I wrote and froze the requirements before any technology was chosen, made every architectural and user-facing call, and reviewed every slice before it shipped. Claude wrote the application code, in sessions that were never allowed to decide anything.
That division only works if the process is written down, so it is: a binding playbook for how a slice runs, a per-slice build history, a decision log where nothing is ever deleted, and a cross-slice lessons file now past a hundred entries. Two independent adversarial reviews sit inside every slice — one on the plan before a line is written, one on the code after. The paper trail runs to about 38 words of record for every line of Python in the repository, application code and tests together, which sounds absurd until the day it saves you.
Where to next
The product →
Every module, the fleet system, what the field sees versus what the office sees, and why the two are deliberately different.
The client portal →
The second product: what a client sees, how a request becomes a job, and the tenant fence that keeps one client's building out of another's browser.
How it was built →
Why the first attempt was thrown away, the eight-step cadence that replaced it, the timeline, and ten things that went wrong.
Under the hood →
The stack, the design calls worth defending, and the lessons that transfer to any build.