Why I Built Taskrol
When I started my appliance repair company, I assumed the hard part would be the repairs themselves — sealed systems, control boards, the intermittent faults that never show up while you're standing in front of the machine. I was good at that part. I still enjoy it.
What wore me down was everything around it.
For a while I was working with several companies at the same time, which is normal in this trade. In practice that meant separate apps, separate logins, separate ways of doing everything. Finish a job, log out, log into the next system, and try not to write your diagnosis on the wrong company's ticket. Up to fifteen times a day. In a parking lot. With the next customer already calling. Here's how Taskrol handles subcontractors without the login carousel →
The van was its own mess. Anyone who does this work knows the picture: boxes of water valves, capacitors, thermostats, fuses, random hardware. You know the part is in there — you bought it two weeks ago. So you kneel in the back of the van and dig through boxes while the customer watches from the doorway. Some days I spent more time finding parts than installing them. This is the mess I'm talking about →
Then Sunday would come, and with it the weekly reports. Early on they took me an hour and a half. Not because the numbers were complicated, but because the information was scattered: payments in one app, parts receipts folded in my jacket, job details in text messages or just in my head. Every week I was reconstructing my own week from fragments — trying to remember what I'd installed and what it cost me. That became reporting built from the jobs and parts themselves →
At some point it became obvious that the hardest part of appliance repair isn't repairing appliances. It's not losing information on the way between the technician, the office, the supplier, and the customer. Every dropped detail costs time. Sometimes it costs money. Once in a while it costs you the customer — like the call you miss while you're on a job and the next company on the list picks up. We built online booking that creates the job for that →
That's where Taskrol came from. Not from a business plan or a pitch deck — from being tired of doing everything twice.
The shortest path from the call to getting paid
If I had to put the whole design philosophy in one sentence, it would be this: the shortest possible path from the call to getting paid. Take the call, do the job, order the part, send the invoice, collect the money. The app should follow those actions in the same order — without extra steps or screens that exist only because the software expects them.
Take the most basic thing: a new job. In every CRM I used, you first create the customer, save, then create a job, then attach one to the other. Two entities, several screens, all while the customer is still talking. In Taskrol it's one screen — Quick Job. The customer and the job get created together, in seconds. That one decision is the whole philosophy in miniature: only the actions a technician actually takes, in the order they take them. Watch the 39-second Quick Job demo →
The part where I'm just a user
I still run my repair company on Taskrol every day. My favorite moment as a user — not as the founder — is opening the statistics screen and trusting what I see. My income and expense reports build themselves from real jobs and real parts. These are not numbers I reconstructed from receipts on a Sunday. They are the actual state of my business, sitting in my pocket.
The other thing I use constantly is parts lookup. Type in the appliance's model number and the parts catalog and manuals for that exact unit are right there on the job. I couldn't find a tool that put those documents where I actually needed them, so we built it into the job itself. See parts lookup inside the job →
The same rule applies everywhere: multi-company support came from the login carousel, Shopping Lists from part-number texts sent to the office, and AI invoices from evenings lost to paperwork. If a feature doesn't trace back to a real problem from the field, we don't build it.
My test is simple: after a ten-hour day of service calls, would I still want to open this app? If the answer is no, it doesn't ship.