LOCAL
idea, market, competitors

Summary

The diagnosis is right, but as a platform the idea dies on two-sided cold start and on the refusal to take money for promotion. As a single-corridor service with verified live offers it can be tested in three weeks and with almost no money.

Five main findings, each with a source referenced in the text below:

1. The problem is real and measured. The query "a specific product or service with its attributes nearby" is not answered today by any product on the market, including Google. Tested in Chicago: AI Mode on "sushi nearby" returned venues an average of 4.9 miles away against 0.3 miles in Maps and included a ramen shop with no sushi.
2. But its "live layer" is already being built by Google. At I/O 2026 Google announced agentic booking of local services and calls to businesses on the user's behalf (repair, beauty, pet care). That is its intent search plus concierge, free and at scale.
3. Its multilingual wedge is the strongest part, and it really is unaddressed. Platforms for Chinese speakers (HungryPanda, Fantuan, Chowbus, WeChat mini programs) are closed inside the language community. The mainstream translates by machine and literally. A two-sided surface where the merchant writes in their own language and the neighbour reads a meaningful explanation exists nowhere.
4. The closest company to this idea is already dead. Karma (Stockholm, $18M from Sequoia, 1.5M users) shut down in 2023 due to churn of partner restaurants and competitor density. verified
5. The economics rest on operations, not on code. One honest offer in the live layer costs about two hours of human time per week. That is the cost of the live layer, not the platform: a permanent profile is filled in once and lives for months, so cost grows not with the number of merchants but with the share of them running live content.

Answering twelve corrections: where she is right, where the analysis holds

The corrections came in twelve points. I take each one honestly, including the ones where I, not the concept, was wrong.

An honest count: five corrections hit my assumptions (two hours, mandatory integration, mandatory publishing, a closed catalogue, a total refusal of advertising), and they hit fairly. The concept was not expensive; I built it up into a more expensive model and then criticised what I had built. The methodological error was turning a worst-case usage pattern into a baseline cost.

But none of the twelve touches customer acquisition. Costs come down and the economics look better than my first estimate, while the kill line runs through demand and remains untested.

Three facts, verified by hand

Three places where the sources were checked by hand rather than taken from secondhand retellings. These three facts carry the weight of the rest of the document, so they are called out separately.

Who is already in the market

Conversational local search has become a baseline feature of every major assistant. Confirmed stock exists nowhere except bookable services and restaurant tables. This both confirms the hypothesis and explains why there will be no time: Google is solving the same problem.

Google: the owner of demand

Google is not one competitor but three products that together cover most of the LOCAL concept for free.

Search and AI Mode

Since May 2026 AI Mode runs agentic booking of local services and experiences: the system assembles prices and availability and gives a booking link. For a custom cake this does not work, because there is no structured availability feed. But for anything that has slots or a POS, it works.

Agentic calls

Google calls the business on the user's behalf and sends a summary. The categories at the time of the announcement: goods (toys, electronics, beauty) and services (repair, beauty, pets). That is exactly "intent search plus concierge", only free and at scale. The LOCAL category is not supported, and that is what leaves a window, but the window is closing.

Maps and Ask Maps

Conversational questions about places, food ordering via Square and Toast, hotels, tickets. Vibe and diet filters exist, no verified product stock.

Yelp and the data layer

Yelp is at once a competitor and a supplier. As a product: a conversational assistant across all categories with booking (tables via Guest Manager, beauty via Vagaro, medical via Zocdoc, auto via RepairPal, services via Calendly), monetised through Yelp Ads and partner leads.

As a data layer: it licenses 330M reviews and 8M+ listings to OpenAI, supplies data to Apple Maps and Yahoo. Reservations and Waitlist run inside ChatGPT.

This means any attempt to be "another source of local truth" competes with a contract already signed between Yelp and those who answer the queries.

ChatGPT, Perplexity, Copilot and Apple

Startup contenders

The common denominator: they all monetise by subscription or ads and none confirms stock. They all play at discovery, not at the truth about what exists today.

Tools for merchants

A separate category is B2B tools that sell merchants visibility and booking. They are not competitors to the LOCAL consumer app, but they occupy the same shelf in the business owner's head.

Profile against live layer: what actually carries the search

The permanent profile carries services, specialisation, assortment, prices, photographs and video of the work process. Two kinds of video deserve separating here because they are constantly confused: video of the work process is a portfolio, it lives for months and belongs to the profile, while video of fresh baking is the live layer, it lives for hours. The first does not age and costs nothing to keep, the second ages every morning.

And the central claim, which I accept: the profile alone is enough for full participation in search. A conclusion follows that deserves recording separately, because it changes the product logic: if the profile alone is enough to reach the results, then the live layer has no effect on discovery at all. It retains exactly one job: turn something found into something settled. So the live layer cannot be sold as a way to get found, and it has to be tested separately from search, otherwise in the pilot one mechanism will mask the other's failure.

The same logic says what must not exist in the interface. If the function exists for convenience rather than as a duty, then a merchant cannot have a counter reading twelve days since your last post, or nudging notifications. Any such element turns convenience into duty faster than the feature itself.

And what a connected merchant gets instead of position: services, specialisation, prices, examples of work, current offers. So the value of connecting is stated as detail and freshness, and that must be visible literally: next to a connected merchant you see what is known about them, next to an unconnected one you see what is missing. Otherwise the difference stays invisible and the advantage of connecting evaporates.

Who owns local data

Access to local data is not a technical question but a licensing one. The canonical source is closed to third parties.

Live content is optional: what that changes

The clarification matters: publishing is voluntary, absent live content carries no ranking penalty, and freshness requirements differ by field. A technician's permanent specialisation lives for months, a temporary offer lives for hours, and demanding the same confirmation from both is pointless. This is a better design than the one I analysed, because it removes the treadmill my cost estimate grew out of.

But optionality has a reverse side that has to be named before launch: if participation is voluntary and unpenalised, the presence of the live layer depends on merchant mood. The buyer cannot count on something live existing today in their neighbourhood, in their category. The promise of seeing what exists right now holds not because the mechanic is good, but because coverage in a given neighbourhood-and-category cell is high.

Two interface consequences follow. One: confirmed freshness needs a visible badge, otherwise the buyer cannot tell a live offer from a stale one and the whole difference vanishes. Two: the sort must not punish a merchant who never publishes, otherwise the no-penalty rule is broken in substance while being kept on paper.

And the cost revision that follows. The profile is one-off hours at onboarding. The live layer is weekly hours, and only those who take part are willing to pay them. So the platform's budget is built per cell, not per merchant: how many merchants in the cell, how many of them are live, and how many queries that cell covers.

The graveyard: what happened to the previous wave

This is the most important table in the document. Every project here sold roughly what LOCAL sells, and every one died of the same cause.

The buyer's path today: Instagram, messages, waiting

The concept names it precisely: Instagram gives a visual sense of a place, but you search photos for a long time, write messages and wait to learn the details. That, and not Google, is the real competitor. The buyer today runs a loop: saw a shot, asked a question, waits for an answer, and only then learns the price and whether it is in stock.

It follows that the product's real metric is not venue found, it is time to a confirmed answer. Instagram wins on desire and loses on certainty: a photograph cannot tell you whether this exists today or what it costs. So the comparison is against the message loop, and in the experiment that is measurable: how many minutes pass between a person's question and a merchant's confirmed reply.

The QR page follows from the same logic. In the concept, it is a useful page the merchant shares with their own clients. So it must be designed such that the owner wants it in their own profile: the live layer visible, prices visible, ordering next to them. Then the merchant becomes the distribution channel without our advertising. And it doubles as an honest test: if the owner does not want to share their page, the page is useless.

The business page: what has to stand on it

The concept lists what a venue page carries: photographs, description, specialisation, goods or services, prices, current offers and links to order. I take each element not as a list item but as a question: who confirms this field, and when does it rot.

The video layer: why it must not sit next to availability

The concept contains a layer of short-lived video: the bakery shows fresh bread in the morning, the florist films new bouquets, a buyer shares the cake they ordered. Posting is voluntary, clips disappear after a few days, and the concept states plainly that a video does not confirm availability.

The mechanic works, and that is not a guess: Atmosfy built a whole product on short video about places, with 1M+ businesses and $12M raised, and TikTok has already become the main discovery channel for food among people under thirty. A live shot persuades where a studio photograph does not.

Where the layer genuinely pays: not inside the app, but as ready-made marketing material for the merchant. They need content for their own channels, their own groups, their own Instagram, and if LOCAL films once and hands the material over, the cost turns into a service they pay for. That is the same logic that keeps a merchant in a programme.

Product surface: the map, the saves, and the explanation

The concept describes three surfaces: intent search, a neighbourhood map to explore, and saving with collections. Plus the requirement that the system explain why an offer matches. I take each separately, because they differ sharply in cost and in payoff.

There is a direct lesson about the map from a neighbouring product. Beli grew to 120 million ratings with a team of about five and holds people not with a map but with a personal list the user assembled themselves: a hundred saved entries create switching cost. The consequence: retention lives in saves, not in the map. The map can stay, but the centre of the product should be the personal list, with the map as one of its views.

The merchant side: attention that cannot be bought

The concept names three things: small businesses struggle to compete for attention with chains, a great product does not mean it will be found, and merchants already use many tools and do not want to learn another. The first two are true and borne out by everything above. The third is the real killer, and it deserves its own treatment.

But here is uncomfortable news for the positioning. The merchant tooling space is already occupied and funded: Chowbus raised an $81M Series E in 2026 precisely for point-of-sale and AI marketing aimed at Asian restaurants, on $120M ARR. So an AI assistant for merchants is not an empty niche as a product. What is empty is different: verified live offers and a cross-language surface. The tool is the entry, not the thing that gets sold.

Integrations: what is needed at the start and what is not

There is no mandatory integration in the first stage, and that changes the order of work more than it appears. It also removes the dependency on other people's APIs, which is exactly what made the local market look closed in the rails section: Fresha offers no public API at all, ChowNow works through intermediaries, Square admits only approved partners with a wait beyond ten months. Under the approach the concept describes, all of that moves from blocker to the price of a later stage, and the launch stops depending on it.

The platform's job is stated narrowly, and rightly so: help a person find a suitable business and get enough concrete information to decide. Note the boundary: LOCAL is not obliged to close the sale, it is obliged to carry the person to a decision. That has an important consequence: the product's quality criterion is not a transaction but sufficiency of information, and that is precisely why the first version needs no integrations.

Too Good To Go and the live layer

The live layer is the heart of the idea: without fresh data the product is useless. Here is how others solved it and what it cost.

Rails: what can actually be read

The idea of "not replacing the existing tools" is right, but it has a price. Here is what is actually available and at what cost.

What merchants actually pay

• Marketing: the norm is 3-6% of revenue for established restaurants, up to 10-25% for new ones; SBA for businesses up to $5M is 7-8%. Most small businesses spend $500-3,000 a month.
• Yelp Ads: from $150/month, a package with enhancements $180/month, bundles from $270/month.
• Restaurant software: OpenTable $149-499/month, Toast $25/month per location, ChowNow from $129/month.
• Salon/services: Fresha $19.95/month, Square Appointments up to $69/month; the median entry tier is ~$28/month.
• Churn: SMB software averages 4.5% a month (42% a year) at ARPU ~$55; in food service 3% a month at ARPU ~$110; annual churn for restaurant software is 25-40%, margins 55-70% against the usual 75-85%.

Translation: the name, the fact and the explanation

The multilingual addition carries three requirements that are easy to lose: the original name is preserved next to the explanation, general information about a dish is kept separate from confirmed facts about this specific shop, and the model may explain a traditional recipe but must not invent the ingredients of this particular bakery.

That gives a simple card construction with two visible layers. The first is about the dish in general: what it is, how it is usually made, how it tastes, what to compare it to. The second is in this bakery today: only what the owner confirmed. The original name stands next to the explanation, otherwise the visitor cannot match the words on the sign to what they see in the app, and all the translator's work evaporates at the moment the person stands at the counter.

And the hidden cost, which has to be named before launch: quality control of explanations. Translation is done well and almost for free, but a wrong specific about a particular bakery is exactly what the concept forbids. So explanations cannot be generated in bulk across a catalogue and left unchecked: somebody is accountable for them, and that somebody costs money. On one street it is tolerable; across a city it becomes an editorial desk.

The multilingual wedge: what already exists

This is the strongest part of the idea. Here is the full map of who has already tried and why the problem is not solved.

Reputation, advertising and registration: three places the concept is stronger than I credited

Reputation. The recency-and-weight model is more precise than what I proposed: not an average star, but the recent period as the main signal with earlier history available separately, and weight given to a complaint's nature, severity, repeatability and resolution. Plus a rule I did not state and which deserves recording: a truthful review cannot be removed for compensation or at the business's request. The honest caveat stands: at pilot scale there is no reputation data at all, so the design is drawn now and tested later. And structure costs moderation: if a complaint is weighted by severity and resolution, someone reads it, and at two hundred merchants that is labour, not a feature.

Advertising. My criticism here was imprecise, and the correction favours the concept. Labelled paid placement is allowed, and only the substitution of organic relevance is banned. Two refinements follow. First: an announcement that a new studio has opened is not really advertising but a newness signal, and it is useful to the buyer, so charging for it is worse than giving it away as a free filter. Second: the strongest item on her list is jobs and hiring. A local business hires constantly, the pain is acute and the willingness to pay is real: job boards charge $75 to $400 per posting. That is the most plausible early revenue after the founder's own labour.

Registration. Search without a login is the right call and matches how people behave on Maps. But it has a blind spot that has to be closed in advance: without identity, repeat use per person cannot be measured, and that is my second pilot criterion. So an anonymous device counter is needed, and an account is offered after the first useful result rather than before it.

The corridor: real numbers (District 4, Sunset)

verified against the official district profile (SF Planning, Sunset Forward).

• Of those who do not speak English at home: 78% speak Asian and Pacific languages (including Cantonese and Tagalog), 3% speak Spanish.
• Median household income $103,817, that is exactly the city average: not a poor district, but not a rich one either.
• District corridors: 160 storefronts (8% vacant), 190 storefronts (2.6% vacant), 242 storefronts (13.2% vacant).
• From the 2018 ground survey: on Noriega 9 vacant out of 196, on Irving 38 out of 406, on Taraval 27 out of 251.

For comparison, Mission: about 900 shops and restaurants, Latinos are more than half the population. Chinatown: 81% of residents are Asian, in 2015 only 14% of SRO households were headed by someone who spoke English fluently.

What else to sell besides tools

The concept lists what could become paid: the extended assistant, automation, integrations, analytics, more offer-management capability, and personal help and handholding. And it states the important caveat: first find out what value the merchant actually gets and what they are willing to pay for.

The first thing the list shows is that it mixes two businesses. The tools (automation, integrations, analytics, the extended assistant) are software: industry average revenue per customer runs $25 to $70 a month, churn 3 to 4 percent a month, and it has to be sold in hundreds. Personal help and handholding is a service: $150 to $500 one-off or by subscription, lower churn, does not scale, sold by hand.

And a warning about the order of sale: analytics is last on that list for a reason. Selling analytics to a merchant with three views a month is selling disappointment. What sells first is what brings money today, and in a business built on relationships that is the founder's own labour.

Ready-made channels that need no inventing

The first twenty merchants and the first hundred users are won not by advertising but through existing organisations and newspapers. It is cheaper and more credible than any app.

A mixed catalogue: connected, unconnected, and what it does to ranking

This correction changes more than it appears. If an unconnected business shows up when it best answers a query, then LOCAL is no longer a closed partner catalogue but a search across the neighbourhood market with confirmed data layered on top. And the distinction she draws I adopt entirely: confirmed information does not mean confirmed quality of work. The merchant confirmed what they do and how, not that they do it well.

The first consequence is uncomfortable: the working space expands to the size of a map, and the difference from Maps now rests entirely on the confirmation badge. The second is worse: among unconfirmed venues, order has to be decided by something, and there are exactly three honest options, all of which Maps already has: distance, open now, and category fit. Popularity returns through the back door, because for the unconfirmed part of the corpus there is no other signal.

One honesty note: the badge has to be defended in the interface with words. A person reads confirmed by the owner as good, not as described by the owner, and that is the fastest way to lose trust. So the badge needs a date and a wording that states exactly what was confirmed: this offer and these terms, as of this date.

Mixed results: freedom of choice and what it costs

Confirmation does not mean a guarantee of quality of work, and I adopt that distinction entirely. But it has to be defended in the interface with words, because a person reads confirmed as good, not as described by the owner. So the badge must carry a date and a subject: what was confirmed, and as of when. Without that, LOCAL inherits exactly the problem it is escaping: trust built on a misreading.

The principle of not restricting choice and not distorting results I accept, and I name its price. If an unconnected business appears on equal terms when it better answers the query, then the only lever left on the merchant is the detail in the card. Visibility can no longer be sold, so the connection funnel changes: the merchant is not sold you will be seen but what decides the choice will be known about you. That is weaker as a promise and more honest as a product.

The economics: four money models

The target for the calculation: $10,000 a month, a modest income for one or two people. Here is what each model requires.

Ranking: match against popularity

The concept contains the product decision I consider its strongest and the hardest to hold: the main criterion in search must stay match to the request, not the size of the business. The example is exact: a small restaurant opened a month ago, almost no reviews, but it makes excellent sandwiches, and if someone is looking for exactly that sandwich, the restaurant should appear on the strength of its offer rather than accumulated popularity.

Holding it is hard because popularity ranking at Yelp and Google is not a policy, it is the arithmetic of their corpus: reviews and clicks are the only signals that scale for them. A corpus of confirmed offers has different arithmetic: if a field is confirmed by the merchant, the match is computable without popularity at all. That is precisely why the decision is available here, and precisely why it disappears the moment the data stops being confirmed.

And a separate axis that is present in the text but unnamed: newness. The query about which new cafes opened nearby is a filter on the newness of the business, not on stock. It is cheap, it gives a small venue a moment where popularity does not matter, and it is exactly what Instagram does well and Maps does badly: Maps shows you what is already popular.

Why the catalogue is not filled with empty profiles

The concept says it plainly: do not repeat the model of huge catalogues with thousands of empty or stale profiles, and build on real merchants who take part and confirm their offers. It reads as an ethical preference, but it is in fact a mechanical requirement of the product.

Match ranking is only as good as the confirmed field set is complete. One empty profile does not merely look bad: it devalues the confirmation badge. If unconfirmed rows sit next to confirmed ones, the word confirmed stops meaning anything, and the entire difference from Yelp disappears in a single line of results.

The practical consequence for the experiment: in the first week count not how many shops were walked but how many confirmed the fields people search by. That second number is the true capacity of the platform.

The unmet-demand signal: the most valuable asset in the concept

An idea absent from the original concept and stronger than half of what was in it: queries can be used not only to match existing offers but to reveal services a neighbourhood barely has. If queries for a specific service keep arriving while matching offers are scarce, that is a gap, and it can be reported to merchants in anonymised form.

Why it is valuable here specifically. Google and Yelp have this data, but they sell it as reports at scale and will never hand it to a single neighbourhood. A LOCAL with one corridor gains an asset nobody else holds: an exact map of what residents search for and cannot find, across five streets. It is the only thing in the concept that cannot be bought with money, because it cannot be copied without walking the same streets.

The limits are honest and she states them: a query is not willingness to pay, at pilot scale there is no statistical validity, and personal data must not reach the report. In practice that means: aggregate with a minimum threshold (do not report a gap below ten queries a month), never expose individual phrasings, and give the signal away free at first to earn the relationship, then sell it later as a neighbourhood report.

And one product consequence worth remembering: if failed queries are an asset, the no-suitable-option screen must not be a dead end. It has to collect the data, and it has to show the person what to do next.

Reputation: the window, the weight, and protection from abuse

The freshness window needs specifics, otherwise it turns into concealment. If the emphasis is on the last three months, that must be visible in the interface directly, as in the last three months, and earlier history must open in one click. The distinction is fundamental: freshness prioritises the recent, it does not delete the old, and the moment the window starts hiding history it becomes the same rating with a different number.

Then two different mechanisms that the concept names together though they are built differently. Contesting a false review is solved by tying complaints to an enquiry: if a complaint is not connected to an order or a query, it cannot be verified, and that is already in the construction. Protection from systematic abuse is not solved that way, because one truthful complaint and a coordinated series look identical. This needs statistics: how many complaints from one source, how many resolved, how many dismissed, and what share repeat from the same person.

And the honest caveat, unsoftened: in the pilot this is designed but not tested. Complaints will be zero because users will number in the dozens, so reputation cannot be confirmed by the first experiment, and it must not be presented as confirmed.

Account, memory and personalisation: what to promise, what not to do

Without an account a person describes a need and gets results, which I accept, and literally so: entry to the product is free and registration is a layer on top, not a gate. Saved information stays under the user's control: viewing, changing, deleting. That is hygiene, but it also solves a problem the concept does not mention: if what was saved cannot be deleted, personalisation becomes an obligation, and the first question of how do I turn this off becomes a question of trust rather than of settings.

Actions affecting reputation require an account, and here a further step is needed or the mechanic stays leaky. Registration itself does not prove that a person used the service, as the concept itself says. So influencing reputation requires not an account but a trace of an enquiry or an order, otherwise signing up becomes the cheapest way to pressure a merchant: create a profile and write. The account is necessary but not sufficient, and the rules should say so plainly.

And the blind spot I named earlier, repeated here because it is inseparable from this point: without a login, repeat use per person cannot be measured, and that is the pilot's main criterion. So an anonymous device counter is needed, and it handles privacy better than an account: count the device, not the person.

Why not Maps and not Yelp: taking the difference apart

The difference is not AI and not interface convenience, which is correct, and a question follows immediately: if not AI, then what. Below I take it apart, because each part of the difference has its own durability.

And the main thing I take from her formulation: individual capabilities, whether AI, video or personalisation, are not a durable advantage, because the large platforms are technically able to implement them. But a refinement follows that makes the difference testable: a combination is strong not because it has many elements but because it is hard to reproduce in one release. Four of the five parts are copyable in a release, and the fifth, the structure of confirmed fields for a specific service, is copyable only by walking the streets.

The assistant as an interviewer: how capabilities become visible

The extension changes the assistant's role: it not only accepts data but asks for it. A restaurant is open to private and themed dinners but says so nowhere. The owner considers it obvious or has never thought about it. A potential customer does not know whether an event can be arranged. The administrator may lack the authority to answer. That is a three-way information failure, and the assistant is the only actor who can close it cheaply, because it is already talking to the owner.

The mechanic is simple and rarely found in product descriptions: the conversation runs on specific questions, not a form. Does the restaurant consider private events and working with dinner organisers. Does the cafe take corporate orders. Can the bakery produce for other venues. Is there wholesale and are there individual terms. Are joint projects with other local businesses of interest. Each question is a field that Maps, Yelp and Instagram all lack.

Confirmation by the owner before publication I accept, with a clarification about what it must be. Not a yes to a question, but three elements for every field: what exactly, on what terms, for whom. We host private dinners, from six people, from $120 per person, by prior arrangement is a working field. Open to events is noise that will produce false matches in business search. And wherever a capability has never been exercised for a third party, it belongs behind a label of stated by the owner, not presented as fact.

And the most delicate point in the whole extension. The assistant's task is not to invent services for the entrepreneur but to help them recognise, articulate and make visible, and that is right. But the line is thinner than it looks: the assistant itself proposes a formulation, and a formulation easily becomes a claim the business does not meet. The rule must be hard: no capability is published without an explicit yes from the owner, and no formulation appears from the assistant's suggestion unless the owner has repeated it in their own words.

The B2B layer: finding suppliers, contractors and partners

The same knowledge base serves a second audience: not consumers but entrepreneurs. A bakery runs out of a specific flour and the owner looks for a local supplier working in small batches with delivery. A cafe looks for a local roaster for ongoing supply. A dinner organiser looks for a restaurant open to joint events. A small brand looks for a packaging or merch producer. A restaurant looks for a local food supplier. In every case it is an ordinary query in natural language.

The difference from traditional search is not the interface but the origin of the information, and that is the right way to put it. Directories and Maps know the name, the category and a standard description from the internet. LOCAL knows what the owner said themselves: what exactly they make or sell, which orders they accept, who they work with, what terms they offer, what constraints and specialisation they have. For instance that a particular supplier really does work with small bakeries, takes orders from a certain volume and delivers within San Francisco, and it knows this because the information came from the business rather than being inferred from its category.

The mechanic of not knowing works for the product here rather than against it: if the terms of cooperation are unknown, the system marks that and can offer to ask the entrepreneur. The missing field thus becomes a reason to talk to the merchant, and it is the same assistant already talking to them. That loop closes both the data gap and a reason to return to the product, and the concept states it correctly.

Why the B2B layer strengthens the product's defence

Before this extension my verdict was: intent search is copyable in one release, confirmed live availability is the only genuine advantage, and a combination of elements is weaker than one defensible asset. This extension changes that verdict, for the better.

The reason lies in the test I applied earlier: what is protected is what a large player refuses to collect. Maps reads menus, opening hours and structured feeds, and it has no field saying works with small bakeries, takes orders from eight units, delivers within the city. Not because it technically cannot, but because acquiring it requires a conversation with every owner, and a company optimised for global coverage will not do that. This is exactly the kind of data business search needs and indexing cannot reach.

But there is an honest counterweight, and it is serious. The capability graph is valuable only where it is dense. Incomplete capability data is worse than none, because a professional will call three suppliers, find none suitable and not come back. The density requirement in business search is stricter than in consumer search, and a conclusion about the order of work follows: B2B should be built not evenly but one whole category at a time. All the bakeries in a neighbourhood plus every flour supplier that serves them. Then a business query finds an answer; otherwise it finds emptiness.

Three sides instead of two: the cold start and what it does to the pilot

The market was two-sided, now it is three: consumers, entrepreneurs as sellers, and entrepreneurs as buyers. In general that makes a launch harder. Here the third side arrives free: the same account and the same profile that serve the consumer also answer the business query. No separate onboarding is needed, and that is a rare piece of luck in two-sided markets.

Something important for the pilot follows. A loop appears that runs inside one side: entrepreneurs serve entrepreneurs, and it needs no consumer traction. That gives an early honest usefulness signal regardless of whether the pilot attracted buyers, and attracting buyers was the central untested risk. The loop does not remove the risk, but it allows the mechanism to be tested before it is exposed to the demand question.

And a separate gain worth noting: the business layer gives a merchant a second reason to keep the profile accurate, and that reason is stronger than the consumer one. Consumer attention rewards attractiveness, while a business query rewards accuracy: a wrong statement about terms breaks a business relationship, not a picture. For data currency that beats any reminder mechanic.

And on the shape of the costs. The onboarding interview happens once and yields a dozen fields, so the cost per merchant becomes front-loaded rather than weekly. That is a different cost profile from the one I analysed at the start: more expensive to bring in, cheaper to keep. For a platform living on relationships that profile is more convenient, because most of the work falls on the stage where a person is present in person anyway.

How this fits without complicating the first version

The extension says no separate B2B platform is needed, no supplier marketplace, no complex universal agent, and that the base remains the components already planned: unified intent-aware search, structured profiles, the assistant that helps merchants describe their work and keep it current, and the gradual expansion of collaboration data. I accept that, and I can put the estimate lower than the extension does.

And one technical clarification that matters specifically for the business side. In consumer search an unknown field can simply be omitted, while in business search it cannot: an unknown critical parameter, volume or delivery, either excludes the result or carries an explicit flag that it needs confirmation. A professional does not tolerate maybe. So the ranking must be able to say not known yet, shall we ask them, which is precisely the mechanic the extension describes as marking the unknown.

Specialised tools for procurement, partnerships, proposals and extended business support, deferred until demand is confirmed, are in the right order. One thing worth adding: confirmed demand here is measured not by the number of queries but by repeat business enquiries from the same entrepreneur. The first query is curiosity, the second is need.

Money on the business layer, and the red line

The business layer is the strongest monetisation in the whole concept, and by the nature of the money it differs from consumer search. A consumer result is worth cents. A business relationship repeats and is worth thousands a year: a bakery that finds a flour supplier buys from them not once. And the query itself arrives with money behind it: a cafe looking for a roaster is not curious, it is purchasing.

There are two honest forms here: a one-off fee for verification or an introduction, or a commission on the first transaction. Selling position in business results is inadmissible in any form, and that is not ethics but the condition of the asset's existence: if an entrepreneur learns that a supplier was shown to them for money, they will not return, because in procurement a mistake is paid for in money rather than annoyance.

And the related revenue from the previous section, which this extension makes obvious: jobs and hiring. It is the same type of value, entrepreneur for entrepreneur, with acute pain and real willingness to pay (job boards charge $75 to $400 per posting). Together with business introductions, that is two revenue lines that do not depend on a consumer audience at all.

And an honest caveat on timing: with fifteen merchants, business fees cannot be tested, because there will be zero transactions. This is second-year monetisation, and the pilot's only job here is to see whether business queries appear at all.

Build once, sell twice, measure separately

The extension insists this is not a separate idea but a natural development of the core mechanism, and on the build I agree entirely: one index, one assistant, one profile structure, one intent router. There is genuinely no need to build twice.

On the go-to-market I agree only partly, and here is why. Consumer discovery is a media-like business: audience, retention, low value per session. Business matching is a marketplace: transaction value, repeat relationships, procurement logic. These are two different sales motions (consumers are not sold to, the entrepreneur-as-buyer is led personally), two different pricing logics (subscription and tools versus a fee per introduction) and two different success metrics (queries and repeat use versus completed introductions and their follow-through).

And the extension's main principle I accept verbatim: LOCAL connects not only consumers with businesses, but the capabilities of some businesses with the needs of others. It really is not a separate idea but an extension of the same mechanism: understanding the real needs of people and the real capabilities of local businesses. The only difference is that needs now also belong to businesses, and there are more capabilities than services for an end customer.

Unmet capability: the second demand signal

The previous extension had the unmet-demand signal: people ask for something a neighbourhood barely has. This extension supplies the other half of the same asset, and it is the more practical half: an entrepreneur looks for a supplier or contractor the platform cannot offer. That is not merely a gap in results, it is a gap on the supply side, and it says immediately who to bring in and why.

The practical difference between the two signals is large. The first says demand exists but not who can serve it. The second says it exactly: there is no roaster in the neighbourhood, and three people are looking for one. This turns a failed business search into a recruitment list, and the platform does it itself, without guessing at categories. The recruitment mechanic becomes the reverse of the usual one: not let us go and onboard florists, but three people asked for a florist, so florists must be found.

Mutual value: four reasons to keep a detailed profile

Two premises first, because the whole argument for a conversation rather than a form follows from them. Small entrepreneurs often have no marketing teams, and they do not always understand how to present their capabilities fully. That is not a complaint but a technical condition: a form requires the owner to know the answer in advance, while a conversation asks questions the owner may not have a ready answer to. That is why the interview works where the form fails.

Next, the four benefits the extension names for the entrepreneur. Their business becomes clearer to ordinary clients. Additional services and partnership possibilities become visible. Other entrepreneurs find them as a supplier, a contractor or a partner. And they can use LOCAL themselves for their own business tasks. Together that is exactly what the extension says: LOCAL helps a business not only be found but better explain what it can genuinely offer.

Note where the real strength sits. The first two reasons work on the consumer side and are inherently weaker: they ask for effort today in exchange for benefit later. The third and fourth change the merchant's role: they stop being merely an object in a catalogue and become a participant in a business network. The fourth is the most durable precisely because it makes the merchant a user. A person who has searched for a supplier and hit empty cards understands the value of a detailed profile without being told, and that is the best product lesson available.

And the loop that follows, named in the extension: the more detail merchants give, the more the platform knows about additional capabilities, and the more types of queries it can serve. The loop is honest but slow: at fifteen merchants it looks like nothing, and that is exactly why it cannot enter the pilot's criteria. It should be built into the construction and checked in the second or third month, when density crosses a threshold.

The cost of one honest offer

A verified, specific and fresh entry requires a conversation in the merchant's language, photos, prices, stock and re-confirmation every few days, because the stock in a bakery changes daily.

At two hours per merchant a week, fifty merchants is one hundred hours a week, two or three full-time people, before the first line of matching code.

Who already sells local data to agents

The position of "vendor of local data for AI" is already occupied, and occupied at scale. This has to be known before the pitch is built, because half of the arguments in favor of LOCAL used to sound as though the field were empty.

The conclusion from the table is unpleasant and useful at the same time. The commodity part of local data is sold and keeps selling: places, categories, reviews, menus, inventory. But none of these players has the field we have: conditions, volumes, minimum orders, delivery zones, restrictions, and all of it confirmed by the owner. Not because they cannot, but because that requires a conversation with each owner, and a company optimized for global coverage does not hold those conversations.

Closest direct competitors

Separately from the data vendors, we have to name those doing what we intend to do, but already with money and a team.

This changes the pitch, and changes it toward honesty. We cannot come out with "we are the first to connect intent with the capabilities of local businesses": that thesis already belongs to Pie with twenty-three million. The business layer already belongs to Faire at a twelve billion valuation. The communication layer already belongs to Owner.com and Slang.ai at four hundred a month. The live layer already belongs to Nventori and Hoyzee.

The live layer is already taken, and it does not make money

About real time we have to say the part that usually stays off the record: this layer is not just taken, in the hands of the leader it is loss-making. Too Good To Go grew to 150 million users and increased revenue by 28.9% for 2025, but the operating result turned into a loss of €5.4M, whereas a year earlier there was a profit of €1.8M. On October 15, 2026 the company announced entry into non-food categories. Plus the well-known market behavior: bags disappear in seconds, meaning demand exists and the money is not collected.

The full loop we describe has also already been assembled end to end, and in more than one place. Meituan: 1.5 billion annual paying users, more than 10 million active merchants, 70 to 80 million food orders a day, and a separate product, Instashops, that turns any neighborhood shop into a local store inside the main app. Douyin Local Life already hands store management to agents through connectors. The Chinese user's path looks like this: discovered in a video, compared in reviews, bought a voucher, looked at the map, paid in a messenger.

Agent access: seven layers on ready standards

The task of "being available to agents without giving away the database" is already solved by a set of published standards. Inventing our own is unnecessary and dangerous: an AI buyer reads only what is familiar to it.

The key lesson from someone else's experience: Cloudflare launched payment per visit in 2025, and on July 1, 2026 it moved to payment per citation, because a year of data showed a simple thing. A bot can take a page a thousand times and cite it zero times. Payment per visit meters traffic, payment per citation meters value. Partners in the new mode are Ceramic.ai and You.com. Price benchmarks as of April 2026: from $0.001 to $0.10 per visit for ordinary content, up to $0.20 for premium, and from $0.05 to $5 per citation.

Four access modes and what remains with the agent

The main architectural rule: agents need answers, not the database. As long as that holds, the rest falls into place by itself, because an answer is narrow by nature and does not live long.

What is never given out: the live layer as a stream, the capability graph in bulk, the derived signal of demand and gaps, and the graph of relationships with merchants. The generalization for the future reads like this: protect what ages, what is massive and what is derived, publish what is durable and what is singular.

Protection against database reconstruction: speed, not response size

The objection is fair and cannot be waved away: by returning three to five results at a time, a significant part of the database can be gradually reconstructed if enough queries are allowed. The size of an individual response is no protection here, and relying on it is a mistake.

The protection rests on four things plus one rule. Quotas are counted cumulatively per key, not per response. Diversity is limited: no more than a certain number of results from one cluster per period, otherwise the database is extracted cluster by cluster. Anomaly detection is switched on: sequential traversal, predictable enumeration, spikes in rate, repeating query patterns. And traps are placed in the database, which show that the data was collected systematically.

And an honest caveat: reconstruction cannot be fully prevented. The real goal is more modest and more attainable: to make reconstruction more expensive and slower than refreshing with us, and to secure proof for ourselves if it happens anyway.

How to measure usage honestly

Here we have to admit something inconvenient: citation cannot be measured directly. No one is obliged to tell us that our data ended up in someone else's answer, and no technical counter will show it.

Response to seven remarks: where my model changes

The remarks on the access analysis arrived in seven points. Three of them strike my own model, and that has to be written down plainly, not smoothed over.

The overall score is honest: two points were my error in framing, not in facts. I described one way of monetizing and presented it as the entire business model, and I proposed selling businesses discoverability in the external ecosystem, although we do not control someone else's ranking and could not explain a tenth place to an owner. Both errors are corrected in the sections below.

Legibility, not discoverability

This is the key correction. The promise to a business splits into two parts, because inside we control the rules and outside we do not.

Inside LOCAL we promise and explain: you land in results by what you actually offer, without thousands of reviews, without ten years of history and without accumulated popularity. We show why a particular offering matched a query, on the basis of what information, and which conditions remain unconfirmed. Here we have rules, and here we are accountable for the result.

Outside we promise only technical availability: the data is structured, confirmed, dated, licensed and cited with attribution. We do not promise placement in recommendations, because we do not know which sources an external platform considers authoritative, how it matches results and why it picks certain venues. The example that explains everything: a bakery may fit a query perfectly, we passed on accurate data about it, and an external agent will put it in tenth place or leave it out entirely. We will not be able to explain that to the owner.

Consent, conflict of interest, and what we sell

The conflict that was fairly raised looks like this: a business pays us to be found, and an external platform pays for access to information about it. The conflict exists exactly where one payment restricts the other side. So it is removed not by assurances but by construction.

Rule one: we never sell exclusivity. Business information is published in the open layer regardless of who pays for access and how much. We create a shortage for no one and close off no one.

Rule two: we never sell position. Neither in consumer search nor in business results. This is already written into the principles, and here it gains a second reason: without it, any platform payment becomes the purchase of influence.

And three consent switches, which have to be three separate visible checkboxes, each one switchable off: publication of the profile and business information, use by external agents for search and recommendations, commercial licensing of access to confirmed data. Plus a screen where the owner sees what the machine sees. Then both sides look at the same document, and there is no information asymmetry between them by construction rather than by promise.

Transparency as a mechanism: what is important to know before a visit

Of all the remarks this turned out to be the strongest and the most undervalued, because it is not architecture but a product feature that no one has.

An example: a person arrives in San Francisco, knows the language and local rules poorly. He picks a restaurant, books a table, and then learns that cancelling less than a day ahead costs 50 dollars per person, and that twenty percent is automatically added to the bill. Formally the conditions are stated, but in small print, and the person did not understand what he agreed to.

This has a legal footing, and it makes the feature sellable. In California, SB 478 is in force, a law on honest pricing: since July 1, 2024 it is not allowed to show a price that does not include all mandatory fees, and the restaurant exemption from it has been removed; according to press reports, restaurants came under the requirement from July 1, 2025. The exact deadlines for a specific case should be checked with a lawyer, but the direction is unambiguous: mandatory fees have to be disclosed in advance, and this is no longer a wish but a requirement.

One card serves three readers, and this is exactly the observation that settles the argument about narrowing: one common foundation on which several products run.

Transparency in both directions, the owner's motivation, and what to measure in the pilot

Three things from that list did not make it into the sections above, and they matter.

Language is the strongest use of the card. What matters to know before you go works best for a person who does not know the language or the local customs: they cannot read the fine print and do not know such a charge exists at all. So the card is produced in several languages, and that is how it should be sold to a restaurant: the law requires you to disclose mandatory charges, and we do it clearly and in several languages. The benefit runs both ways: the guest makes an informed decision, and the restaurant gets fewer conflicts at the table and fewer negative reviews afterwards. Transparency in both directions means exactly this: the same fields, presented differently for a person, for a business buyer and for an agent.

The boundary of transparency has to be managed, or it turns into a demand to disclose everything. Transparency means clear terms, honest promises and no hidden conflicts of interest. It is not an obligation to disclose internal mechanisms and algorithms. What we disclose is what affects the decisions of a person or a business: the ranking rules, the basis of a match, what was confirmed and when, where the data goes, what we charge for. What we do not disclose is the internal machinery, because it helps nobody make a decision and leaves us defenceless.

The owner's motivation matters more than the data, because without it there is no confirmation channel. Static information can be copied; a continuous confirmation channel cannot, but it exists only while the owner is inside the product. Broader functionality is therefore not expansion for its own sake but a condition of the asset's existence: the owner should use LOCAL not only so as to be found, but to search for suppliers, post requests, receive offers and get their own tasks done through the assistant. Relations are then built around everyday usefulness rather than around a request to update a profile. That is the most durable reason to keep data accurate: it does not depend on our politeness and does not end when enthusiasm does.

Identity: LOCAL sells confirmation

An identity built on "our AI is better" or "we will beat the existing platforms" is a promise that cannot be kept, because individual capabilities are copied in a single release. An identity built on connection, community, honesty and respect is correct, but as a slogan it is worth nothing until it is translated into mechanisms. Here are the six, and each is verifiable in the product.

Out of these six comes a single formulation worth keeping in mind as a definition: LOCAL does not sell an advantage, LOCAL sells confirmation. An advantage is when one side knows the rules better than the other, and that is exactly what must be avoided. Confirmation is when both sides look at the same document whose provenance and date are known.

Weak points, in descending order of danger (1-4)

1. The "live layer" is an operational problem, not a technical one. Nobody solved it with ease; Too Good To Go solved it with money today and is still loss-making. This is risk number one.
2. Merchant churn is what kills exactly these projects. Karma: $18M, 1.5M users, death by partner churn. verified
3. The monetisation in the concept is more careful than my first reading: labelled paid placement is allowed, and only the substitution of organic relevance is banned. What was rejected is not the strong model but its dishonest version. "You cannot pay for a better match" and "you can pay to be seen" are different things. The honest line: paid placement with an explicit label, never inside the match score.
4. "Three verified instead of ten random" is ethically right and weak as a product. The user's expectation is "show me what is nearby"; an app that often answers "I don't know" feels broken. Honesty must be a property of the interface (labels "confirmed" and "check"), not a filter.

Weak points, in descending order of danger (5-8)

5. The two-sided cold start. San Francisco is the most saturated local search market on earth, but the problem is not the competitors: value appears only when both sides exist in one corridor.
6. Google is building the same thing, for free and at scale. Agentic booking and agentic calls are already announced. There is a window, but it is closing.
7. Data is consolidating. Yelp licenses 330M reviews to OpenAI. Being "another source of local truth" against that is hard.
8. External agents as a channel: the most important and the most dangerous. If the agent answers, the app does not get installed. So LOCAL turns into a data supplier: B2B, better margin, but it needs coverage and verification, and Google is already there.

And two more questions to ask every owner in the first week, because they test the concept's hypothesis directly: how do you find customers today and which tools do you use for it, and what is missing for you. Take the answers down word for word; they are the material the product gets written from later.

And the pilot's shape as the concept describes it: 10 to 15 independent merchants from different districts, prioritising recently opened businesses ready to experiment, recruited through Instagram, personal contacts and local communities, framed as a B2B partnership rather than a plea for help, a free initial period with no promises of customer flow, and customers recruited in parallel and independently. One point where I hold a narrower position: supply can be spread across the city, demand cannot. A buyer in Bernal Heights does not care about an excellent bakery in the Sunset, so demand testing should be concentrated in one or two cells even when merchants are gathered citywide.

And one divergence from her original text worth noting: the concept began with matching queries to offers by hand, and now it is a small working version. That shift is in the right direction, but the reasons differ and both are needed: manual matching tests the conversation and query quality, a working version tests result quality. The cheapest path is both: two weeks of manual matching to collect real queries, then the small app on the same queries.

What the first version must do and what can wait

The first version's job is stated precisely: understand a specific query and offer genuinely suitable options, rather than demonstrate AI complexity. Let me make that measurable so it does not stay an intention: the share of queries answered with a concrete result carrying confirmed fields, and the share where the system honestly said nothing suitable. The second is not a failure but a working feature, and it must be counted separately, otherwise honesty will look like poor quality.

Gradualism I accept: clarifying questions, long-term memory and agentic functions come later. With one caveat that matters more than the principle itself: in the first version there can be only one clarifying question. Two questions turn a conversation into a form, and the person leaves for Maps, where there is no form at all. That looks like a technical limit but it is a product one, and breaking it is the most expensive mistake available.

Scaling: representatives, standards and their limits

After onboarding, most interaction runs through self-service and the assistant, and that changes the hiring structure, not just the costs: a person is needed per neighbourhood cell, not per merchant. One operator runs a street rather than eighty cards, and that is the only form in which relationships scale.

On-site checks by paid contractors I accept, with a clarification: it is the only kind of check that can be bought and that requires no trust in someone's judgement. Whether a venue exists at an address is checkable, whether the work is good is not. So such a check must never be presented as confirmation of quality, and wherever it is shown it must state what was checked: the venue operates at this address, as of this date. Otherwise verified reads as good, and that is deception rather than imprecision.

And I record the status honestly: this is a potential direction for scaling, not a settled organisational design, and the open question is not how many partners but how to verify that a partner is not selling results. That can only be answered by measurement: the same queries run across different cities must produce results that follow the same logic, and that is testable.

What is technically hard and what is easy

The minimum experiment: three weeks, almost no money

Step 0, half a day, before anything else. Take five example queries from the concept and run each through Google Maps, Google AI Mode or ChatGPT, Yelp and Instagram search. Note in a table: did it find a specific suitable offer, with a price, with stock, nearby.

Step 1, week one: one corridor, 12 establishments, 3 categories. Walk Noriega (or your own street) on foot. For each: a photo, real offers with prices, stock, in their language. Publish one page per establishment (Carrd or Notion) plus a QR sticker on the storefront. One question to the owner: "what do you want more of?" and "what would you pay for?" Write the answers down word for word.

Step 2, weeks 2-4: one demand channel, zero development. Once a week, one message "what is fresh on Noriega" to the neighbourhood groups plus a form "ask anything about this street". Marina answers by hand, in any language, within an hour, with a real offer and a link to order. No app.

Metrics and kill criteria

Disputes without a public arena

The concept raises a question most pitches skip: users need a way to report real problems, the merchant needs a fair right of reply, and public wars in comments and star ratings are not an acceptable model. That is a precise statement of the problem, and it matters more than it looks.

The reason is simple. In local commerce a merchant's reputation is their most valuable intangible asset, and a rating with one button for bad, with no purchase attached, turns that asset into a bargaining chip. A platform promising to show only what is confirmed must promise the reverse too: no unverified accusations in a public field.

The cost of that construction is small: it is policy plus a little code. The expensive part is different, namely refusing to build the rating everyone expects, and patiently explaining to every early merchant why there are no stars.

The human factor as an asset, not a phase

The concept says relationships with merchants may remain a durable part of the value after automation, and that building an advantage on the mere use of AI is weak. Both are right, and the second is stronger than it may appear: if AI is a commodity available to everyone, then exactly three things stay hard and defensible, and all three are made by hand.

An unglamorous hiring consequence follows. The first employee of such a company is a neighbourhood operator, not an engineer: someone who walks, speaks the owner's language and keeps the records straight. The founder's own walking at the start is not preparation for the business, it is the seed capital, and it cannot be bought.

Why this is not another Yelp: testing the argument

The concept's section on the difference from Yelp is more honest than most pitches: it says the platform does not compete on the number of venues, reviews or search traffic, but on finding a specific dish, service or offer. And it immediately concedes that merging existing features is not an advantage, and that the value of such an experience still has to be proven.

That concession matters more than the difference itself. The difference describes what the product is not; the concession admits that proves nothing. To separate a feature from a business I ran the three questions that usually settle it.

The multi-agent architecture: why it is not needed on day one

The concept says plainly that a complex multi-agent architecture is not needed from the first day, that many tasks can be solved more simply, and that architecture should follow the product's needs rather than the reverse. That is correct, and it can be said more precisely: here is what the first version actually needs.

And the risk worth naming directly: agent frameworks installed on day one add failure modes you cannot debug across three merchants. The question from an owner, where did my croissant go, is answered by a row in a database, not by an agent.

What LOCAL does instead of fighting for attention

A formulation from the concept worth keeping verbatim: help a person find what genuinely suits them, and help an independent entrepreneur be discovered through the quality and specificity of their offers rather than a constant fight for attention. This is not just a mission, it is the product's promise, and it is testable: be discovered on merit, instead of be noticed. If LOCAL ever starts selling notice, the promise is broken, and it will show in the results, not in the words.

And the list of risks she acknowledges in the conclusion I accept entirely: customer acquisition, a sufficient volume of offers, information quality and currency, operating costs, monetisation, competition from large platforms. That list is precisely what the pilot is obliged to test, and I add one item that is missing from it: the ability to keep confirmed data current, because that is what separates LOCAL from Maps and that is where the manual time goes.

And finally on the unmet-demand signal, which she names as an additional possibility and which is genuinely worth more than most of the mandatory parts: it helps businesses find opportunities to grow. One risk must be named: if the signal is given away free to everyone, it stops being LOCAL's advantage and becomes ordinary consulting; if it is sold, the merchant expects a guarantee of demand that the data does not contain. There is exactly one sensible framing: the signal is free and anonymised, and what is sold is not the data but help in verifying it.

What I would change in the concept

1. Drop the word "platform" at the first stage. This is a one-block service with a database.
2. Sell the merchant the benefit today, not visibility someday: fill an empty slot, sell the surplus, find customers outside their own language community.
3. Allow paid promotion with an explicit label. The ban only inside the match score.
4. Build the consumer app last. First the merchant tool "say it once, it updates everywhere" plus a public machine-readable page for the establishment for agents.
5. Choose the first categories by frequency and urgency, not by beauty: pastries and prepared food (a decision today), open slots at service providers (money is lost every hour), flowers (an event with a date). Custom cakes are a bad first category: a rare query, a long cycle.
6. Start with the corridor where the language gap is largest, not with an "interesting neighbourhood": Noriega or Irving in the Sunset. 53% Asian, 14% of households with limited English, 42% born outside the US: that is the market for the multilingual wedge. verified

Cross-check: every claim in her corrections and where it is addressed

Completeness should be checkable, so here is the article-by-article cross-check. Her corrections and the extension contain one hundred and seventy-three separate claims; each is assigned to the section where it is addressed, including the cases where the treatment amounts to agreement.

Eleven of the first hundred and eleven claims stay outside the document deliberately, and here they are: the illustrative details she uses to explain theses already covered (the bakery's bread varieties, the specific technician, the studio opening). They add no new product requirement, so they are not entered as separate points, but their sense is accounted for in the sections on the profile, on the technician example and on paid placements.

Verdict

As a platform the idea does not hold up: two-sided cold start, the refusal of money for promotion, the live layer as endless manual work, and Google building the same thing for free.

As a single-corridor service with verifiable live offers and a multilingual surface it is coherent, testable in three weeks and with almost no money, and it comes down to one question: are merchants ready to confirm stock themselves, without reminders.

Sources

Every figure in the document has a source given inline. A summary of the sources by section.

Three facts verified by hand: the Karma shutdown, Yelp licensing its data to OpenAI, the District 4 demographics. They are marked with the verified marker throughout the document.