ContractorKeith on june 20 i wrote about contractor-bid 0.2.0, the free cli that turns a bid invite into a package you can check. that post ended with “tell me where the next bid folder is still dumb.”
eighteen days later the answer is a whole suite. here is what got built, with screenshots from the actual apps, running on my machine this week.
the decision that shaped everything else
first, the call that set the direction: the paid product is not the cli. nobody wants to buy a license key for a terminal tool, and i stopped pretending otherwise.
the free engine stays MIT-licensed and local, forever. the thing worth paying for is the app built on top of it: a shared bid command center for a subcontractor team. working name, Contractor Takeoff.
so the two weeks split three ways. keep improving the free engine. build the team app around it. and grow the plan markup tool into something that can live inside all of it.
the free engine got an installer and a front door
contractor-bid shipped 0.2.1 and 0.2.2 in this window. the headline is boring and important: you can actually install it now.
brew install ContractorKeith/tap/contractor-bid
# or
pipx install "contractor-bid[mcp]"tagged releases build themselves when i push a tag. there is a real docs site now (MkDocs on GitHub Pages), a fictional fences-and-gates demo project in the repo so you can run the whole pipeline without touching real bid documents, and a recorded terminal demo. 0.2.1 also consolidated the pipeline outputs because the first version wrote too many overlapping files.
small releases. but “installable in one line” is the difference between a repo people star and a tool people run.
Contractor Takeoff: the bid command center went pilot-ready
this is the big one. 80 commits and 18 feature branches landed on the Django app since june 20, and the v1 feature set from the PRD is done.
that dashboard is the seeded demo workspace: a fictional fence company with five bids in different stages. one command builds the whole thing, demo login, documents, notes, and a pre-run document review included. i can hand anyone a working demo in about a minute.
the piece i care most about is what happens inside a bid. the free engine’s triage now runs inside the app, and every finding it raises carries its evidence with it: the source pdf, the page, the sheet number, and the quoted text it matched.
a finding is not a chat answer. it is a claim with a citation, and a human marks it reviewed, important, or dismissed. those review states persist, so when an addendum drops and the engine re-runs, the team does not re-review the forty things they already settled. the app only surfaces what changed.
around that core, the window added: addendum review as its own engine run, team notes with dated decisions that survive even if a member leaves, workspace trade profiles (22 CSI divisions plus my fences-and-gates one, so a drywall shop and a fence shop get different scope flags), an export packet that reflects review states, and the unglamorous deployment work. Postgres, Redis, private object storage, the works. 143 tests pass on the app alone.
next step is not more features. it is putting a pilot instance in front of real estimators and watching where they get stuck.
Plan Markup became three apps from one codebase
the markup tool i started in june kept its pace: 34 commits, about 19,000 lines added across 170 files, and the test count went from 314 to 364.
the desktop app now covers the daily-driver features i actually reach for in Revu. stamps (text and image), right-click context menus, search across a whole plan folder with ⌘F, endpoint snapping while you draw, and overlay alignment that can transfer markups between plan revisions through a review queue, so nothing moves onto a new sheet without me accepting it.
that is my own screenshot from a real bid set i shook down this week (title block cropped for the client’s sake).
but the bigger move was architectural. the markup and takeoff logic got extracted into a framework-free core package, and now one codebase ships three ways: the Electron desktop app, an embeddable viewer that mounts inside the Contractor Takeoff document pages, and a standalone web app.
the standalone web app is the one that surprised me. it runs entirely in the browser. no server, no account, no upload. folder mode uses the browser’s file system access to write the same sidecar files the desktop app writes, right next to your pdfs.
that screenshot is a real takeoff in a browser tab: a fictional site plan, page scale set to 1” = 20’, four fence runs measured, gates counted, 810 linear feet totaled in the drawer, one click to csv. the sheet is a sample i generated so i could demo without publishing anyone’s drawings.
and because every mode reads and writes the same sidecar format, a markup made in the browser opens on the desktop. the pdf never gets touched.
the suite got a front door too
the marketing site went from nothing to built in this window: contractortakeoff.ai, a static Astro site with the suite pitch, a security page that explains the local-first stance, an honest comparison page, and a done-for-you pilot setup offer.
the hero line took a while: “run every bid from one command center.” the first five words have to correct the expectation that “takeoff” means computer vision measuring your plans. it does not. the app organizes the bid; the measuring stays human, in plan markup, where you can see it.
the tally
june 20 to july 7, across four repos: two engine releases, 80 commits on the app, 34 on plan markup, a marketing site, and roughly 500 automated tests green between them. one person, plus a crew of ai agents doing the swinging.
that crew is its own story. how the planning, the parallel worktrees, and the project memory actually work is the next post.