Founder
Built from inside a service business.
Thorbis wasn’t built in a boardroom. Byron Wade is a master plumber who owned a plumbing and septic business, and built the field software he wished he’d had, after running dispatch, estimating, pricing, payroll, and reporting himself.

- Name
- Byron Wade
- Trade
- Master plumber, licensed in two states
- Role
- The founder, and still on call
The experience
What shaped the product.
Master plumber
Licensed in two states, and still on call. The trade came before the software, and it still outranks it in arguments.
Plumbing and septic business owner
Owned and ran the company: the trucks, the crew, the phone that rings at dinner. The product’s opinions were earned there.
Dispatch, estimating, and the office
Ran dispatch and customer service himself; wrote the estimates; chased the paperwork. Every screen in Thorbis had a night shift behind it first.
Pricing, payroll, and reporting
Managed technicians, set the prices, ran payroll, read the numbers. The owner pages exist because he was the owner reading them.
Software and AI development
The second trade. Thorbis is what happens when the person who felt the bottleneck can also build the system that removes it.
Builder principles
Shaped by the work, not a software category.
Thorbis is designed around the uncomfortable parts of running a service company: coordination, trust, cash flow, adoption, and data that has to stay clean.
01
Built for the truck and the office
The same workflow has to make sense to the dispatcher, the technician, and the owner reading the numbers later.
02
Transparent pricing matters
A shop should budget software without surprise modules, seat traps, or hidden implementation complexity.
03
Your data should stay useful
Customers, jobs, equipment, invoices, and messages should become an operating asset, not another export problem.
04
AI should do real shop work
Automation should chase follow-ups, surface risks, and cut admin drag, not perform tricks in a demo.
The arc
Operator, then builder.
01
Ran the work
Dispatch at 6 a.m., estimates at lunch, payroll on Friday, reports on Sunday night. The whole loop, personally.
02
Felt the bottleneck
The lightweight tools were too thin to grow on; the enterprise platforms too heavy, too expensive, and months to roll out.
03
Built the system
The field platform he wanted: easy enough for the first truck, strong enough for a multi-location operation. Priced at $99 so any shop can grow into it.
The value of trade-built software is not biography. It is knowing which small failures compound inside a service company.
Operating lessons
Learned running the business. Kept in the product.
The schedule is where trust breaks first
Missed windows, vague notes, and weak dispatch context become customer problems long before they become software problems.
Cash flow depends on the field handoff
If the technician cannot document the work cleanly, the office cannot invoice quickly or collect confidently.
Adoption is an operations problem
Software sticks only when the workflow makes sense to the owner, the office, and the person doing the work.
Data should not die after the job
Equipment, history, photos, signatures, payments, messages: all of it should make the next visit easier.
Start
Run it on an operator’s software.
$99 / company. Unlimited people. Built by someone who has been the person your software bill punishes.
Coming from a suite? We’ll extract your records.
Rather talk first? Email the team.
