40x faster document search for construction teams

Customers were working around us

We talked to architects, engineers, contractors, and GIS analysts. The pattern was clear: customers weren’t asking for better search. They’d given up. They were actively avoiding Studio Projects.

At multiple companies, it was best practice to not use Studio Projects. Because it was too painful.

The industry had moved on

Between 2018 and 2023, AEC data storage grew 8x while time spent searching doubled to 13 hours per week. ^[1][2] The industry recognized the crisis: 58% of construction firms were investing in new technology specifically for better data access. ^[5]

Meanwhile, Bluebeam had never leveraged basic indexing capabilities. We were way behind the times.

We own the ecosystem

Studio Projects house redacted of files. We own the data, the platform, and the workflow. If anyone should be able to search construction documents effectively, it’s us.

But our products were fragmented. Studio, Revu, and Cloud existed in silos. No centralized projects. No unified document storage. Search couldn’t exist in one product — it had to bridge them all.

The forcing function

Leadership’s directive: become an AI-centric company in 2024. Search was the foundation. You can’t build AI features on fragmented data.

But search also forced a harder conversation: product unification. You can’t build effective search across silos. Building search meant confronting the architectural fragmentation we’d been avoiding.

Search wasn’t just a feature. It was the wedge that would force Bluebeam to evolve from a collection of tools into a unified platform.

Don’t index the world. Index what matters.

The obvious approach: crawl and index all of Studio upfront. Every project, every file, immediately searchable. That’s the best user experience. It’s also redacted upfront, redacted/month to maintain.

The tension: Do we pay for perfection, or find a cheaper way that’s still good?

I asked: What if we only crawl a project when someone actually searches it?

Most projects would never need indexing. And the ones that did would index fast:

The tradeoff: a ~1 minute wait on the very first search of a project. Every search after that is instant. The user’s intent — “I want to search this” — becomes the signal to index. No “Make Searchable” button. No setup. Just search.

Concurrent segment search: perception of speed.

Even with ad-hoc indexing, a full crawl takes ~60 seconds. Users won’t wait. The design challenge: how do you make 60 seconds feel fast?

The answer: don’t make them wait at all. As each segment finishes crawling, we search it immediately and stream results — newest files first. The target often appears in 10–15 seconds, while the rest indexes in the background.

Why it works psychologically. Seeing 12 results at 2 seconds, then 29 at 4, then 47 at 6 feels instant — even when the full index takes 60. A blank screen for the same 60 seconds reads as broken instead of working. That first interaction decides whether users trust search or go back to folder trees.

The tradeoff. Relevance ranking (BM25) needs global statistics — how rare a term is across all files. Stream before the crawl finishes, and those stats are incomplete. The top result might be 3rd-most-relevant, not 1st.

Why that was fine. AEC search is retrieval, not discovery. Users aren’t exploring — they’re after “A-201” or “RFI-247,” things they know exist. As long as the target is on the first page, its exact rank doesn’t matter. And indexing newest-first wasn’t a guess: document access follows a power-law, with ~90% of accesses targeting files less than a year old. ^[6] We indexed in the order users needed results.

Search on Enter, not on every keystroke.

Modern search feels live — results updating with every character, Google-style. The design question: does that fit how construction professionals actually search?

It doesn’t. Live search assumes you’re exploring, refining a vague query as you watch results shift. But AEC users type things like “A-201” or “ELEC-PANEL-3B” — exact identifiers they already know. They’re not browsing toward an answer. They have one in mind.

So we search on Enter. The user composes the full query, commits, and gets one clean set of results — no flicker, no half-formed matches for “A-2” before they finish typing “A-201.”

It was also the responsible choice technically. Every keystroke is a query. Live search on “ELEC-PANEL-3B” fires a dozen queries to answer one question. Enter fires one.

Filters that narrow, never expand.

A single query can match in three different places: inside a file’s content, in its name, or in its folder’s name. By default, we search all three — so a search for “conduit” surfaces a file named conduit-detail.pdf, a file containing the word, and anything inside a folder called /conduit/.

The design question: how do users narrow to just the kind of match they want — without learning a query syntax?

Checkboxes, with one rule users never have to learn: nothing checked → search all three. Something checked → only that. Check “File names” and “Folder names,” and you get either — an OR between selections.

The tradeoff: no compound logic. You can’t express “file names AND modified this week” as a strict AND. Everything across selections is OR. But Boolean filter builders are where simple search UIs go to die. Predictable beats powerful when the user just wants to narrow a list.

Every dead-end needs an exit sign.

Search has more ways to fail than most features. The project isn’t indexed yet. A file got deleted after it was indexed. The user doesn’t have permission to the file they just matched. The connection drops mid-crawl. Each of these is rare individually — but across a system this size, every rare failure is somebody’s Tuesday.

The easy path is a generic error: “Something went wrong.” The design work was making each failure tell the user what happened and what to do next.

• No results → not just “0 results,” but a nudge: check spelling, broaden terms, or “this project may still be indexing.”
• No permission → matched files the user can’t open are hidden entirely, not teased. A locked door you can see is worse than one you can’t.
• Offline → “Connect to search,” with the last results still visible — not a blank, broken screen.
• Stale index → a file deleted after indexing drops from results on click rather than opening a dead link.

The principle, borrowed from any well-run job site: never leave someone stranded. Every dead-end gets an exit sign.

Measure time-to-open, not engagement.

The default way to measure a feature is engagement: searches per user, time spent searching, weekly active searchers. Every one of those would have been the wrong target.

Engagement metrics assume the activity is the value — more searching means a healthier product. But nobody wants to search more. They want to search less: find the file, get back to work. Optimizing for time-spent-searching would mean celebrating the exact thing users were trying to escape.

So I started somewhere else: forget the product for a second. What does the user actually want? To open the right file. What are they doing to get it? Searching. How well is it working? Time-to-open — the seconds from typing a query to the file on screen.

That became the primary metric, with a target: under 30 seconds, end to end. It’s honest because it captures the whole journey — query, crawl, results, click, open. If indexing is slow, ranking is off, or the open is clunky, the number moves. One metric, accountable for the entire experience, pointed at the only outcome the user cares about.

Press coverage

More coverage: GlobeNewswire, Nemetschek Group, ENR, EngTechnica, Seiler Design Solutions, Brighter Graphics

Official sizzle reels

Unbound 2025 keynote

Intelligent Search presented by Bluebeam Founder Don Jacob