A sales dashboard
Upload the sales spreadsheet and get an instant read: revenue, active accounts, campaign-over-campaign movement, a per-agent view, a heat-mapped country map, new, returning and churned accounts, and where revenue is concentrated.
A brand selling through independent retail had two slow, manual jobs. Reading the sales book meant working a spreadsheet by hand, with no fast way to slice it by agent, country, account, or campaign over campaign.
And finding new stores to sell into depended almost entirely on field reps walking the same ground. The blind spot was everything outside the book: the compatible stores nobody had mapped.
Three pains came up. We took the two that paid for themselves, analysis and discovery, and deliberately parked the third, a larger CRM-style build, so the tool could ship before the selling season instead of promising everything.
One private web app with a sales dashboard and a prospecting engine. The interesting part is where they meet.
Upload the sales spreadsheet and get an instant read: revenue, active accounts, campaign-over-campaign movement, a per-agent view, a heat-mapped country map, new, returning and churned accounts, and where revenue is concentrated.
From a city and a radius, it finds the independent stores that could carry your brands, reads each store's own site to see which brands it already stocks, and rates the fit by the strength of those brands rather than the raw count.
Every store is cross-referenced against your own book and labelled active, lost, or pure prospect. Then it finds the decision-maker and drafts outreach that references the brands the store already carries.
The cross-over: places where the engine finds compatible stores but the sales data shows no customer. The one thing neither tool does alone, and the core idea of the product.
Deliberately out of scope: a social-media intelligence module (priced separately), department stores and pure ecommerce, a full agent CRM, and a mobile-first build. The app is responsive but not mobile-first.
A React frontend over Supabase (Postgres and Deno edge functions), with scraping through Firecrawl, contacts through Hunter, and send through Gmail. Every table is walled off by row-level security, so each user only ever sees their own data.
The top few candidates are analyzed inline and returned immediately. The rest go to a background worker and stream into the page as they finish, so the search feels instant without dropping anything.
It only confirms a brand that genuinely appears on a store's own pages. When a site is too thin to read, a constrained web search backs it up, confirming a match only when store and brand truly co-occur.
Each brand carries a strength tier you set. A store's quality is set by its best brand, so a single strong stockist outranks a pile of weak ones. The badge you filter by matches the result one to one.
The background queue claims jobs safely so nothing is processed twice, caps retries, and requeues anything stuck. Row-level security walls every table, and admin checks run through a guarded path to prevent privilege escalation.
The prospecting engine is not built from scratch. It adapts Odysi Reach, our existing B2B outbound pipeline, so most of the plumbing was already proven. The genuinely new work was the geography-first discovery, the multibrand scoring, the customer cross-reference, and the sales dashboard.
Contact discovery needs a store to have its own domain; the engine only sees brands a store actually publishes; fuzzy matching can occasionally over-match.
We rated these up front, so they're known trade-offs rather than surprises the user finds later.
A common assumption was that store locators were unreliable. Before committing the architecture, we checked the actual brand list and found that most of them ran working locators carrying multibrand retailers. That evidence shaped the build instead of a hunch.
Then the dashboard started returning near-zero revenue. The spreadsheet parser was skipping formula cells. We fixed it, and then audited the corrected numbers cell by cell against the source file with an independent tool before trusting a single figure. We did not assume the dashboard was right; we proved it.
The dashboard is the most advanced part, with its data validated against source. The prospecting engine is substantially built: geography-first search, chain filtering, two-stage analysis, signal scoring, customer cross-reference, and the contact-and-outreach pipeline are all in place.
Some pieces remain on the roadmap, and there is known, named technical debt to pay down. Delivery ran past the original target. There are no usage or commercial metrics, so we report none rather than invent them.
Most of the engine is reusable, so the path forward is to harden it into something more brands could run, and to make white spaces the thing you open the app for.
Make white spaces the default view rather than a side effect.
Finish settings and search history, and pay down the named debt.
Harden the engine into something more brands can run.
A small product studio. We prototype, automate, and ship.
Small is the feature: you work directly with the people building the thing, and we care more about something that holds up in production than something that looks good in a pitch.