Building in public: the founding contractor program

Construction has been sold a lot of software that looked great in a demo and fell apart at the first month-end close. Most contractors we talk to have a story: the suite that promised to replace everything, the integration that worked until an upgrade, the dashboard nobody trusted because nobody knew where its numbers came from.

We don’t want to be another one of those stories. So we’re building os.construction in the open, with a group of founding contractors who use the product early, tell us where it’s wrong, and decide what gets built first.

This post explains what that means in practice.

Why build in public

Two reasons.

The work is too specific to guess. A change order at a commercial GC doesn’t flow like one at an electrical sub. A WIP schedule a surety wants isn’t the one a lender wants. Retainage rules change by state and by contract. You can’t design for that from a whiteboard. You design for it by sitting with the people who do it every month and watching where the numbers go.

Trust has to be earned. Contractors are right to be skeptical of software claims. The best answer we have is to show the work as it happens: what’s ready, what isn’t, and what we changed because someone told us we had it wrong.

There’s a practical reason too. The hardest parts of construction software aren’t the screens. They’re the edge cases: a change order approved in two pieces, a sub paid by joint check, a retainage reduction negotiated halfway through a job, a cost code structure that grew over twenty years. Those only show up when real contractors push real jobs through the system. We want to find them early, with people who expect to find them, instead of after a company has bet its month-end close on us.

What founding contractors get

Early access first. Founding members get in before anyone else, in waves, as each piece is ready for real work.
Founder pricing, locked. The first contractors on board get founder pricing. Details go to the founding cohort directly.
A direct line to the team. Not a ticket queue. Your workflows, your imports and your reports shape what we build first.

What we’ll ask in return

We’re asking for honesty more than time. In practice, that will mean:

Show us how it works today. A redacted pay app, your WIP template, your change order log, your cost code list. The artifacts teach us more than any survey.
Tell us your stack. Which PM, accounting and reporting tools you run, and where the seams hurt. That decides which migration paths we build first. We’re planning import paths from Procore, Sage, QuickBooks and Vista for the things you can’t start over without: jobs, cost codes, vendors, commitments and open balances.
Tell us when we’re wrong. Especially about the accounting. If the controller doesn’t trust it, nothing else matters.

Who it’s for

General contractors and specialty contractors who run the job in one system and the books in another, from the super and the PM to the controller and the CFO. If your team re-keys data between PM software, accounting and a WIP spreadsheet, you’re who we’re building for. Owners and developers are welcome too; you sit on the other side of every pay app and change order, and that perspective matters.

How we’re deciding what to build first

We rank work by where the seams cost the most, in money and in risk, not by what demos well. Roughly:

The change order path. Field issue to RFI to CO to budget, commitment and pay app line, on one record. It touches everyone, and it’s where approved money most often goes unbilled. We walked through it in the real cost of re-keying a change order.
Job cost that’s current. Invoices coded to cost codes and matched to commitments as they arrive, so cost to date is true on any given day.
Billing on the same record. Schedule of values, AIA G702/G703, retainage and lien waivers, tied to the ledger.
WIP as a view. Once the first three are right, live WIP mostly falls out of them.
Agents on top. Only once the record underneath is solid, and always with approvals.

That order will change as founding contractors push back on it. That’s the point.

Where we are. We’ll update this in the changelog as it moves.

What “in public” means here

A changelog. Every meaningful change to the product and the site goes in the changelog, newest first.
Docs that say what’s real. Product docs are labeled preview or planned until they describe something you can use.
This blog. We’ll write about how construction money and data actually move, what we’re learning and what we got wrong.
No invented proof. You won’t see customer logos we haven’t earned, testimonials we wrote ourselves, or statistics we can’t source. When we have real results from founding contractors, and their permission, we’ll share them.

What we don’t know yet

Building in public means saying this part out loud:

Launch timing. There’s no public launch date. Founding members get access first, in waves, when each piece is ready for real jobs.
Which integrations come first. That depends on the stacks founding contractors bring.
Field details. How phone and offline workflows should behave for crews without signal is being shaped with the people who work that way.
Pricing details. Founder pricing is locked for the cohort; the specifics go to the cohort first.

We’d rather leave a question open than answer it wrong.

Joining

If you run the job in one system and the books in another, and you’re tired of being the integration between them, get early access, or read the full founding contractor program and apply there. Tell us your role and your stack when you sign up. The first contractors in shape what everyone else gets.