Radar de Obras is my own product, not a client. A B2B SaaS/DaaS that collects public tender notices, filters them, scores them by relevance, and delivers the curated opportunities over WhatsApp to construction material suppliers in Mato Grosso. It ran in production from April to June 2026, and it's paused now.
I built this case against the designer reflex: no opening Figma to draw screens. The question that mattered came first. Is there real pain? Who feels it? Is it worth solving? I validated the whole product before the first line of code. What follows is the product decision first, and the interface it produced shows up as proof, not as the starting point.
Discovery first,
screens as proof.
Double diamond against the reflex: discover the real pain, define who it's for, develop the architecture, deliver with a quality loop.
8 rounds until the real pain surfaced
I ran 8 rounds of ICP research with deep-research and AI panels, plus a benchmark of competitors. They all sell the same promise: "find the tender". The research showed that's not the problem. Shop owners do find the tender; what they lose is the opportunity, because the counter eats their whole day. The pain wasn't search, it was attention.
ICP distilled, 16 anti-ICPs, 3 clusters
I distilled the buyer persona and, even more useful, mapped 16 anti-ICPs: people who look like the customer but aren't. Knowing who you don't sell to sharpens the product as much as knowing who you do. Instead of a generic "tender platform", I picked 3 clusters to focus on. The requirements became centered on a non-technical operator: if it needs training, it's already failed.
Architecture that lowers cognitive load
A deliberate AI decision: I split the business dashboard from the technical health dashboard. The shop owner sees only opportunity, score, and action; scraper, queue, and logs live in a separate panel. Mixing the two is the classic mistake that drowns a non-technical user in noise. The scoring is adaptive: it raises what the supplier opens and replies to, and lowers what they ignore.
Live, with "Customer Zero" in the loop
The product went into production. Before exposing it to any paying user, I built the "Customer Zero" mechanism: me on the receiving end, checking whether the filter delivered signal and not junk. It's a relevance QA loop, not a usability test. Tenders that leaked past the score turned into weight adjustments. The day someone paid, their WhatsApp would only get opportunities worth reading.
The decision became the screen.
Utilitarian on purpose: non-technical operator, zero training. Each screen embodies a product decision, not decoration.
Pass A → D, closed out.
The weight of discovery.
AI as research copilot, from discovery to code
The entire discovery (deep-research, decision panels with multiple models), the plans, and the build itself ran on Claude Code and agents. Validating a product with AI as a research copilot is how I work.
Own product, no paying client. "Customer Zero" is an internal filter-quality QA, not a usability test with an external user. There was no A/B testing and no Figma prototype (the spec was written in text). The production interface is utilitarian on purpose, non-technical operator and zero training. This case shows the product decision and the discovery behind it, with the real screens as evidence.