Collaboration Brief
From: Project Owner · March 2026 · Confidential
Truhub is a small business command center sold as a managed service at $2,500–$5,000/month. It is not traditional SaaS. It is closer to hiring a fractional COO who also builds and runs the tools — someone who sets everything up, keeps it running, and helps the owner make better decisions.
Every company we are building right now — Patriot, Tom Sawyer, Renderly, bld.it — is a proof of concept. We are building the template on real businesses we control, proving it works, and then Truhub is how we sell it to everyone else.
Starter
$2,500/mo
Growth
$3,500/mo
Full Stack
$5,000/mo
Four companies are being built simultaneously. Each is a real business with real customers. Together they prove the template across different industries — and each one becomes a live demo for Truhub.
Live — reference implementation
Towing and roadside assistance in the Eastern Sierra. The first complete instance of the template. Bookings, dispatch, Square invoicing, insurance reimbursement guidance, weekly AI blog, and owner command dashboard.
Next build
Painting contractor. Same field service architecture as Patriot — estimates, crew scheduling, job costing, material tracking, and client communication. Proves the template works beyond towing.
SaaS version of the template
The same field service platform as Tom Sawyer, built specifically for the fence industry and packaged as a SaaS product. Fence contractors sign up, get their own branded instance, their own subdomains, and their own command center. This is the direct precursor to Truhub.
Separate architecture — plan before building
AI-powered rendering engine. Places products — paint, pavers, flooring, siding, lighting — into customer environment photos so they can see it before they buy. The most technically distinct project in the portfolio. Requires dedicated architecture planning.
The project owner drives product strategy, design direction, and feature prioritization using Manus AI. Manus handles the initial implementation — scaffolding features, writing procedures, building UI, and saving checkpoints that sync to GitHub. This moves fast and covers a lot of ground.
Your role is to be the engineering conscience of the platform. Where Manus builds broadly, you build deeply. Where Manus implements correctly, you make it production-grade. The division is not about hierarchy — it is about leverage.
Every project in this portfolio is built on the same stack. Once you know it for Patriot, you know it for all four — and for every Truhub client after that. The most important architectural principle is this: one backend, one database, multiple surfaces. A booking made on the public site appears instantly in the dispatch board. A job marked complete triggers a review request, updates the financial dashboard, and logs the revenue — all from a single database write.
| Layer | Technology |
|---|---|
| Frontend | React 19, Vite, TypeScript, Tailwind CSS 4, shadcn/ui |
| API | tRPC 11 — all procedures in server/routers.ts, no REST routes |
| Backend | Express 4, Node.js, tsx watch |
| Database | MySQL / TiDB via Drizzle ORM |
| Auth | Manus OAuth + JWT session cookies, role-based (admin / user) |
| File Storage | AWS S3 via server/storage.ts — never local disk |
| Payments | Square SDK via server/square.ts |
| SMS | Twilio via server/sms.ts — driver dispatch and review requests |
| AI / LLM | Manus built-in API via server/_core/llm.ts |
| Maps | Google Maps (Manus proxy — no API key required) |
| Mobile | Expo (React Native) — shared tRPC backend |
| Scheduling | node-cron — weekly blog automation (Monday 9 AM PT) |
| Testing | Vitest — pnpm test |
| Package Manager | pnpm — do not use npm or yarn |
Each company — and each Truhub client — gets three subdomains beyond their main site, all sharing the same backend and database. The engineering challenge is not in building three separate applications. It is in designing the role-based access model, CORS configuration, and real-time data layer so that each surface shows exactly what its user needs.
Campaign landing pages, lead capture, email and SMS automation, blog syndication, and ad conversion tracking. Outward-facing — attracts customers.
Real-time job board, driver GPS tracking, two-way SMS, ETA management, and shift scheduling. Built for the people running the day-to-day.
Revenue, compliance, employees, taxes, document vault, and alerts. Everything an owner needs to make decisions without digging through spreadsheets.
The codebase is functionally correct. What it needs from you is the kind of depth that comes from engineering experience — the things that do not show up in a feature demo but determine whether a product survives contact with real users.
Public-facing endpoints need rate limiting before go-live. The Zod input validation layer is present throughout but warrants a completeness review. Cookie security headers, CSRF posture, and token expiry handling all deserve a dedicated pass before any company goes live under its production domain.
Database query patterns are correct but not yet optimized for production load. As job volume grows, the dispatch board and admin dashboard will need indexed queries, pagination, and potentially a caching layer. The React frontend has not been profiled — the dispatch board especially will benefit from virtualization and memoization as live job counts grow.
There is currently no CI/CD pipeline. Every project needs automated testing on push and deployment gated on passing tests. The subdomain architecture will require a reverse proxy configuration and a CORS policy that allows the three subdomains to communicate with the shared backend securely.
The most important engineering challenge for the platform's commercial success. When a new Truhub client signs up and pays, the system needs to automatically provision their instance — create their account, configure their branding, set up their subdomains, and get them live. This is the SaaS layer that sits on top of the field service template. The architecture for this needs to be designed before bld.it is built, since bld.it is the direct precursor.
The most open-ended engineering challenge in the portfolio. The product concept is clear — place any product into a customer's environment photo and make it look real. A production render pipeline needs a job queue, status tracking, credit metering, and likely a specialized model for photorealistic compositing. This is where your architectural thinking will shape the product most directly.
What we are building across these four companies is a template for how small businesses should be run. Not with a dozen disconnected SaaS subscriptions, not with spreadsheets and phone calls, but with a single platform that gives every person in the company — the driver, the dispatcher, the owner — exactly the information they need to do their job well.
When this works for Patriot, it works for Tom Sawyer. When it works for Tom Sawyer, it works for the next painting company, the next towing company, the next fence contractor. The template becomes Truhub. Truhub becomes the product.
You are not just maintaining a codebase. You are co-authoring the infrastructure that hundreds of small businesses will run on.
Truhub clients are not buying software. They are buying a 12-month partnership that ends with their business running on a system built specifically for how they operate. The engagement has three distinct phases, each with a different kind of work and a different pricing structure.
Spin up the 80% — Command Center, all three subdomains, booking form, dispatch, Square invoicing, review engine, weekly blog automation, and social posting. The client goes live with a fully operational platform in under 60 days. This phase is largely templated and moves fast.
The 20% that makes the platform theirs. Weekly calls, iterative builds. Their specific job types, their estimating logic, their crew workflows, their compliance requirements, their reporting. This is where the platform stops being a template and becomes the operating system for their specific business. It takes a year to do it right.
The platform runs itself. Blog posts auto-publish. Reviews auto-request. Dispatch works. The owner has their dashboard. This phase covers updates, new features as the business grows, and support. The client is locked in not by contract but by switching cost — their entire operation is built into the system.
"We spend the first year building your business into software. After that, your business runs itself."
Every Truhub client gets the same 80% — the core platform that handles marketing, booking, dispatch, invoicing, reviews, and the owner command center. The remaining 20% is built custom for their industry during Phase 2. Your job as lead engineer is to keep the 80% clean and stable so the 20% can be built on top of it without touching the core.
Towing
DOT compliance logs, driver hour tracking, insurance claim workflows, long-haul route planning
Painting
Crew scheduling by job size, paint spec sheets, color approval sign-offs, surface prep checklists
Fence
Material takeoffs, linear footage estimating, permit tracking, HOA approval workflows
HVAC
Equipment serial tracking, warranty management, maintenance contracts, seasonal scheduling
Landscaping
Recurring service routes, seasonal contracts, equipment maintenance logs
The most important architectural decision for Truhub's scalability is how the 20% connects to the 80%. Each industry module needs to slot into the Command Center and the dispatch workflow without requiring changes to the core platform. This is the design challenge Robert owns.
The goal is a plugin interface clean enough that adding a new industry takes days, not weeks — and that a new industry's module can be built, tested, and deployed without touching any shared code. Think of it as the difference between a WordPress plugin and a WordPress fork.
Job schema extension
Additional fields on tow_jobs specific to this industry (e.g., linear_footage, permit_number, paint_spec)
Intake form fields
Extra fields shown on the booking form for this industry's specific job requirements
Dispatch card template
What the driver sees on their job card — industry-specific checklist items and fields
Command dashboard module
An additional section in the owner dashboard with industry-specific metrics and reports
Compliance requirements
Industry-specific license types, expiration tracking, and regulatory alerts
Estimating logic
Pricing formulas specific to the industry (per linear foot, per room, per ton, per hour)
Design note: The plugin system does not need to be built before bld.it — but the schema and router patterns established in bld.it will become the reference implementation. Design bld.it's fence-specific extensions with the plugin interface in mind, and the pattern will generalize cleanly to every industry after it.
Questions about product direction go to the owner. Questions about the codebase start with server/_core/ and this document.
Welcome to the team, Robert.