Skip to content

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.

Byron Wade smiling outdoors
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.

  1. 01

    Ran the work

    Dispatch at 6 a.m., estimates at lunch, payroll on Friday, reports on Sunday night. The whole loop, personally.

  2. 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.

  3. 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.