10 Things We Got Wrong Building SLB (And What We Learned)

Building in public means sharing the failures alongside the milestones. Here are ten things we genuinely got wrong while building Support Local Businesses to 6.4 million listings — what went wrong, what it cost us, and what we learned.

We are sharing these not because we enjoy self-criticism, but because every team building a local business directory will face the same forks in the road. Maybe this saves someone the months we spent learning some of these lessons the hard way.

1. We Thought Data Quality Was the Starting Problem

When we had 12,000 listings, we spent weeks trying to improve the quality of those 12,000 records. Better formatting, more complete fields, more consistent categories. We treated data quality as the primary constraint.

It was not. At 12,000 listings, we were too small to be useful. The problem was scale. Even imperfect data at 500,000 listings is more valuable than perfect data at 12,000. Coverage creates utility; quality refines it. We should have invested in the data pipeline to reach meaningful scale first, then layered quality improvements on top.

What it cost us: Four months of quality work that mattered far less than four months of pipeline work would have. We launched to coverage gaps that frustrated early users far more than any data quality issue.

Lesson: For directories, scale unlocks usefulness. Quality without scale is polishing something no one is using yet.

2. We Underestimated the AI Shift

We built SLB for Google search in 2022. Keyword-optimized category pages, structured for Google's crawlers, designed to rank in traditional search. We did not seriously consider that AI search would reshape local discovery within three years.

By 2025, the assumptions behind our original architecture were outdated. Users were asking ChatGPT and Perplexity for local recommendations, not running Google searches. The signals that drove Google rankings (backlinks, keyword density, click-through rate) were less relevant than the signals AI systems used (structured data quality, source authority, data provenance).

We had to retrofit AI-first architecture onto a search-first foundation. That is harder and more expensive than building AI-first from the start.

What it cost us: Six months of engineering time to add JSON-LD schema, restructure URLs, implement llms.txt, and add provenance citations to legacy listings.

Lesson: In a technology transition, build for where the world is going, not where it is. In 2022, AI search was clearly coming. We should have built for it earlier.

3. We Ignored Category Standardization Early

At launch, we had over 200 business categories. We thought granularity was good — more categories meant more specific matching. What we discovered was that AI agents could not navigate 200+ categories efficiently, our own team could not maintain them consistently, and businesses often landed in ambiguous categories where multiple options seemed valid.

Consolidating down to 98 well-defined categories was one of the most painful projects we undertook. Every existing listing had to be reviewed and potentially re-categorized. Listings that had been correctly categorized under old categories needed to be migrated to new ones without breaking existing links or losing search visibility.

What it cost us: Three months of re-categorization work, plus a temporary dip in search rankings as category URLs changed during consolidation.

Lesson: Fewer, well-defined categories are better than many ambiguous ones. Define your category taxonomy at the start and treat it as a core architectural decision, not a detail to iterate on later.

4. We Thought Businesses Would Self-List

The original plan included a self-listing feature as a primary growth mechanism. Business owners would find us, fill out a form, and grow the directory organically. We imagined a flywheel: more listings bring more users, more users bring more business owners to self-list.

The flywheel did not spin. Business owners are busy. Most will not proactively list their business on a new directory they have not heard of, especially when they already have a Google Business Profile. Self-listing is a supplement to a data pipeline, not a replacement for it.

The government record pipeline we eventually built is what actually scaled the directory. Self-listing now accounts for roughly 3% of listings. It adds value (business owners can add details not in government records) but it is not the foundation.

What it cost us: Six months of waiting for organic growth that did not materialize while we should have been building the pipeline.

Lesson: Build the authoritative data pipeline first. Self-listing is a layer on top, not the base.

5. We Launched Locally Before Building for National

We started deep in Palm Coast — every ZIP code, every neighborhood, county-level detail. The Palm Coast architecture was beautiful for Palm Coast. When we tried to scale it nationally, the routing structure broke. URLs that worked for Flagler County did not work for Cook County. State-level navigation was an afterthought.

We had to rebuild the geographic routing layer when we went national — a project that required redirecting thousands of URLs and rebuilding the navigation hierarchy from the state level down.

What it cost us: Two months of architecture work plus a period of SEO instability during the redirect migration.

Lesson: Build the national geographic architecture first (state > county > city > ZIP), then go deep locally. The skeleton should be national; the flesh is local.

6. We Did Not Build Schema Markup from Day One

JSON-LD LocalBusiness schema was added to SLB listings approximately eight months after launch. The decision seemed reasonable at the time — we were focused on getting the listing data right before worrying about markup. Schema felt like a polish layer.

It was not a polish layer. It was foundational infrastructure. Every listing created before schema markup had to be retroactively updated — an automated process, but a three-month project to validate that all 400,000 listings active at that point had correct schema and that the schema accurately reflected the listing data.

What it cost us: Three months of engineering time that would have been zero if schema had been part of the initial listing generation template.

Lesson: Build schema markup into the listing template before you publish your first listing. It is infinitely easier to add schema to 1 listing than to retroactively validate it across 400,000.

7. We Thought Free Would Be Its Own Marketing

"Free" is a powerful value proposition. We believed that offering free listings would generate word of mouth, that business owners would share their listings with other business owners, and that organic growth would follow.

Some of that happened. But "free" is necessary rather than sufficient. Business owners needed to see concrete value before they would engage with the platform — and value was not visible until they could see their listing in AI recommendations or track increased calls. The benefit was real but not immediately perceptible.

We had to build active value demonstration — AI Visibility Reports, search performance data, recommendation tracking — before "free" generated meaningful organic growth.

What it cost us: Slower early growth than projected.

Lesson: Free removes a barrier but does not create a reason. The value has to be tangible and visible.

8. We Underbuilt the Review System

We assumed reviews would accumulate naturally. Businesses with satisfied customers would receive reviews; the review count would grow organically over time. We did not invest in review collection infrastructure.

Reviews did not accumulate naturally. Without a systematic prompt — a follow-up email, an SMS, a QR code at the point of service — most satisfied customers do not leave reviews. We eventually built a review collection system, but it was a year behind schedule.

What it cost us: Lower review counts than competitors during the period when reviews were a primary trust signal for users.

Lesson: Design the review collection workflow before launch. Reviews require active collection mechanisms; passive accumulation is too slow to be strategically useful.

9. We Did Not Anticipate AI Agents as Primary Users

We built SLB for human browsers. Every design decision — navigation menus, visual hierarchy, mobile layout — was made with human users in mind. AI agents, which retrieve structured data programmatically rather than browsing visually, were not part of the design.

llms.txt, the x402 protocol support, and the agent card were all added after launch — afterthoughts that became strategically critical. They should have been day-one features.

What it cost us: Slower AI agent adoption and lower citation frequency during the period when AI search was first growing.

Lesson: If you are building any web property today, AI agents are a primary user class. Design for machine consumption from the start, not as a retrofit.

10. We Got the Palm Coast ZIP Codes Wrong

This one is the most embarrassing. In our early data, we included ZIP code 32135 as a Palm Coast ZIP. It is not. Flagler Beach is 32136. Bunnell, the Flagler County seat, is 32110. The core Palm Coast ZIPs are 32137 and 32164. For a directory marketing itself as "hyper-local," this was a significant error.

We discovered it through user feedback — a Palm Coast resident pointed out that businesses were being misassigned between ZIP codes. The correction required re-running entity resolution for all Flagler County listings and updating geographic assignments.

What it cost us: User trust in our geographic accuracy, plus a week of data correction work.

Lesson: Triple-verify local geographic data, especially for your home market. If you are marketing local expertise, geographic errors are credibility-destroying in a way that other errors are not.

These ten mistakes represent real time, real money, and real credibility lost. We share them because the next team building a local directory at scale will face the same decisions — and maybe one of these lessons will save them the cost of learning it firsthand.

Building in public means owning the failures. We are still here, still building, and grateful for every hard lesson that made the platform better.