Thorbis did not start because the field-service software market needed another scheduling calendar.
It started because I owned a plumbing and septic company, grew it to $2.4 million in annual revenue, and still did not have a system that showed me the whole truth of the business.
The office knew one part of the customer story. The technician knew another. The estimate carried assumptions that did not always reach the crew. The invoice showed revenue without explaining whether the job made money. Calls, texts, photos, payments, inventory, payroll, and follow-up lived across different tools and different people.
When something went wrong, the information usually existed somewhere.
The problem was that it did not exist together.
That is the idea behind Thorbis: field-service software should not be a collection of tabs that happen to share a login. It should understand the operating chain from the first phone call to the final dollar and help the company see where that chain is about to break.
A service business does not need more software activity. It needs fewer dropped handoffs.
That sounds like a product statement. For me, it is a lesson paid for through real operational failure.
The market has already proven that an operating system matters
I am not pretending that nobody has tried to solve this.
ServiceTitan deserves credit for proving that contractors will adopt a deep, end-to-end platform. In its fiscal 2026 annual filing, ServiceTitan described a product spanning call tracking, scheduling, dispatch, customer communication, marketing, estimating, sales, payments, inventory, and payroll integration. It reported approximately 10,800 active customers and $82.1 billion in gross transaction volume processed through the platform during that fiscal year.
Those numbers do not prove that every contractor is happy, that every workflow is solved, or that a smaller company should copy ServiceTitan. They prove something more important:
The trades are not a lightweight-software market.
A serious plumbing, HVAC, electrical, roofing, or septic company is a complicated operating business. It has a mobile workforce, urgent customer demand, physical inventory, route constraints, licensing, job risk, financing, warranties, payroll, cash-flow timing, and a large amount of information moving between the office and field.
The market is large enough for different product philosophies.
Thorbis is not being built on the theory that integrated software is a new idea. It is being built around a different question:
What would an operating system for the trades look like if it were designed from the field up, priced so the whole team could use it, and built with AI that remains accountable to the owner?
The job is one continuous chain
Most software categories are described separately:
- CRM
- Scheduling
- Dispatch
- Estimating
- Invoicing
- Payments
- Communications
- Inventory
- Reporting
- Payroll
- Marketing
- AI
The customer does not experience separate categories.
The customer calls because a sewer is backing up. The call becomes an account, property, problem description, and appointment. Dispatch assigns a technician. The technician inspects the system, documents the condition, builds options, and gets approval. The approved option consumes labor and materials. The completed work creates an invoice, warranty obligation, payment, follow-up, and future service history.
Every step changes what the next person needs to know.
When software treats those steps as isolated modules, people become the integration layer. The dispatcher copies a note. The technician asks the customer to repeat the story. The office searches a text thread for a photo. The bookkeeper sees a deposit without the job context. The owner sees revenue without the original estimate assumptions.
Thorbis is based on a simpler model:
lead → customer → property → job → scope → approval → work → invoice → payment → follow-up
The data should travel with that chain. A change at one step should update the people and calculations that depend on it.
That is what “one system” should mean.
It should not only mean that the company bought several products from the same vendor.
Field software has to work where the work happens
A field-service application is not normal office software.
Technicians use it with one hand while carrying tools. They use it in crawlspaces, basements, mechanical rooms, attics, trenches, and truck seats. Signal can be weak. The sun can wash out the screen. The customer may be standing six feet away waiting for an answer.
A workflow that feels acceptable during a desktop demo can feel unbearable on the tenth call of the day.
That changes the product requirements:
- The next action has to be obvious.
- Important information cannot be buried under administrative settings.
- Touch targets need room for imperfect input.
- Common actions should not require repeated typing.
- Photos and measurements should attach to the correct job immediately.
- A weak connection should not erase work.
- The technician should be able to explain the customer’s choices from the same information used to build the estimate.
- Paperwork should be finishable in the driveway, not at home after dinner.
This is one reason I care so much about speed. A fast marketing page is good. A fast route transition is good. But the real measurement is task time.
How long does it take to create the customer, find the property, understand the original call, build the option, collect approval, record materials, take payment, and close the job correctly?
Every second repeated across every technician becomes labor.
Assume eight technicians each complete 14 repeated workflow actions per day. If the software removes only 45 seconds from each action across 250 working days, the annual time recovered is:
8 × 14 × 45 seconds × 250 days = 1,260,000 seconds
That equals 350 hours per year.
At an illustrative loaded labor cost of $45 per hour:
350 × $45 = $15,750
That is the value of removing less than one minute from a repeated action. It does not include faster dispatch, fewer errors, earlier payment, or the work those 350 hours can produce.
Software performance is not a vanity benchmark when the product is part of the labor process.
Per-seat pricing can work against adoption
A company gets the most value from an operating system when the whole operation participates.
The CSR needs the call history. The dispatcher needs capacity and location. The technician needs the scope and customer context. The warehouse needs demand. The manager needs job cost. The owner needs cash and risk. Restricting access creates blind spots.
This is where per-seat pricing can create a bad incentive. The vendor earns more as more employees are added, while the contractor starts deciding who can live without access.
Consider a hypothetical 12-person company evaluating software at $150 per user per month:
12 × $150 = $1,800 per month
That is:
$1,800 × 12 = $21,600 per year
Thorbis currently publishes a base price of $299 per company per month with unlimited users, plus transparent usage for utilities such as calls, texts, and AI after an included allowance.
The base subscription is:
$299 × 12 = $3,588 per year
The difference between the two base-price models is:
$21,600 - $3,588 = $18,012 per year
That is an illustrative comparison, not a quotation from a specific competitor. Usage, implementation, add-ons, support, and actual vendor pricing can change the result.
The point is the incentive.
I want the next technician, dispatcher, apprentice, or office employee added to the operating system because their participation improves the data and workflow. The price should not make the owner wonder whether that person is important enough for a login.
Financial truth has to sit beside operational activity
My plumbing company did not fail because we lacked invoices.
We had revenue data. What we lacked was an operating view that connected the revenue to the decisions and costs that produced it.
A $20,000 job can be excellent or terrible. The invoice alone cannot tell you.
The company needs to know:
- What labor was estimated?
- What labor actually occurred?
- Which materials were quoted, committed, used, returned, or lost?
- What equipment and subcontractors were required?
- Did the job absorb permit, disposal, financing, or warranty costs?
- Was a change in scope captured before the work continued?
- When did the cash arrive relative to payroll and purchasing?
- Did the customer return, refer someone, dispute the bill, or require a callback?
That is why Thorbis is intended to connect field operations with money rather than treating accounting as a separate screen visited at the end of the month.
Revenue is an event.
Margin, cash timing, customer value, and operational risk are the business.
I am especially interested in making commitments visible. A bank balance can look healthy while taxes, payroll, supplier bills, warranty obligations, and upcoming purchases have already claimed the money. A job can look profitable while the material receipt, callback labor, or unpaid change order has not reached the report.
The system should make it harder for owners to confuse money in the account with money available to spend.
Communication should be one record, not several channels
A service business still runs on conversations.
The customer calls, texts a photo, replies to an email, approves an estimate, receives an arrival update, asks a question during the job, and follows up months later. The business may know all of that while no individual employee can see all of it.
That is not a communications problem. It is a context problem.
The same customer should not become several disconnected identities because they used several channels. The technician should not arrive knowing only the dispatch note when the office has already received photos and answered questions. The customer should not have to repeat the same explanation to the CSR, dispatcher, and technician.
Thorbis is being designed around a living customer and property record where calls, texts, email, approvals, jobs, equipment, invoices, and internal notes can be understood together.
The benefit is not a prettier inbox.
It is fewer promises lost between people.
AI should be visible, bounded, and reversible
The field-service industry is moving quickly toward AI.
Some of that will be genuinely useful. An AI system can answer a call after hours, summarize a conversation, identify a scheduling conflict, draft a follow-up, find an unpaid invoice, flag a margin problem, or turn a technician’s field notes into a cleaner customer explanation.
The risk is building one vague “AI assistant” with broad access and no clear ownership.
Thorbis is being designed around distinct AI surfaces with distinct jobs: voice, operational recommendations, automations, and questions about the business. The public product direction is also explicit that sensitive automations can pause for human review and that the owner decides what can run automatically.
That separation matters.
A healthy AI feature should answer five questions:
- What information can it see?
- What action can it take?
- What evidence produced the recommendation?
- Who approved or changed the action?
- Can the action be reversed or corrected?
The more financially or emotionally important the action, the more human judgment belongs in the loop.
Booking an available maintenance appointment is different from changing a payroll amount. Drafting an estimate explanation is different from authorizing a discount. Flagging a risky invoice is different from sending a collections message to a long-term customer.
AI should remove repetitive work without quietly taking ownership away from the people accountable for the result.
Thorbis is early, and the roadmap should say so
One of the easiest things for a software company to do is describe the future in the present tense.
I do not want to build that way.
Thorbis is early. The current public site identifies features that are in development, in design, or planned later. The proof page intentionally avoids invented testimonials and says directly that the product is early.
That is not polished startup theater. It is the standard I want the product to keep.
There are three kinds of claims a product company can make:
- What exists and can be verified today
- What is actively being built
- What is part of the longer-term direction
Those should not be blurred together.
A contractor evaluating software is trusting the vendor with customer records, schedules, pricing, communication, and money. The sales process should make uncertainty smaller, not hide it.
I would rather explain exactly what is ready than manufacture the appearance of maturity.
What Thorbis is not trying to be
The scope is large, so boundaries matter.
Thorbis is not trying to turn every contractor into the same company. Plumbing, HVAC, electrical, septic, roofing, and commercial service share operational patterns, but they do not share every workflow.
It is not trying to automate judgment out of the trade. A system can surface code, history, measurements, options, and risk. It cannot replace the licensed person standing in the building.
It is not trying to win through the largest number of settings. Configuration is useful when businesses truly differ. Configuration becomes failure when the owner has to design the software before using it.
It is not trying to make software the center of the day. The customer and the work are the center. Good software should disappear behind a clear next action.
It is not trying to copy a competitor screen by screen. Existing platforms are evidence of what the market values and where workflows become complicated. The product still needs its own point of view.
The product principles
As Thorbis develops, I keep returning to a small set of principles.
One source of operational truth
Customer, property, job, equipment, communication, scope, invoice, payment, and cost should form one connected record rather than several synchronized copies.
The field is the primary environment
Desktop administration matters, but every workflow has to survive the phone, bad signal, time pressure, and one-handed use.
Speed is measured in completed work
Bundle size and page metrics matter because they support the real target: fewer seconds, taps, corrections, and handoffs per job.
Pricing should encourage full participation
The company should be able to give access to everyone who improves the operation without negotiating another seat.
Automation should expose its reasoning
Recommendations and actions need evidence, ownership, logs, and review boundaries.
Financial views should show obligations, not only balances
The product should help owners see committed money, job-level margin, cash timing, and the operational causes behind financial outcomes.
The roadmap should separate reality from intention
Shipped, building, and planned are different states. Customers deserve to know which one they are buying.
Why I am still building it
There are easier products to build.
A field-service operating system has scheduling complexity, payments, telephony, permissions, offline behavior, financial data, mobile constraints, integrations, migration, and customers whose businesses cannot stop because the software is having a bad day.
That difficulty is exactly why I care about it.
I know what it feels like to have real demand and still lack control of the operation. I know what it feels like to search for information that the company technically has. I know what it feels like to discover that revenue did not mean the job made money. I know how much pressure accumulates when the owner becomes the connection between every person and process.
Thorbis is my attempt to turn those lessons into infrastructure.
Not infrastructure that makes a contractor look modern.
Infrastructure that helps the company answer the questions that decide whether it lasts:
- Are we answering and booking the right work?
- Does the field have the full customer context?
- Are we using capacity well?
- Did the job produce the margin we expected?
- Is the cash actually available?
- Did the customer trust the experience enough to return?
- What needs attention before it becomes a crisis?
The field-service industry does not need another dashboard full of activity.
It needs a system that understands how one call becomes one job, how one job becomes money, and how one experience becomes a long-term customer.
That is what I am building Thorbis to become.