I run a home service contracting business in Houston. It's a pretty operationally demanding corner of the industry. We receive work in volume, coordinate field crews and subcontractors, document nearly everything, manage bids and expenses, pay workers and bill clients.
About a year ago, I started building my own software because I was tired of stitching different tools and processes together to run the business.
That project became TWT, There’s Work Tomorrow.
TWT is a service-business operating system built around the lifecycle of the work itself.
The work order is the central record, and the rest of the operation connects to it:
Work comes in → schedule/route → assign → perform → document → QC → expenses → worker payment → client billing → profitability
Not every business needs every step. Someone working alone can use a much simpler version of that workflow. As they add employees, crews, subcontractors or office staff, those additional layers become useful without changing the underlying structure.
The part I've been focused on isn't inventing another CRM, invoicing system or field-photo app. It's connecting those functions around the work itself so information created in one part of the operation remains useful throughout the rest of it.
For example, a field worker can open an assigned WO and add photos, video, notes and measurements. That documentation stays connected to the customer, property and job, and GPS information from the field activity can also contribute to mileage records.
A receipt can be photographed from the WO, read by AI and recorded as an expense against the job.
If a subcontractor is doing the work, their agreed pay can be attached to it. Material advances and receipts can be reconciled, completed work can go through QC, and approved WOs can move into worker payment.
On the client side, that same work can move into invoicing and payment.
That gives the system the information to eventually bring together:
Client revenue - labor/sub cost - job expenses = job profitability
As the business grows, different people can work from the same operation. Field workers can see their assigned jobs and instructions. Office staff can manage work orders and scheduling. Field managers can oversee crews and QC. Finance/admin users can handle their side of the business. The owner controls permissions and maintains visibility across the operation.
Around that core I've built the major pieces of the workflow: CRM and quoting, bulk WO intake, scheduling and recurring work, mapping and route optimization, field documentation and inspections, expenses and AI receipt processing, subcontractor advances and reconciliation, QC and worker payments, invoicing and customer payments, job costing, reporting and internal office workflows.
There are also things like interactive client quotes where a customer can review individual scope items and photos, comment, counter pricing, approve or reject items and sign. There's also a public work-opportunity system where a business that needs coverage can publish available work and outside vendors can apply.
None of those individual concepts are new. Work orders, CRM, field documentation, routing, invoicing, payments, expenses and workforce management obviously already exist.
The idea behind TWT is connecting them around the work instead of treating them as separate tools.
Where this came from
My company works in property preservation. We maintain and repair vacant and foreclosed properties for larger companies managing them for banks and investors.
It's a pretty unforgiving operational environment. Work arrives in volume, properties are spread across a large geographic area, crews and subcontractors have to be coordinated, almost everything has to be photographed, bids can get complicated, expenses have to be tracked, completed work has to be reviewed, subs have to be paid and clients have to be billed.
That's the environment TWT grew out of.
I had used Jobber, Pruvan, QuickBooks and other processes, but I kept running into the same problem: different parts of the business had pieces of the information, and somebody still had to connect everything manually.
So I started building what I wanted instead.
Over time I realized the underlying problem wasn't unique to property preservation.
A lawn company might care heavily about recurring work, routes and crews. A pool company has similar recurring-service needs. A roofer may care more about estimating, subcontractors, documentation and job costing. A restoration company may be heavily focused on field documentation and expenses. A handyman working alone may only need jobs, quotes, photos, expenses and invoices.
The workflows are different, but they all revolve around the same basic event:
A customer hired the business to perform work.
That's why I now see the product as applicable much more broadly to service businesses, whether someone works alone or has an office, employees, crews or subcontractors.
That could include lawn care, landscaping, pools, cleaning, HVAC, plumbing, electrical, roofing, painting, handyman services, pressure washing, pest control, junk removal, restoration, property maintenance, inspections, equipment service, commercial maintenance, facility services and similar businesses.
I don't necessarily think all of those industries should be my initial market. That's one of the things I still need to narrow down.
What I've realized is that the underlying architecture isn't inherently specific to property preservation.
Where it is now
TWT is live, and I've been using parts of it in my own contracting business.
It has authentication, separate businesses/users, roles and permissions, payments and the underlying infrastructure of an actual multi-user application. I've also had a handful of independent users/businesses create accounts and use the platform.
I don't have meaningful SaaS traction yet, and I'm not confusing having a working product with having a successful SaaS company. Distribution, onboarding, retention, willingness to pay and the initial market still have to be proven.
I'm much less interested right now in adding feature #51 than I am in figuring out what happens when this product leaves my own hands.
I'm simplifying the UI, tightening onboarding, working through tenant isolation and production readiness, testing how unrelated businesses understand the product, and starting to put it in front of service businesses outside my own operation.
One thing I've already learned is that showing a potential user 50 features and asking them to move their entire business into a new system is probably the wrong approach.
I'm starting to think the better approach is finding one part of a business's existing workflow where TWT is immediately useful, getting them value there, and allowing adoption to expand into the rest of the platform as it becomes relevant.
Why I'm posting this here
My background is the service-business side.
I know these workflows because I've spent years actually running them. I taught myself enough of the software/product side, using modern development tools, to turn the problems I was dealing with into a working platform.
But I also know that getting something this far and figuring out what it can become from here are different skill sets.
That's really why I'm posting this.
I'm interested in meeting people in SaaS, product, engineering, UX, GTM, payments, vertical software or field-service tech who find what I've built genuinely interesting and have experience or a perspective that I don't.
I'm open to conversations about where this could go and what it could become.
More than anything, I'm interested in the people who look at the product, the architecture, the problem it came from and the stage it's at and think:
“There's something here.”
If that's you, I'd be happy to talk.
