About

Built from both sides of the problem.

I build the systems I needed when I was the one producing the paperwork.
Twelve years in enterprise product leadership. Three years inside residential construction operations.
Construction OS came out of the overlap.
Justin Yurasits — Boston, MA
Today
What I do now.
I build operating systems for construction companies—configuring Construction OS around how a company actually works, or building something purpose-made when nothing off-the-shelf fits.
I’ve written the scopes, produced the change orders, managed trades, and been responsible for work in the field.
Where this came from
I’ve held the license, run the jobs, and produced the paperwork.
Product thinking applied from inside the operation. That’s where Construction OS came from.
License
Massachusetts Construction Supervisor License
The work
Three years in residential construction as project manager and site superintendent, running $1M–$4M renovations at a $50 million contractor.
What I built
The construction document library, operating procedures, and standards came from running those jobs. The AI systems were built out of the problems encountered doing that work, and have been used on roughly twenty real jobs and bids.
I ran $1M–$4M renovations at a $50 million contractor as a licensed Massachusetts Construction Supervisor.
I learned how estimates get built, how documents get produced, and how information moves between the office and the field.
And where experienced judgment is the only thing keeping a process running.
Before that
Twelve years building enterprise software products: Optimizely, as Principal Product Manager on generative AI and data-science products. Fidelity Investments, a digital customer-account platform used by millions. Jabra. Most recently, Citizens.
What I found
It wasn’t really a software problem.
The software existed.
The problem was that the operation hadn’t been made legible enough for it to work.
Valuable knowledge lived in experienced people—and left with them when they did.
Operating standards existed, but not in a form anyone could consistently use.
Repetitive production work consumed time that should have gone to judgment.
Most tools required the work to adapt to the software, not the other way around.
The business couldn’t scale what was working because it wasn’t written down anywhere useful.
The technology was ready. The operating knowledge wasn’t in a form the technology could use.
You can’t automate what the business hasn’t made legible.

The first step is making the operation legible: capturing the knowledge, standards, and procedures that live in experienced people and putting them into a form the work can actually use.

Then the tools and systems are built around how the business operates—not around how a generic product assumes it should.

When the structure is right, the predictable work comes off the team and attention goes where it actually matters.

That is the premise Construction OS is built on.
The team
Two people. Two halves of the same problem.
I designed, architected, and built Construction OS—the document library, standards, pricing logic, product architecture, and working systems built around them.
Ava builds the engineering and the agents. She’s developing the configuration layer that will let the same underlying system be adapted company by company instead of rebuilt from scratch each time.
The construction knowledge, product architecture, and engineering live close together. That’s why Construction OS reflects how the work actually happens.
Justin Yurasits
Co-Founder — Construction / Product
Designed, architected, and built Construction OS.
Massachusetts Construction Supervisor License, three years inside residential construction operations as a project manager and site superintendent, and twelve years in enterprise software product leadership before that.
I define the product architecture, write the specifications, and build the systems.
Ava Yurasits
Co-Founder — Engineering
Builds the engineering and the agents behind Construction OS. Is developing the configuration layer that will let the system be adapted company by company rather than rebuilt from scratch.
Ava also works in clinical automation and operations, where the same underlying problem appears in a different industry: the knowledge that makes software useful often lives in the person doing the job rather than in the system itself.
The software isn’t the hard part. Getting a business’s own knowledge into a form software can use is.
What that became
Construction OS grew out of the work.
01
Document Workbench
Produce company-standard construction documents from first walkthrough through closeout.
02
Construction Intelligence
Put your company’s procedures, standards, pricing judgment, and operating knowledge within reach of the team.
03
Project Intelligence
In development
Surface the exceptions and unresolved work that need attention across active projects.
Extension layer
Operations Automation extends the system into recurring operational workflows.
Built from real construction work.
The document library behind Construction OS—110 distinct construction document types across five lifecycle phases—grew out of the workflows, document patterns, and operating knowledge from running $1M–$4M renovations at a $50 million contractor. The AI systems were built out of the problems encountered doing that work, and have been used on roughly twenty real jobs and bids.
It wasn’t assembled from a generic template pack.
About
Tell me about the problem.
Bring me the problem your team is tired of dealing with.
Book a call See how an engagement works
Most conversations start with one of these.
You have more work than time to do it well.
A process is held together by one person’s experience.
The same question gets asked—and re-answered—every week.
The business has grown, but the way the work gets done hasn’t kept up.