Managing construction defects (snags) on small-scale projects through a SAAS platform.
Tailored to construction stakeholders involved in small projects.
SnapSnag. Utilising AI prototyping to build a MVP.
Snag (n): a minor defect or outstanding work that needs to be addressed.
AI prototyping | July - August 2025
Problem: Construction stakeholders need to formally record site defects with ongoing works, usually numbering around 20 to 50 per week for a small project. To log and communicate this effectively to other stakeholders, they either use expensive, complex software designed for large construction projects or informal, slow methods that are inefficient and prone to human error.
Solution: A simple platform for creating and organising site snags, able to generate simple reports for coordination with the larger project team.
Project timeline: One month from research through to initial user testing.
Read the full report below or try the Lovable prototype here.
Project inspiration
The project idea sparked when family members renovated their house, moving back into an unfinished property near project completion.
They struggled to manage numerous ongoing issues with various tradespeople, facing defects like loose door handles, flickering lights, and incomplete paintwork. Lacking construction experience, they found logging and reporting amidst the chaos of ongoing works overwhelming, as they juggled daily life with closing the project out. This experience highlighted a clear need for a simple, effective solution.
This mirrored a challenge from my architectural career, where documenting site reports was tedious, often involving a combination of photos and written notes from site, taken back to the office and compiled into emails and reports for stakeholders. Working on larger projects introduced me to various software options, all of which were complex and expensive tools designed for advanced teams working on big-budget projects, and is completely ill-suited for smaller works.
Surely there should be a way to help those involved in smaller projects to manage, track, and coordinate ongoing site issues effectively?
Competitors: Expensive, complex software, tailored to teams with extensive requirements. Pictured above: SnagR.
Understanding the User
Fewer features = Simpler product
While my knowledge of complex snagging software certainly assisted me with this project, it also meant that I approached the topic with preexisting ideas regarding necessary features. From talking with construction clients and professionals, I was able to understand what minimum features to include to keep the product simple for the user.
From research, below is a list of strictly necessary features.
Snag Management: Capture images of defects, add text descriptions.
Assign Snags: Tag parties responsible to action items.
Prioritisation & Status: Note snag priority level and current status (ongoing, etc).
Reports: Generate PDF reports for team distribution.
Common features of bigger softwares that were excluded to keep the product lean and user friendly include: Real-time Project Tracking, Analytics, Document Management, Customizable Forms, Workflow Automation, Quality Control, Safety Management, Integration, and Real-time Collaboration.
Personas & Journey Maps
Problem Statement: Simon needs a cheap, easy-to-use solution to log detailed site snags and generate reports for his teams.
The Goal: Design a simple, browser-based snagging tool to efficiently manage site snags, enabling input of detailed data and PDF report generation.
Research insights
Simon’s two primary work locations are suited to different aspects of the snagging process.
Sites are noisy, dusty, and busy environments, unsuitable for taking detailed notes, especially on a small cellphone screen. On site, Simon will take photos, pin locations, and add snag titles for later reference.
Offices provide a quieter environment where Simon can efficiently organise, detail, and collate notes and reports for distribution to other stakeholders.
Note that some building sites are more conducive to on-site note-taking, and some professionals use devices better suited to writing and recording notes (tablets, etc). The intention is that the mobile product (not designed) will allow Simon to add as much detail as he’d like on-site, though the majority of fine-tuning and organising of notes will still take place on the web-based platform.
As such, the focus of the project is on the design of the web-based client platform.
Designing the Solution
AI Prototyping
Lovable was used to rapidly generate testable prototypes with functional variable states.
Benefits: This was much faster than the manual workflow would be to achieve a prototype of comparative detail and performance.
Drawbacks: Chat format is slow and inefficient for smaller tweaks.
UI updates
A clean visual style was opted for with high contrast for CTAs and tags, with the intention of keeping the product simple and intuitive for new users.
Benefits: Global colour/font edits are extremely quick to make.
Drawbacks: Making any adjustments to the UI can be buggy, sometimes a small change will crash the file.
Supabase backend integration
Integrating Supabase for a backend proved powerful for expanding the product capabilities. As pictured, the user can quickly customise and generate PDF snag lists for team distribution.
Usability testing
Testing with 5 construction professionals highlighted two main feedback points:
Users wanted customizable reports, like listing only “high” priority snags. I created a report preview page to select snags for reports.
The “assignee” category in the snag user flow confused users, e.g., assigning snags to “electrical engineers” but interpreting “assignee” as a specific person. I clarified the wording.
Learnings
Overcoming preconceptions
As a former architect, I initially viewed the problem with my own solutions in mind, but worked to adopt a broader perspective. Incorporating diverse viewpoints from others involved in construction helped me understand core user issues holistically.
Prioritising simplicity
Competitor softwares have many more features, increasing their capabilities, but making them bloated, more expensive, and daunting for new users. This project demonstrates that a cheaper, simpler solution could access a wider audience.
AI Prototyping
0 to 60% at pace: The time taken to get to a testable prototype is much quicker than standard Figma workflows. Backend integration lets users input text, generate external documents, logins etc, for a much more realistic prototype experience.
Slow progress after 60%: The AI text chat format is poorly suited for graphical changes and tweaks. I found small graphic errors extremely frustrating, wasting lots of time (and credits) trying to fix them.
There will be bugs: Currently, AI prototyping is prone to crashes that break your prototype, especially with small tweaks, wasting time and forcing restores of earlier versions.
Accept the imperfect: Aiming for polish? Not possible. Just things lining up? No again. AI prototyping is great at getting to a testable, integrated product fast, but you’ll have to compromise on aesthetics, or waste hours and credits inching toward visual improvements.
Going Forward
AI improvements
Massive improvements in AI prototyping since I started using Claude last year make it hard to predict the extent of future impact on processes. I do, however, think the immediate future holds plenty of opportunity to integrate AI prototyping into workflows, like rapidly producing unpolished, integrated prototypes to achieve fuller user testing and validation sooner.
There's currently some one-directional integration between Figma and Lovable, but I predict integrations allowing designers to work on the same product switching between different tools, for instance manual input and AI assistance as desired.
Staying problem-centric
As AI influences product creation, we risk obsessing over the “how” and losing sight of the “why”. Staying problem-centric is critical, ensuring our methods serve business and user needs first.
I had to constantly remind myself during this project that the goal was a testable prototype, even as graphic errors distracted me from that focus. See the GIF for iterations on graphic issues that were more about my visual standards than building a working product.
Iterations to get the square snag images full height within the card, and thereafter change the images to be relevant to the snag title.
Let’s collaborate!
Hey, thanks for taking the time to review my work.
If you have an idea that we could collaborate on, or want to know more about my process, feel free to drop me a message!