Internal toolWeb app

Atlas

To solve the problem of research being more accessible, I was able to ship a complete independent software with the help of knowledge of design and AI.

Role
Development & Product Design
Timeline
4 weeks
Tools
Claude CodeNext.jsAWS
Status
Live
40Competitors
1,000+Screenshots
1 hr → 2 minReference lookup
~71%Adoption, 12 of 17 priority users

Overview

A designer built the tool that made research searchable.

Problem

Competitor research sat in Figma boards with no search. A PM asking how an app handles payroll got a Slack message and a wait.

My part

I defined the product, designed it, and built the AI tagging pipeline, the web app and the deployment, end to end.

Result

A reference now takes about two minutes instead of about an hour. 12 of the 17 priority users adopted it.

Problem

Our competitor research was trapped inside Figma.

The apps we compete with are fintech products that need accounts, onboarding and real bank connections before the interesting screens appear, so they are not on Mobbin or AppShots. Researchers had captured hundreds of flows and pasted them into Figma boards with no search.

A PM asking "how does this app handle payroll?" got a Slack message and a wait. We had the research. We had no way to surface it.

Goal

One private, searchable product for three kinds of questions.

DesignerWhat does this app's payroll screen and disclosure copy look like?
PMWhat pricing and onboarding does a competitor show in week two?
ExecWhat is their full credit-building flow, and how do they pitch the upgrade?
Wants inspirationOpens the site andbrowsesFinds patterns andscreens they likeSaves itAdds to a collectionCopies the linkShares for referenceWants to seeA specific screentypeA specific productpitchA specificcompetitor screenSearchesAdds a filter forthe needGets a screen forreferenceWants to make amoodboardBrowses to findinteresting patternsSaves itAdds to a collectionAdds to their boardfor workWants to compare pitchflowsSearches for aproduct pitchAdds competitorsCompares

Designer user flows, one journey per row.

  • One journey mapped per person, not per feature.
  • Every path ends in the same place: a screen they can use.

Options

Three ways to get there, and why two lost.

RejectedBuild on a public screenshot libraryThe flows we needed sit behind accounts, so they are not in any public library.
RejectedOrganize the Figma boards betterStill no search, and it does not scale past a few hundred screens.
ChosenA private, AI-tagged productYou cannot search pixels, so I needed metadata for every image.

Approach

Two weeks of thinking came before any building.

I spent the first two weeks working out whether this was possible. The answer was to teach Claude to look at each screenshot and mark it: which flow, which feature, what copy, which partner. Every image goes through that pipeline and comes out as structured data.

  1. Raw screenshotsHundreds of captured flows
  2. Claude tags each imageIt looks at every screenshot and marks it
  3. Flow, feature, copy, partnerThe four marks on every image
  4. Structured datasetEvery image comes out as data
  5. SearchableBy flow, feature, screen type, copy and pricing

You cannot search pixels. So the first two weeks went on how to make thousands of screenshots searchable.

Design

Search first, filters second, results grouped per competitor.

The structure is shallow. A visitor lands, explores, browses or searches, reaches screens, and opens a company.

Information architecture A visitor goes to the website and lands on Home, then Explore, then the Explore page. From there they choose All apps or Most popular. All apps leads to Browse or Search. Both reach Screens, and Search can also add a filter before reaching Screens. Screens lead to a Company view, which can also be reached straight from Search. Cancel or back from a Company view returns to Browse. cancel / back User goesto website Home Explore Explorepage All apps Most popular Browse Search Screens Add filter Company view

Information architecture. I considered a landing page with an Explore call to action.

Wireframe of the home screen: a carousel of screen-type categories above a dense grid of all screens, with a menu and search at the top.

Home: screen-type categories above a dense grid of all screens.

Wireframe with the filter menu open: quick select chips, then competitors, screen types and screen flows, beside the grid of screens.

Filters: quick select, competitors, screen types and screen flows.

Wireframe of the Competitors tab: screens grouped in a row per competitor, each row labelled with the competitor and its products.

Competitors tab: grouped per competitor, so a flow reads in sequence.

Wireframe of one competitor's page on its Flows tab, with screens grouped by flow.

A competitor's page, with a Flows tab beside All screens.

Build

Private storage, a database, and one app in front.

The infrastructure was straightforward: images in private storage, metadata in a database, and a web app in a private network that queries the data and serves the images.

  • S3: imagesEvery competitor screenshot in a private, VPN-gated bucket.
  • RDS: metadataFlow tags, feature labels, extracted copy, ratings, bureau mentions.
  • EC2: the appA Next.js front and back end inside a private VPC.
  • SearchQuery the metadata, get the images, side by side across apps.

Private bucket, private network, VPN required. Images never leave.

What shipped

A private product first, then three releases.

V1 went live after four weeks. Three releases followed:

  1. More apps.
  2. An AI inspiration tab.
  3. Atlas made queryable from an AI coding assistant through an internal plugin.

It now covers 40 competitors and is updated weekly.

App detail: every screen grouped by flow, filtered to one journey.

Search: asking how a competitor onboards.

AI Inspiration tab.

A setback

The site went down three weeks after launch.

A routine credential rotation broke image access · mine I had made the app depend on a key shared in a setup guide. I fixed it with engineering: secrets moved to environment variables, and a fallback added.

The lesson: any credential in a shared file is a dependency.

Impact

A reference went from an hour to two minutes.

Finding a reference went from about an hour to about two minutes, measured as average time to complete the task. 12 of the 17 priority users (about 71%) adopted it.

Research that was trapped in boards became searchable by flow, feature, screen type, copy and pricing.

Takeaways

What I would do differently.

  1. Use environment variables from day one.
  2. Invest in the tagging model before ingesting at scale. Search quality is tagging quality.
  3. Keep the two-week think, two-week build split for anything this undefined.