Stop Redrawing Details Your Firm Solved Ten Years Ago

 

 

We had a chat with Ari Baranian, co-founder of Pirros, to learn how the company is tackling one of the least glamorous time sinks in architecture and engineering: finding the detail your firm has already drawn. Pirros calls itself the AI project hub for architects and engineers. Firms use it to search, reuse, compare, and standardize Revit details and families across every past project. This month it adds QA/QC, a feature that reviews a drawing set from inside the Revit model rather than from a PDF.

Baranian, a structural engineer who co-founded the company with fellow engineer Peter Johann, explains why the product exists, what building QA/QC with beta firms taught the team, and where he thinks AI belongs in an AEC workflow.

In this conversation:

• Why Pirros runs a people-heavy rollout and how that scales
• Where Baranian thinks AI actually belongs in the AEC workflow
• Why two structural engineers built a search tool for Revit content
• How Health Scores and Model Health differ, and why Pirros built both
• What adoption looks like at Arup-sized firms versus regional practices
• What QA/QC catches, and why it lives inside the model instead of on the sheet

Q1: Can you share the story behind founding Pirros and how it addresses key pain points in AEC detail management, such as searching for and standardizing Revit content across teams?

Peter and I are both structural engineers. We spent years on the production side of the industry, and our day-to-day looked like most engineers': detailing connections, coordinating with architects, producing drawing sets under deadline.

What stood out, project after project, was how much time went into searching. Hunting for a detail we knew existed somewhere in the firm's past work. Opening old models that took ten minutes to load, just to copy one wall section. Asking colleagues if anyone remembered which job a particular condition was figured out on. More often than not, we ended up recreating something from scratch that had been solved years earlier.

Pirros is the AI project hub for architects and engineers. It lets firms search, reuse, compare, and standardize Revit details and families across every past project, with controls that prevent blind reuse where it isn't appropriate.

The result is that designers spend less time hunting and more time designing. Standards stop being a static set of files that decay over time and start reflecting how the firm actually works. New hires can tap into decades of institutional knowledge from day one.

BIM managers get real visibility into what teams are reusing, so quality improves continuously instead of degrading between rollouts. And because the platform gets smarter the more a firm uses it, the value compounds with every new project.

"Standards stop being a static set of files that decay over time and start reflecting how the firm actually works."

Building QA/QC

Q2: Pirros is launching QA/QC at AU this September. What did building it actually look like, and what turned out to be harder than expected?

The starting point is what QA/QC looks like at most firms today. Someone sits down with a massive sheet set and goes page by page, hunting for code compliance issues, leaders that don't land on geometry, misspellings, and more. It's slow, it's manual, and it happens late, usually right before a set goes out.

Anything that slips through shows up as an RFI. That's expensive, and a set full of avoidable errors does real damage to a firm's reputation with its client.

We wanted to replace that manual review: not just make it faster, but catch the same problems earlier and automatically. That's also why QA/QC couldn't be one more standalone check sitting at the end of a disconnected process.

The whole reason Pirros exists as a platform is to connect a team's workflow end to end. Figuring out what details belong in a project. Using Mira, our AI Revit agent, to speed up modeling. Collaborating through stashes and building sheets. Then QA/QC and Model Health at the end.

QA/QC only does its job well if it can see everything that happened upstream, and if it replaces a slog someone used to do by hand instead of adding another manual step somewhere else.

None of that is something you can spec correctly from the outside. So we built QA/QC with a group of firms as beta testers on live projects.

A lot of what's in the feature exists in its current form because they told us where an assumption we made didn't hold up against how their teams actually review a set.

That's also why AU felt like the right place to launch it. It's the room that understands what that manual grind costs, and we wanted to show up with something shaped by firms who've felt it firsthand.

"QA/QC only does its job well if it can see everything that happened upstream."

Q3: You've described search and reuse as the foundation of Pirros. QA/QC feels like a different kind of product: it checks a model for code compliance and quality issues rather than helping teams find and reuse content. What was the thinking behind building it, and how does it fit into the bigger picture of the platform?

QA/QC came out of the same instinct as everything else we build: watch where teams lose time, then build the thing that gets it back. Search and reuse solve the front end of a project, finding and placing the right content. QA/QC solves the back end, catching problems before a drawing set goes out the door.

The distinction that matters is that QA/QC is connected to the actual Revit model, not just the PDF sheet. Most QA tools scan a set of drawings and hand back a list of issues for someone to interpret and chase down in the model by hand.

Because QA/QC sits inside the model, an issue can be assigned to a specific person, and there's a resolver where it gets fixed directly. Nothing gets written up somewhere else and translated back into the model later. It turns an audit into distributed, tracked work instead of a static document nobody circles back to.

The rules are the firm's own, too, not a generic checklist. QA/QC checks a project against code compliance, but also against whatever standards a firm sets for itself, and those checks can be customized to the region a project is in.

Model Health lives inside QA/QC as its own tab and does something related but distinct. Instead of finding problems in the documentation, it scores the underlying Revit model on a 0 to 100 scale against thresholds each firm sets. That score is tracked over time, so a model that's drifting shows up before it becomes a problem on a deadline.

"It turns an audit into distributed, tracked work instead of a static document nobody circles back to."

Two scores, two jobs

Q4: You already have Health Scores for details and families. Now there's Model Health inside QA/QC too, also scoring things out of 100. How are those two different, and why build both?

They sound similar because they use related scoring logic, but they're pointed at two different things.

Health Scores grade the individual details and families in a firm's library, the reusable pieces everyone pulls from project to project. Each one gets a color-coded score from 0 to 100, checked against factors like misspellings, bad tags, or leader lines that don't land on geometry.

A BIM manager can see what needs cleanup before it gets reused across ten more projects.

Model Health, inside QA/QC, scores the actual Revit model on the project someone is working in right now. It runs across 21 metrics grouped into categories like file size, warnings, imports, worksets, and documentation.

The firm decides how to weight those categories, so the score is tailored to its own specifications. It's read-only and never edits the model directly.

 

Rollout and adoption

Q5: Your implementation approach is unusually people-heavy for a SaaS company: co-building standards libraries, white-glove onboarding, change management inside active projects. Most software companies treat that as a cost to minimize. Why have you leaned into it, and how does it scale?

The philosophy comes from watching adoption fail in this industry over and over, for the same handful of reasons.

A firm buys a tool with the best intentions. Someone schedules a training session, the vendor delivers a feature walkthrough, and everyone moves on. A few weeks later deadlines compress, the team falls back on whatever felt familiar, and within a year the tool is being used by maybe a third of the people it was bought for.

Leadership eventually asks why the investment didn't pay off, and the answer is almost always that nobody owned the rollout once the contract was signed.

So we decided to own that part ourselves. Not as a goodwill gesture, but because the platform's value only shows up when it's embedded in how teams work.

In practice, that means we map a firm's workflows before any training begins. We work alongside the BIM team to bring their standards library into the platform together, rather than handing them a system and walking away.

Once teams start using it, we sit inside the early projects where the work is happening, so questions get answered in the moment rather than three weeks later at the next training session.

We come back at 30, 60, and 90 days, because the workflows that felt right on day one are almost never the workflows the firm wants three months in. Treating enablement as a one-time event is most of what goes wrong with rollouts like this.

As for scale, it works because the platform does most of the heavy lifting that would otherwise sit on a customer success team. Content gets ingested, organized, and made searchable within the first day.

Our team isn't spending its time on data entry; it's spending it on workflow design and the parts of the rollout where human judgment matters.

And the methodology travels across very different firm sizes and disciplines with the same shape each time: intensive at the start, where it makes a difference, then a much lighter ongoing presence once the platform has become part of how the team works.

"The answer is almost always that nobody owned the rollout once the contract was signed. So we decided to own that part ourselves."

Q6: Pirros is trusted by firms like Arup, Thornton Tomasetti, and Populous, which are very different in scale and typology. What does adoption look like at a large global firm versus a smaller regional practice? Is there a "sweet spot" firm profile where Pirros delivers the clearest ROI fastest?

What Pirros delivers shifts with the size and shape of the firm.

At a large global firm like Arup or Thornton Tomasetti, the most valuable thing the platform does is consolidate decades of distributed work into something the whole firm can see and use.

An engineer in London can search the same library of past project content that a colleague in Sydney built from. Standards that used to drift between offices stay aligned. Cross-discipline coordination gets easier, because the structural and architectural sides of the firm are working from the same searchable history.

At that scale, the deeper value is turning a federated firm into an organization that learns and improves as one.

At a smaller regional practice, Pirros plays a different but equally meaningful role. There's usually one person holding the firm's standards together, often a senior architect or BIM lead doing it on top of billable work, and the platform takes a significant amount of that burden off their shoulders.

Designers feel the time-back benefit of search and reuse immediately. The firm's accumulated knowledge stops living in the heads of two or three senior practitioners and becomes something a junior designer can tap into from day one.

That also helps smaller firms compete with much bigger ones, because the depth of institutional knowledge they bring to a project no longer depends on headcount.

The clearest predictor of fast ROI isn't firm size. It's the conditions inside the firm: enough accumulated project content for the platform's intelligence to learn from, a BIM lead or design technologist who feels the pain and can champion the rollout, and leadership willing to move at the pace the work requires.

When those conditions are in place, value shows up quickly regardless of headcount.

"The depth of institutional knowledge they bring to a project no longer depends on headcount."

 

Where AI belongs

Q7: Across AEC tech, tools are moving quickly from file management into active AI assistance inside design software. Where do Pirros and Mira fit five years from now? Do you see the platform growing beyond detail management into a broader layer of design intelligence?

A few years ago, the problem in AEC was that there weren't enough tools. Today the problem is the opposite.

Open LinkedIn any week and there are five new AI products launching, each promising to revolutionize some sliver of the workflow. Firms buy them, trial them, abandon them, and start over with the next batch.

Most won't exist in two years. The ones that survive will be one more login, one more dashboard, one more thing for an already overstretched team to learn and forget. Software fatigue in AEC is a real cost.

What's worse is the direction a lot of this AI is pointing in. There's a growing list of products built around the idea that AI should do the design work itself: generate the floor plan, write the spec, draft the detail from scratch.

Architects and engineers are rightly skeptical. The years they spent in school, and the longer years building expertise, are exactly why that work shouldn't be handed off to a model.

Where AI belongs is in the production layer underneath the design.

The hours spent hunting for a detail in a previous project. The version mismatches between Revit releases. The sheets assembled by hand for the hundredth time. The quality issues caught one detail at a time.

That's the work Pirros is built around.

The whole point of calling ourselves the AI project hub is that we want to keep expanding into the parts of the production workflow that architects and engineers were never supposed to spend their time on in the first place.

Five years out, the industry won't be running on a hundred point solutions. It will consolidate around a small number of platforms that connect the work end to end.

The firms that pick well now will be operating at a different level from the ones still patching together twenty disconnected products. Pirros is being built to be one of those platforms.

"Five years out, the industry won't be running on a hundred point solutions. It will consolidate around a small number of platforms that connect the work end to end."

The aec+tech takeaway

Pirros started with a complaint every production engineer recognizes: the detail exists somewhere, and finding it takes longer than redrawing it. Search and reuse answer that directly.

The more interesting part is where the company is heading. QA/QC moves drawing review from a late, manual, sheet-by-sheet pass into tracked work assigned inside the Revit model, checked against rules the firm writes for itself. Model Health flags a drifting model before a deadline exposes it.

And the rollout model, with check-ins at 30, 60, and 90 days on live projects, answers the way BIM tools tend to die quietly after the first training session.

Baranian's framing is the one to hold onto: keep AI in the production layer underneath the design, and let architects and engineers keep the design.

To learn more about Pirros, visit their page on aec+tech or explore more on the official Pirros website.