BuilderHelp
A construction platform that had to work in the office and on a jobsite with one bar of signal.
- Client
- BuilderHelp, LLC
- Year
- 2026–
- Role
- Design + Development
- Live
- Website
Residential and commercial builders run on a stack of disconnected tools: a spreadsheet for the budget, a text thread for the crew, a filing cabinet of supplier invoices, and a folder of PDFs nobody can find. BuilderHelp replaces that with one system of record — and then has to be usable by a project manager at a desk, an owner checking progress from their phone, and a framer standing in the mud.
Three audiences who share data but share nothing else
A builder's software has to serve people whose jobs have almost nothing in common. The office needs invoicing, change orders, subcontractor payments, RFIs, submittals, and budget tracking — dense, detail-heavy screens. The homeowner needs a calm view of progress and a way to approve things without learning construction vocabulary. The field crew needs to photograph a receipt with cold hands and get back to work.
Build one interface for all three and you get software that everybody tolerates and nobody likes. The design problem was to keep a single source of truth underneath while letting each surface be shaped entirely by who's holding it.
Four codebases, one source of truth
The web app is the system of record — projects, invoicing, the owner portal, and staff admin, built on Next.js with MongoDB behind it. It owns the API that everything else talks to.
The field app is Expo and React Native: receipt scanning, jobsite photos, schedule access, and RFI responses, designed for one-handed use and intermittent signal.
The marketing site is its own deploy, so pricing and lead-capture changes ship without touching the product.
And a Python OCR microservice reads supplier invoices, extracts line items, and posts them back to the web app — the piece that turns a photographed receipt into a budget line without anyone typing.
Money, and the fact that it has to be right
Payments were the least forgiving part of the build. Subcontractor payments run through Stripe with both cards and ACH via Financial Connections, and the system carries a second provider as an alternative path — because a payments integration you can't swap is a business risk, not just a technical one.
Getting that wrong doesn't produce a bug report, it produces a subcontractor who didn't get paid. So the money paths are the most conservative code in the product: explicit state, no silent retries, and reconciliation that assumes the network lied.
AI that does the boring work, not the impressive demo
The AI features are deliberately unglamorous. A one-click owner update pulls budget status, schedule health, and progress since the last update, then writes the narrative a PM would otherwise spend twenty minutes drafting. Daily logs, invoice reconciliation, and schedule optimization work the same way — they compress work that already existed rather than inventing a new thing to learn.
It runs through the Vercel AI SDK, which keeps the provider a configuration detail rather than an architectural commitment.
Four repos that deploy independently
Each surface is its own repository, tracked as a submodule from a parent repo whose only job is recording which commit of each piece is live. Web and marketing deploy on Vercel; the mobile app builds through EAS.
That means a marketing copy change doesn't redeploy the product, and a mobile release doesn't wait on the web app. It also means the App Store and Play Store review cycles — which are their own kind of engineering problem, from scoped-storage permission changes to OAuth production verification — stay isolated from everything else.
