LogoSyncer exists because someone described it in public, said they would pay for it, and nobody had built it. This is the unembellished version: the ask, the gap it revealed, the four decisions we made before writing any code, and the things we deliberately left out.
What was the ask?
In August 2026, Nevo David — founder of Postiz, the open-source social media scheduling tool he has grown into a well-known bootstrapped SaaS — posted on X describing a product he wanted to buy. Paraphrasing the substance: a tool connected to your Stripe subscription data that shows the logos of the companies using your app, updating dynamically as subscriptions are created and cancelled, with the logos fetched from the web and formatted so the wall actually looks good. He said he would happily pay for it.
I am paraphrasing on purpose — I am not going to put words in someone else’s mouth to make a launch post read better. But the substance was that specific, and that is the interesting part: it is a complete product spec in one sentence. Data source, update semantics, output format, and the quality bar (“look good” is doing real work there) are all named — and it describes something that obviously should exist and didn’t. Precise demand plus zero supply is rare enough to take seriously when you see it.
I replied in that thread recommending Logo.dev for the logo layer. Logo.dev replied too, confirming that showing customer logos sits within fair use and that once you have the domains, pulling current logos from their API is straightforward. That reply is what turned “someone should build this” into “I’m building this tonight,” because it closed the only question I didn’t already know the answer to.
To be explicit, since this is exactly the kind of origin story that gets embellished in the retelling: Nevo David described a need publicly, and Logo.dev answered a public question about logo rights. Neither endorses LogoSyncer, neither reviewed it, and there is no partnership. Logo.dev is a vendor we pay. That is the entire relationship.
Why didn’t this product already exist?
Because both halves were already solved and the join between them is boring — and boring, unglamorous joins are exactly the products that don’t get built.
Logo.dev solves logos. Domain in, clean brand asset out, across tens of millions of companies. That layer is not a side quest, either: HubSpot sunset Clearbit’s free Logo API at the end of 2025, breaking every site that had quietly hardcoded logo.clearbit.com into a customers page, and pointed people at Logo.dev as the replacement. Logo resolution is infrastructure with an operator behind it, not a scraping trick.
Stripe solves customers. Your subscription list is the one record of your customer base that stays accurate without anyone maintaining it, because it is maintained as a side effect of money moving.
Nobody joined them. And the join sounds like a weekend script right up until you write it: extract the registrable domain from a billing email, handle punycode, drop consumer mailbox domains, roll many subscriptions up into one company, decide what “currently a customer” means when a subscription is past due, rank the result stably so a free-tier cap doesn’t reshuffle the wall on every sync, cache vendor logos globally but scraped fallbacks per-account so one poisoned favicon can never reach someone else’s site, invalidate on webhook, and serve the whole thing from an embed that never renders a broken image. Every one of those is boring. All of them together is the product.
What did we decide in the first hour?
Four decisions, made before any code, each of which costs us something. That is how you know they were decisions and not preferences.
1. Read-only Stripe access, or nothing
You connect via OAuth (one click, revocable from your Stripe dashboard) or with a restricted key carrying exactly four read scopes: Customers, Subscriptions, Events, Account. Full secret keys (sk_) are rejected outright rather than accepted-and-scoped-down, because a credential that could move money becomes a liability the moment it lands in our database. There is no code path in LogoSyncer that writes to Stripe, because there is no credential that could. “Marketing tool with write access to your billing account” is not a sentence anyone should have to agree to. The full model is in the security docs.
2. Domains, never emails
The sync reads the billing email field, derives the company domain in-request, and discards the address. We store acme.com, never jane@acme.com. Stripe customer names are never read at all — display names come from Logo.dev brand data or from the domain itself. This costs us features we could otherwise ship, and it means your customers’ personal data is never written to our disk, which makes every subsequent security question much shorter to answer.
3. A publish gate on the Stripe account’s own inbox
This one took the longest to get right and is the one I’d defend hardest. Restricted keys leak — into repos, CI logs, screenshots, agent transcripts. A read-only key is low-damage in most products; in this one, a read-only key is your entire customer list, and publishing it to the open web would be the damage.
So before any wall from a key-based connection serves publicly, we email a confirmation code to the connected Stripe account’s own address — not the signup email, not an address someone typed into a form. A leaked key doesn’t come with that inbox. OAuth connections skip the code because OAuth already proves account control. The gate adds a step to signup and it costs us conversion. It stays.
4. Agent-first, not agent-also
An /llms.txt index and a complete /llms-full.txt reference, one error envelope everywhere, a GET /v1/me that states exactly what is currently blocking you from publishing, and an MCP server at /mcp for ongoing management. Partly because the party installing a developer tool in 2026 is increasingly a coding agent acting on someone’s behalf. But mostly because designing for an agent is a forcing function: a flow an agent can finish unattended is a flow with no hidden state, no “click the thing in the corner,” and no error message that means five different things.
What did we deliberately not build?
A product shipped in a day is mostly a list of refusals. Ours:
- No write access to Stripe. Not as a setting, not as a Pro feature, not later. See decision one.
- No CRM connectors. Salesforce, HubSpot, and “import a CSV” would each hand us a bigger addressable market and a worse product. The entire premise is that billing is the honest record and the CRM isn’t — see Your Stripe Account Already Knows Your Customers. Bolting on a drifting data source would sell out the thesis for a checkbox on a comparison page.
- No logo editor. No cropping UI, no per-logo color picker, no canvas. Normalization is the pipeline’s job; if one mark still reads badly, you upload a replacement for that domain and move on. A design tool inside a sync tool is how a one-line embed turns into a five-hour project.
- No discovering customers from anywhere but your billing data. We don’t scrape your site, your inbox, or LinkedIn to guess who your customers are. If it isn’t a subscription, it isn’t on the wall. That constraint is precisely what makes the wall a claim you can defend.
- No AI inside the product. No model deciding which customers deserve to be shown, no generated company blurbs, no “AI-optimized” anything. Domain in, logo out, deterministic. The only concession to AI is that the docs are written so agents can read them.
- No customer counter. You won’t find “trusted by 1,200 companies” anywhere on this site. We launched days ago. Any number we published would be either embarrassing or a lie, and a company selling honest social proof doesn’t get to fake its own.
- No paywall on coming off a wall. Exclusions — the controls that decide who appears — work on every tier, including free. Curation is product value worth charging for in bulk; keeping a company visible against its wishes is not something we’d sell at any price.
Can an agent really do the whole install?
Yes, minus three copy-pastes. If you use Claude Code, Codex, or Cursor, the integration is one prompt:
Add a customer logo wall to my site with LogoSyncer — start at https://logosyncer.com/llms.txtThe agent reads the machine-readable docs, builds against the public demo wall before asking you for anything, then runs signup, the Stripe connection, the sync, and the embed placement. You paste exactly three things into the terminal: your email verification code, the read-only restricted key you create in Stripe, and the confirmation code that lands in your Stripe account’s inbox. Those pastes are decisions two and three doing their job — credentials never transit the agent or any LLM. The design behind the flow is its own post: Agent-Ready SaaS: Letting AI Agents Install Your Social Proof. Prefer clicking? The quickstart shows both paths side by side.
What does 24 hours actually buy you?
Less than the number suggests, and more than you’d think. A day was enough only because the specification had been written in public, the two hard halves were already solved by other people’s infrastructure, and the refusal list above kept the scope from expanding. The speed came from subtraction, not heroics.
What a day does not buy: edge cases discovered across thousands of real Stripe accounts, a track record, or the taste that only comes from watching people misuse a thing. If your customer list is sensitive, read the security docs before you connect anything, start on the free tier, and look at the wall before you publish it. You own what your wall asserts; we just make it agree with your billing data.
The bet underneath all of it is simple: a logo wall isn’t a content section, it’s a view over billing data, the same way an MRR chart is. Nobody hand-edits their revenue dashboard. If that premise sounds right, the quickstart takes a few minutes, the embed docs cover placement, and the homepage has a live wall you can look at before you decide anything.