Bringing AI into a complex construction product

Turning project documents into tasks and inspections automatically, inside an app built to hold two very different products

At TidalHaus I brought AI into a construction product so it could read a project’s documents and turn them into the tasks and inspections a team has to run, automatically, instead of making people create each one by hand. I did that inside an app I had to reshape first, so a legacy AR product and a new sheet-management product could live together without feeling like two apps bolted into one.

The AI features became the product’s competitive edge

The new sheet product entered a market with a few well-established competitors, and it needed a reason to be chosen. I found that reason in AI, and it became the product’s edge.

Construction runs on documents. Buried in a project’s plans and specs is a long list of the tasks and inspections that have to happen, and until then a person had to read all of it and recreate each item in the software by hand. The AI features I proposed and designed changed that. The product reads a project’s documents and turns them into structured tasks and inspections automatically, files newly added sheets in the right place on its own, and builds a field walkthrough that tells inspectors exactly where to go and what to check. Work that used to mean hours of manual setup arrives mostly done.

Alongside the AI work, the onboarding and activation redesign and the design system behind it contributed to a significant increase in trial sign-ups.

This is the case where I put AI into a real product, in production, in front of users, and where the AI was not a bolt-on feature but the product’s competitive strategy. It shows several things the best AI product roles ask for: competitive and user research turned into a product direction, a proposal taken to leadership and shipped, dense and technical input turned into clear product logic, automation designed to be trusted and corrected, and a complex two-product platform held together across mobile and web. It also shows the less glamorous Staff work, taking a problem shaped by a small team, a legacy product, and what sales and engineering could each take on, and finding the path that actually shipped.

The work had two problems stacked on top of each other.

The first was inherited, and it was as much organizational as visual. The company’s original product was built for AR on construction sites, and it was built by engineers before the company had a designer, so it had never had a proper design pass. A redesign sat on the roadmap, but the team was small and the effort was large, so it kept getting deferred. Then the company pivoted and decided to build a second product, for sheet management and annotation. Sales wanted that new product to look and feel like the established competitors, so it would feel familiar to buyers and be easier to sell. Engineering did not want to fix the legacy design and build a new product at the same time.

That left one realistic path, and it landed on design. Both products had to live in the same app, on mobile and web, and they could not look alike. The AR product was dark and built for the field. The sheet product had to be light and feel like the document tools people already knew. My job was to make two products that could not match feel like one coherent app, not two apps sharing a login.

The second problem was competitive. The sheet product was entering a market with a few established players that buyers already knew and trusted. Looking familiar was the price of entry, which is what sales wanted. But familiar on its own does not win. The product needed a real reason to be chosen over the incumbents, and finding that reason was a design and strategy problem as much as a UI one.

I turned a constraint into a coherent product

I could not redesign the legacy product, and the new one had to follow familiar patterns, so the two were always going to look different. I made that difference work instead of fighting it. I gave the app one shared structure, one navigation model, and a design system that could carry two visual modes: a dark mode for the AR and field work, and a light mode for the sheet and document work. The surfaces stayed distinct, on purpose, while the bones underneath stayed the same. That is what kept it feeling like one product a person moves through, rather than two things bolted together.

I found the product’s edge through research

To decide where to differentiate, I ran a competitive analysis of the established players, mapping their features, strengths, and positioning, and set that against our own research into what users actually needed. The gap between what competitors offered and what the field genuinely struggled with was where the opportunity lived, and it pointed at one thing: the manual, document-heavy setup work that every product in the category still made people do by hand. With that whole picture in front of me, I took a proposal to the leadership team for a set of AI features that would turn that shared pain into our advantage.

I designed the AI features that became the differentiator

The proposal became three features:

• The product reads a project’s construction documents and creates the tasks and inspections cited in them automatically, instead of making someone transcribe each one.
• It recognizes sheet numbers and names and files newly added sheets into the right place on its own.
• It builds a walkthrough for inspectors in the field, so they know exactly where to go and what to inspect.

Together they moved the product from one more sheet tool to one that does the tedious reading and planning for you.

I kept a person in the loop

Because these are real construction tasks and inspections, people cannot blindly accept whatever a model generates. I designed the features so their output is something people can see, check, and correct, rather than a black box that fills the app on its own. The aim was to remove the typing without removing the judgment, so the automation earns trust instead of demanding it.

I owned the design system across surfaces

I built and evolved the design system across iOS, iPad, and web, so both products stayed consistent and quick to ship even as they kept changing. The system is what let a small set of decisions cover a wide and growing product, which mattered a lot on a small team.

I worked AI-native, with a clear read on its limits

For the main screens, I used AI to generate design directions and early ideas, and treated the output as inspiration rather than finished work. The models at the time were nowhere near producing polished, production-ready design, so I used them where they genuinely helped, opening up options fast, and did the craft myself. Knowing where AI adds value and where it does not is part of how I work, and it kept exploration quick without handing the quality bar to a machine.

The decision I owned was how to handle two products that could not match. Forcing one look would have meant either redesigning a legacy product the team had no capacity to redesign, or stripping the new product of the familiarity sales needed to sell it. Neither was worth it. So I unified the structure and let the surfaces stay different, dark for the field, light for documents, coherent underneath. Some visual uniformity went out the window on purpose, because coherence for the user is about moving through one predictable app, not about every screen looking identical. Given the team’s size and what each side of the business needed, I would make the same call again.

The best AI features I have worked on remove the busywork and leave the judgment. People will hand a machine the tedious reading and typing gladly, as long as they stay in control of the decisions that carry risk. And the constraints made the product better than a free hand would have. Because I could not unify the two products by force, I had to find the coherence that actually mattered, which was shared structure rather than identical surfaces. Make the bones the same, and two very different things can still feel like one.