Boss HQ is the operations software a multimillion-dollar custom home builder runs on
We built it to replace JobTread, so jobs, budgets, draws, vendors, schedules and documents are all kept in one system the builder owns, and the field team's work is there too. An AI assistant works inside it, and its permissions are the same as whoever's asking.
- 1,456logged file moves in a folder of about 27,000 files, and we deleted none
- 166,239lines of TypeScript are in the main code repo (generated and type-declaration files left out)
- 152tables are in the live database
- About 130tools can be called by the AI assistant, and each one's checked against the caller's role
As of October 28, 2026
At a glance
- The client
- A multimillion-dollar custom home builder runs its operations on Boss HQ every day, and the builder owns the code and the Cloudflare account it's running on.
- What it replaced
- Boss HQ was built to replace JobTread. Before that the team had tried a task manager and then an all-in-one construction platform, and neither one did the job well.
- What it covers
- It handles jobs, schedules, budgets, receipts, draws, purchase orders, change orders, vendors and their paperwork, daily logs, time and mileage, and SOPs and training. People can reach it through a team web app, a Telegram bot, a Claude connector and a homeowner portal.
- Size, as of October 28, 2026
- Three Cloudflare Workers carry the product, and there are 152 live database tables, 208 database migrations, 523 commits, 166,239 lines of TypeScript, and about 130 AI-assistant tools.
- The data move
- 1,595 tasks and 131 task dependencies were moved over from JobTread with zero refusals. 119 lien waivers are each linked to their Drive file, 1,284 estimates were loaded and coded by script, and we found 2,981 files that existed only in JobTread.
- The Drive cleanup
- Across four logged cleanup passes in the builder's old shared folder (about 27,000 files), we made 1,456 file moves, 804 of them duplicate copies set aside in holding folders for a person to review, and 1,192 renames: 724 estimate files brought to the company's naming standard and 468 files given their real names back. We also created 762 folders. We deleted nothing; a person decides what goes. When the June automated rename got 850 files wrong, an audit caught it, and a logged fix pass gave 468 files their real names back and moved 393 duplicate copies into a holding folder. These are logged operations, so a file handled in two passes counts twice.
- How it's built
- I built it with Claude Code directing subagents, and I don't have formal development training. Every load-bearing change is checked by two independent AI reviewers, Skeptic and Red Team, before it merges.
- How it fails
- Bugs and feature requests are turned around in under 20 hours on average (19 hours 27 minutes, from Boss HQ's own tracker, October 2026). One gap is still open, because nothing's grading Ask Boss's answers yet, and answer-quality evals are the next piece being built.
What it does
A custom home builder runs on loops that general software was never drawn around. The team tried a task manager first and then an all-in-one construction platform, and each one did a little of everything and none of it well. Costs, vendor paperwork and draws (the request for payment that goes out as a house hits each milestone) were carried by hand beside the software, and conversation lived in texts, email and chat, and the right file was often sitting in the wrong copy of a Drive folder. The work kept happening around the software, so the software didn't have a chance to help.
Here's what the team's doing in Boss HQ every day, grouped by area, and each area links to the same screen in the demo, and all of the data in it is invented.
Projects and schedule
Every house is a project on a board, and the team opens one to see its tasks, schedule, documents, budget and daily logs. The schedule is a Gantt chart with dependencies, so when you move one task, the tasks that depend on it are pushed or pulled to stay in step. Phases have colors, finished phases collapse and stay collapsed, and baselines show variance against the original plan. You can see it in the demo.
Budgets and costs
The original budget locks at construction start, and every budget line carries a cost code. On top of that the team tracks allowances, a buyout log, a monthly forecast, contingency and cost per square foot. A budget can be seeded from a file, and the seeding has an Undo. You can see it in the demo.
Receipts and invoices
A receipt or vendor invoice is filed against a job and a cost code, and the cost code is what puts it on the right budget line. Receipts are editable, linkable and deletable, and they have an Undo too. You can see it in the demo.
Draws
Closing a draw, submitting it and opening the next one are three separate buttons, and each vendor's lien waiver is shown inside it. Anyone on the team can close or open a draw, but submitting one or marking it paid is limited to admins, and submitting first shows any packet tasks that aren't done. You can see it in the demo.
Purchase orders, change orders and documents
A purchase order starts from an estimate, gets built as a PDF, and is filed in Google Drive. Change orders and estimates sit beside it, and an estimate intake reader captures an estimate's stated exclusions into a review queue. Voiding a PO drafts the email to the vendor, and you can see it in the demo.
Vendors and compliance
Each vendor has a license status, insurance, a W-9 and a master agreement on file, along with a prequalification checklist and expiry banners. A lapsed certificate's flagged on the vendor, and it's flagged again in the draw at pay time. You can see it in the demo.
Field work
Daily logs are one per person per day, with role-specific questions, in-app reminders, and a way to edit your own past log. Hours go through an approval queue that only approvers see, miles are logged on their own tab, and people can clock in and out from Telegram. You can see it in the demo.
Ask Boss and Telegram
Ask Boss answers questions about the company's own jobs, and it's got a history panel and answers scoped to the asker's role. The Telegram bot answers in a group when it's tagged or replied to, links a chat to a job, and asks for a Yes before it changes anything. Claude can reach the same system through a connector, and I'll explain the safety rules on that further down. You can see it in the demo.
Training and SOPs
Training documents record who has read them, and an always-present Report an issue button takes up to three photos. You can see it in the demo.
Metrics and the activity log
Metrics shows company tiles for jobs needing attention, billing position, schedule health, vendor-blocked work, draws needing action, and open questions and RFIs, with delay attribution on the schedule and draw cycle time inside Draws. The activity log is visible to leadership only, and you can see it in the demo.
The homeowner portal
It's a read-only view of one house, and it's got schedule, budget, draws and change-order tabs. A homeowner reaches only the job they were granted, and each grant sets how much money detail they see. You can see it in the demo.
The story
The builder wanted software that's shaped around how the company runs, and nothing on the market fit. The task manager and the all-in-one platform each had plenty of features, but the real work kept going around them, because none of those features matched how a cost-plus custom builder operates. (Cost-plus means the homeowner pays the real costs of the build plus a fee, so the budget has to show what's actually being spent, house by house and vendor by vendor.)
So the builder decided to build its own, and I was the one who took the job. I listened to how the company runs, and what I heard came down to five loops: houses move through phases, money moves through draws, and commitments move through documents, and people coordinate while everyone needs visibility. Every module in Boss HQ belongs to one of those loops, and if a feature didn't serve a loop, we didn't build it. That's the rule.
From there the work went in order. We migrated the data out of JobTread and loaded it under rules that'd refuse anything that broke one, and we also cleaned up the Google Drive, since the team had been filing into look-alike folders right next to the real ones. I built the platform with Claude Code. Then we moved the team onto it. Today the builder's team runs its operations on Boss HQ every day.
Here's my part in plain words: we migrated all their data over, we built it, and we got things cleaned up in Google Drive. I built it with Claude Code, and I don't have formal development training. The builder owns the code, so the demo is a from-scratch recreation on invented data, because the real records are theirs.
The Drive cleanup
Across four logged cleanup passes in the builder's old shared folder (about 27,000 files), we made 1,456 file moves, 804 of them duplicate copies set aside in holding folders for a person to review, and 1,192 renames: 724 estimate files brought to the company's naming standard and 468 files given their real names back. We also created 762 folders. We deleted nothing; a person decides what goes. These are logged operations, so a file handled in two passes counts twice.
The old shared folder held about 27,000 files (counted October 2, 2026). The 1,456 moves, 1,192 renames and 762 folders come from the inbox, rename fix, September rename and cost-code passes below; the estimate-folder and empty-folder passes add moves that aren't in those totals. The 804 duplicates are part of the 1,456 moves, and every move and rename was logged with the original name next to the new one. The 467 June duplicates went to a Proposed Deletions folder and the 337 September ones to a folder named _Duplicates, where they wait for a person to review them.
Here's how the passes went.
- Inbox: About 700 loose files in the Drive inbox came down to 68. Of the 712 moved, 425 were filed, 213 were routed to their owners, and 74 were duplicates we set aside, and the names stayed as they were.
- Rename fix pass: 468 files got their real names back, 393 duplicate copies were set aside, and 2 were skipped because someone had already trashed them.
- September rename pass: 724 estimate files were renamed to the company naming standard, and 337 duplicate copies were set aside. 14 drawings moved into project folders, and 516 folders were created.
- Estimate folders: 480 cost-code folders were moved up a level, so estimates now sit one level down instead of two.
- Cost-code folders: 244 cost-code folders and 2 estimates folders were created, so every cost code has a home in the Drive.
- Empty folders: 115 empty folders were set aside for review. Since then 78 are still there and 37 were trashed by a person, and we haven't deleted any.
What changed
The builder's team is running its operations in Boss HQ, and here's what changed, with what each count means.
- One place for the work: A receipt, a change order, a vendor certificate and a schedule date are kept in the same system and point at each other. Costs land on budget lines because every receipt carries a cost code.
- 1,595 tasks and 131 task dependencies moved over from JobTread across four live jobs, with zero refusals by the rules they were loaded under. That's the migrated schedule work the crews were already running.
- 119 lien waivers are each linked to their Drive file, so a draw can show every vendor's waiver.
- 1,284 estimates were loaded and coded by a governed script from the existing Drive files. A script did that work, so I'm not claiming a model filed them.
- 2,981 files were found that existed only in JobTread, so the team knows what would've been left behind.
- A Drive folder for every cost code, 244 of them, means each document has an obvious place to land.
- A Drive inbox went from about 700 loose files to 68.
- Field entry happens from Telegram: Clocking in and out, linking a chat to a job, and daily-log reminders are all done where the crews already talk.
- Vendor compliance has data behind it, so a lapsed certificate now has something to flag.
I haven't measured hours saved, so I can't quote a number.
How it's built
The architecture in plain words
Three Cloudflare Workers (small programs that run on Cloudflare's network and wake up when they're asked) carry the product: the team app's API, the assistant server with Telegram, and the homeowner portal. They share one database and Google Drive for files. They all share one core.
- The team web app. This is what the crew opens in a browser, and it's running behind Cloudflare Access with Google sign-in and talks to the core.
- The assistant server. It speaks MCP, which is the standard that lets an AI assistant like Claude call a system's tools. It exposes about 130 tools, and each one's checked against the caller's role. The Telegram bot lives here too, and a Durable Object (a small stateful program) holds each chat.
- The homeowner portal. It's a separate, read-only Worker. A homeowner signs in through Cloudflare Access, and what they've been granted is the only job they see.
- The shared core. Every change goes through one write door, and that door's job is to check the caller's role, block double submits and edit collisions, apply all or nothing, and write an audit row. The web app, the Telegram bot and the Claude connector all write through it, so the answer's the same wherever you ask.
- The database. Cloudflare D1 (a hosted SQLite database) holds the structured records, and it's got 152 tables today. A scheduling engine, a search layer that uses Workers AI and Vectorize (a vector index that finds text by meaning), and a few shared packages sit around it.
- Google Drive. Files stay in the builder's own Drive, and Boss HQ is what files and links them there.
- Scheduled jobs. Jobs like the daily-log autofile and a regular Telegram sweep are code that runs on Cloudflare Workers, right next to the data they touch.
The stack in numbers
These figures are from GitHub main (commit 2e411ccf) and the live database, as of October 28, 2026.
- 3Cloudflare Workers carry the product: the team app's API, the assistant server with Telegram, and the homeowner portal.
- 523commits are in the main Boss code repo. (The team web app's front end lives in a second repo that isn't counted here.)
- 166,239lines of TypeScript are in 367 files, and generated files and type-declaration files are left out.
- About 170,000lines of test code sit beside it, and they aren't counted in the TypeScript total.
- 152live database tables are there, plus 9 views and 100 triggers.
- 208database migrations have run.
- About 130AI-assistant tools are available. The owner role sees 127, and the code registers 132 names in all, and a few of those are gated to admins only.
- 725test files ran in the newest run, and 722 were green.
- 25 of 25deliberately planted bugs in the must-catch set were caught by the tests. On a wider set of 33 that Red Team picked, 19 were caught and 14 got through, so the tests do have gaps.
How I build it
I work in Claude Code with an orchestrating session I call Kai. Kai doesn't do the building. It writes a scoped brief, hands it to a subagent, and reads back a short written report. Builds go to a mid-size model and trivial jobs go to a small one, and the big one's used only when the brief says why.
Every load-bearing change is reviewed by two independent AI reviewers before it merges. Skeptic assumes the work is wrong and hunts for errors, and Red Team attacks the assumptions and looks for what's missing, and each one returns a complete ranked list of problems in one pass, and there are three rounds at most for most work (a few kinds of change allow more). In my own build sessions, a merge gate blocks any merge into the Boss repo that doesn't have a fresh verification record.
Across Kai's whole system, and not only Boss, the verification log has 13,956 logged review rounds from March 16 to October 28, 2026. A row is one reviewer round, and a single piece of work can take several rounds. About 4,887 of those rows mention Boss or HQ in the title or path (a title match, so it's approximate), and 3,164 of them ended in a pass. The rest came back with a block, partial, fail or concerns verdict, which tells you the reviewers do find things.
A UI fix closes only when a real click proves it. The builder presses the control in a real browser, sees it work, and puts the screenshot in the build report. Code reading and unit tests alone can't close one.
How it's kept safe
- Every way in has its own sign-in. The team app, the homeowner portal, the AI connector and the Telegram bot each refuse on a missing or bad credential, and they don't guess. The connector uses OAuth with a fixed allowlist, and the Telegram webhook gets a constant-time secret check first. Pairing a Telegram account uses a single-use token with a 15-minute window.
- No Worker has a public default address. Every way in has its own sign-in, described above.
- Money visibility has three levels. They're full, committed only, or none, and the highest of a person's roles wins. A hidden amount never shows up in the response at all.
- Every change goes through one door. It checks the role, blocks double submits and edit collisions, and doesn't apply half of a change.
- Every attempt is logged, refused ones too. The audit row names who, from where, and why. Secrets are stripped before anything is written, and a test checks every command.
- Undo works on everyday actions. Undo saves the before-state, is role-checked and logged like any other change, and refuses to overwrite a later edit. A few big actions, like resetting a test job, don't have a single undo, so they ask for a typed confirmation instead.
- The owner can view the app as a teammate to debug. That view has the teammate's permissions, and there's no owner bypass, and the log still names the owner as the real actor.
- The chat bot only proposes. A person taps Yes and the sender's checked again, and money, draws, purchase orders, change orders and budgets can't start from chat.
- The AI reads only what the asker may read. Uncertain doesn't return anything, and if a setting is missing, Telegram message storage stays off.
- Secrets live only in the platform's secret store. A secret scanner runs on every pull request, too.
- Homeowners reach only their own job. Access comes from an expiring grant, and each grant has its own money setting.
- Public upload pages ship a restrictive content-security policy, which is the set of browser rules that limit what a page may load or run.
How it fails, and how we catch it
How problems get caught
- Heartbeats and a watchdog. The scheduled jobs that work on Boss run on Kaizn's own operations system. Each one writes a heartbeat when it finishes, even with nothing to do, and a watchdog flags a stale one. The watchdog judges freshness and ignores exit codes, because a job once failed for six weeks into a channel nobody was reading, and others exited clean for weeks while doing nothing.
- Boss records its own failures. Inside Boss itself, the database has a failure log with 34 distinct entries since October 11, 2026. Repeats collapse into one row with a count.
- One Issues page. It's collecting the issues the team files, those automatic failures (on an Automatic tab), and suggestions made through Claude. 186 issues have been filed, and 159 are closed, 25 are open and 2 are deferred.
- A yes-or-no twice every weekday when something's open. One request asks whether to fix what's open, and the answer is a plain yes or no. A yes starts a fix run with triage, a subagent in its own worktree, two-reviewer verification, merge and ship, and the issue closes only after the fix is read back live. Issue text is treated as data only, and it's never taken as an instruction.
- Fix time. Bugs and feature requests are turned around in under 20 hours on average (19 hours 27 minutes, from Boss HQ's own tracker, October 2026). Half of the 159 closed requests were turned around within about 13 hours (September 18 to October 28, 2026).
- Staging first, by default. Changes are staged and shown before production. Every load-bearing change is checked by two independent AI reviewers before it ships, and a UI fix closes only when a real click proves it. Staging builds use mock documents, so every done-means line can be proved without waiting on real events.
- Rebuild fixed, never revert. A bad merge isn't ever reverted, so it gets rebuilt fixed and merged again. Test-house cleanup tools refuse to run unless the record's id and name both match, and they do a dry run by default.
Four times it failed
The honest gap
Nothing grades Ask Boss's answers yet. The tests check that Ask Boss records its failures, but they can't tell whether an answer's right. The raw material is there, since every question and answer is already stored in a history table and no grader's reading it, and answer-quality evals are the next piece being built.
Who built it
Josh Cross runs Kaizn, an AI coaching and automation business, and Boss HQ is something he built with Claude Code and without formal development training. He's proficient in Make, Zapier and n8n, and these days he wires Claude Code straight into the APIs he works with, like Stripe, MailerLite, Cloudflare, Higgsfield and Google Workspace. He's run nearly 950 million Claude Code output tokens since June 2026, and over 430 million in October alone. He takes a business's real operations, finds the loops it runs on, and builds the system around them, and then he teaches the team to run it.
Want one built around how your company runs?
If a spreadsheet, a pile of tools and a few channels are standing in for the system you need, we'd like to talk.