A breakdown of the product itself: surfaces, data model, flows, rules, the lifecycle of information, metrics and the boundaries of the first version. Assembled from the whole concept, all corrections and all the research. The market breakdown and the access architecture for agents stay in a separate document.
This document answers the question of how it works, not whether it is worth doing. The market, competitors, economics and access for external agents are covered in a separate analysis document. Here it is only the product: what it consists of, what happens to information inside it and how to verify that it works.
One sentence from which the whole construction follows: everything rests on a single record about a business that the owner confirmed himself. There are five surfaces, each serves its own need, but they share one set of data, and that is why the product does not fall apart into five separate services.
A surface is not a section of the app but a separate need with its own scenario. LOCAL has five, and all five read one record.
| Surface | Whose need it serves | What it reads from the record |
|---|---|---|
| Search | A person needs something specific: a vegan cake, an appliance repair person, a bouquet within a budget | Profile, capabilities, live layer |
| Discovery | A person explores the area and does not know what they want | Profile, novelty, updates |
| Community | A person wants to know what is happening around, without a query | Updates and events with a limited lifetime |
| Business layer | An entrepreneur looks for a supplier, a contractor, a partner | Capabilities: terms, volumes, areas, lead times |
| External access | An external agent answers its own user's query | Confirmed fields for a specific query |
The split is not for beauty but for one reason: each surface has its own ranking criteria and its own promises. For a person, distance, match and freshness matter. For an entrepreneur, the match on capability, terms, volume, area and lead time matter. For an agent, getting a confirmed fact with provenance matters. A single ranking for everyone would break at least two of the five.
Job statements matter more than a list of features: they define what counts as success and what can be removed without losing the meaning.
The product rests on one record about a business. Not on a card and not on a page, but on a record that has fields, and every field has four mandatory properties.
| Field property | What it means | Why it is needed |
|---|---|---|
| Value | The fact itself: from eight units, delivers within the city | It is what gets matched against a query |
| Provenance | Who confirmed it: the owner himself, an on-site check, or derived from a conversation | The label declared by the owner versus verified |
| Confirmation date | When this was last confirmed as true | Freshness and the decision whether to show the field at all |
| Publicity and permissions | Open to everyone, available to agents by key, available only inside LOCAL. Plus three owner switches | Separates what is published from what is licensed |
Plus a lifetime, and it is not the same for all fields. This is the fifth property, but it is easier to describe separately, because it drives half of the product decisions.
An average star. A best field. A paid recommendation field. Any field filled in by a guess. And fields derived from activity: view counts, save counts and a popularity rating do not enter the ranking, they live in separate analytics where they do not affect the results.
The main flow of the product, and the only source of data: the owner speaks, the assistant structures, the owner confirms, the field is published. Four steps, and between the third and the fourth stands the product's only safeguard against invention.
A field counts as confirmed only if three things are derived from the conversation: what exactly, on what terms, for whom. Plus a date. Open to events is not a field, it is noise that will produce a false match. We host private dinners, from six people, from 120 dollars per person, by prior arrangement is a field. The difference between those two statements is the difference between a product and a catalog.
And two constraints that make the flow cheap. First: one conversation of twenty to forty minutes at onboarding yields about a dozen fields, so the main cost of bringing a merchant in is upfront, not weekly. Second: later updates are made by the owner himself in one sentence, so our hours go into onboarding, verification and exceptions, not into entry.
A single decision explains search, the live layer and updates alike: every field has a lifetime, and it is determined by the nature of the field, not by our convenience.
| Type | What it contains | When it spoils | What to do when it spoils |
|---|---|---|---|
| Permanent | Specialisation, services, portfolio, the owner, the story of the place | Months and years | Updated at the owner's discretion, the field stays visible |
| Weekly | Terms, delivery areas, minimum batches, seasonal items, special offers | Days and weeks | After expiry it leaves the ranking, but stays in the profile with a date marker |
| Live | Stock, free slots, a fresh batch, an event today | Hours and days | Disappears from the active layer entirely |
The news of an opening lives two days, but the fact opened in October 2026 must stay in the record forever. On expiry, every temporary event writes a durable attribute into the profile: opened, refreshed the menu, moved, added a service. Otherwise we lose the durable value of the temporary element, and the new filters stop working without a live feed.
The same reasoning dictates what to show and what not to. A field past its lifetime is better hidden than shown with the caveat possibly out of date: the caveat teaches the person not to trust the label. A hidden field is more honest than a marked one.
| Flow | Who starts it | What happens | How it ends |
|---|---|---|---|
| Onboarding | The founder comes to the owner | Conversation, structuring, field confirmation, a snapshot | The record exists, the merchant is in the product |
| Update | The owner speaks to the assistant | The assistant clarifies, structures, asks for confirmation | The field is updated, the event is created, the date is set |
| Consumer query | A person describes a need | Matching against confirmed fields, ranking by distance, match and freshness | Three to five options with an explanation, or an honest no |
| Business query | An entrepreneur looks for a supplier | Matching by capabilities, a separate ranking, strict handling of the unknown | Options with terms, or unknown, needs clarification |
| External query | Someone else's agent | Authentication by key, an answer to a specific query, a counter | A confirmed answer with provenance and attribution |
Three of the five flows are served by the same assistant and the same record, and that is the main argument against a separate business platform. The fourth differs only by ranking, the fifth only by the access wrapper.
Ranking is the one place where the product decides whom it serves. There is no room for configuration here: the rules must be stated once and protected from our own wish to do the familiar thing.
The fifth idea of the concept and the most underrated one, because it answers a question nobody answered before it: why should a person open LOCAL when they have nothing to search for.
The mechanics: a small block of current changes, each living a limited time depending on the nature of the event. A coffee shop opening holds for a day or two, a Friday promotion disappears after the promotion. The owner publishes it himself through the assistant, in the same way as the other fields. No ratings are assigned, there are no scores, the word best is not used: only the fact and its freshness are reported.
| Format | What it reports | Lifetime |
|---|---|---|
| Just Opened | A new business appeared in the area | One or two days |
| Coming Soon | A known opening date | Until the opening, then it becomes a profile attribute |
| New & Updated | A new product, a new service, a menu refresh | Several days |
| Closed or Moved | The most useful news: do not go today | Several days, then a profile attribute |
| Local Offers | A promotion, happy hour, a tasting, an event with a date | Until the event ends |
The fifth format, closed or moved, was added to the four from the concept, and it is the most useful for a person: the only way to learn that a venue has closed is to walk up to a closed door. It is also honest, because it does not require judging quality.
First: there are no paid placements in the community at all. Not labelled ones, but none. This is exactly the surface where Yelp, Maps and social networks make their money, and as soon as you can get into what is happening for money, the feed becomes advertising and the promise of no artificial recommendations dies. Paid offers live in a separate module with an explicit label and are never mixed with updates.
Second: one update per business per period. Without a frequency limit the feed rewards the active rather than the relevant, and a fair chance for the small turns into whoever announces loudest. The queue rotates: if there are more businesses than slots in the view, we show them in turn, not by posting frequency.
And three things about this mechanism that must be said plainly, because what it does not become depends on them.
This is not a feed and not an editorial desk. To show what is happening around you do not need a city newsroom and you do not need an endless feed a person falls into. You need a short list of confirmed changes, where each lives exactly as long as it is genuinely current. That is precisely why this is within reach of a small team, not of a media holding.
It is shown to those it concerns, not to everyone. Once the owner confirms it, an update appears for the people it is potentially interesting to: those in this area, those who marked this category, those who have visited this place before. For a business this is the main benefit: it speaks not into a void but to an interested local audience, and it does not have to pay for the fact of an opening to become news for the community.
The goal is not for the city to learn about the platform but for the city to learn about itself. The life of an area is made of small events: a coffee shop opened today, on Thursday the bakery has a new pie, on Friday the restaurant has two hours of discounts. None of them amounts to news, and together they are the life of the city. That is why the statement for the product reads not as we show places but as we help the city learn about itself, and that is why a person decides for themselves whether this place is interesting to get to know: we report a fact and its freshness, not an opinion and not a judgement.
This is not a tagline under the logo but a requirement for the product: it does not matter how long you have lived in this city, whether you know the language or whether you know the rules. A neighbour does not have to earn the right to know what is happening on their street, and a small business does not have to earn the right to be noticed in its own area. Search helps you find what you need. Community helps you learn what is happening.
Personalisation determines relevance, not quality and not popularity. That is correctly written in the concept, but personalisation has a built-in trap the product almost fell into once already: it locks a person onto what they already love.
| Signal | What follows from it | Constraint |
|---|---|---|
| Area | What is happening on your streets | At least one item in every view from your area, regardless of interests |
| Interests | Coffee, pastry, appliance repair, specific categories | No more than half of a view from a single category |
| Past interactions | Businesses the person has already viewed, saved or visited | No more than one item from the familiar circle per view |
| Time and occasion | A Friday evening, the weekend, the morning | The occasion does not replace the area: a Friday offer from the other end of the city is not shown |
An interest easily slides into a bubble, an area cannot: a street is objective. So geography takes priority over interests, and this rule is worth checking with a number in the pilot: the share of views where a person saw a business they did not know before. If it falls, personalisation is eating discovery, and discovery is half the value.
A habit is formed not by an icon but by what accumulates for a person. So retention is designed not around the interface but around accumulation, and we have three such points.
The first is the main point, because it is the only thing that cannot be moved into someone else's product: a hundred saved places create switching costs. Entry into the product is free and without registration, so an account is offered only after the first useful action, not before it, and it exists precisely so that accumulation becomes possible.
The third point is tied to the community, and it must be limited strictly, otherwise the product turns into a mailing list. Notifications are allowed only under three conditions: your area, the formats the person marked themselves, and no more often than a set frequency. Everything else is a path to deleting the app, not to coming back.
The goal is not for a person to spend more time in the app. A person can open LOCAL for two minutes, learn about a new coffee shop and go there, and that is a complete success. So the metric is not time in the app but the share of visits that led to an action: to a save, to a route, to a profile, to an order. Time in the app as a goal would directly violate the community first principle.
Transparency in this product is not a section with rules but three areas of the interface that a person or an owner sees.
We disclose what affects the decisions of people and businesses: the search rules, the grounds for a match, what is confirmed and when, where data goes, what we charge for. We do not disclose the internal kitchen and the algorithms, because that helps nobody make decisions and leaves us defenceless.
Business search is not a second product but a different ranking of the same record. This is worth remembering, because the temptation to build a separate supplier marketplace will come up constantly, and the answer is always the same: the same data, different criteria.
| What the entrepreneur asks | Which field answers | Why this is missing from ordinary catalogs |
|---|---|---|
| Does he work with clients as small as me | Who he works with, minimum volume | Because this is established in a conversation, not in a data dump |
| From what volume he takes orders | Minimum batch | It is not published in any category |
| Will he deliver to me | Delivery area | The index has no such geometry, but a conversation does |
| How fast | Lead time | Not published, because it changes |
| On what payment terms | Payment terms and commitments | Discussed only in correspondence |
In consumer search a thin layer is tolerable: a person finds two bakeries instead of five and leaves satisfied. In business search emptiness kills everything, because a professional calls three suppliers, finds none that fits and does not come back. So one category must be onboarded in full: all the bakeries in the area plus all the flour suppliers for them. An even layer across the city looks like the absence of a product in business search.
For the product this is not infrastructure but one surface with four modes and one rule: agents need answers, not a database.
| Mode | What the external agent sees | What it keeps after maximal use |
|---|---|---|
| Open layer | Profile: name, category, area, services, hours, photos | The knowledge that a business exists and what it does. Nothing more |
| Attribution | The same, plus a mandatory source link and usage reporting | A citable fact and our demand signal in the report |
| Answer by key | Confirmed fields for a specific query, with no full dump | A set of answers that decay along with the data |
| License | A data class under contract, without the live layer and without the capability graph | A snapshot of a low-sensitivity class, with reporting and a ban on resale |
In the product this appears as one screen for the owner, what machines read about you, showing which fields go outside, which stay inside, and three consent switches. The open layer also carries a license file and preference headers, so the terms do not have to be explained to every agent separately.
| Surface | Who pays | For what exactly | When it becomes possible |
|---|---|---|---|
| Onboarding and upkeep | Business | Personal labour: the conversation, field collection, initial setup | Immediately, before any product at all |
| Hiring and jobs | Business | The value of an entrepreneur for an entrepreneur, independent of audience | The first month |
| Business introductions | Business | A one-off fee or a commission on the first deal, never for position | When the category is dense |
| Additional tools | Business | Automation, integrations, analytics, an extended assistant | The second year |
| Answers for agents | Platform | A verified answer with provenance, payment per citation | When there is a volume of requests |
| Labelled placements | Business | A separate module with a label, never in the community and never in business results | When there is an audience |
We sell three verbs that only we perform: we verify, we aggregate, we keep current. We do not sell position in any form. We do not sell exclusivity. We do not resell the owner's facts as goods: the facts belong to him and lie in the open, and we monetise the work on them. That is what removes the question of a conflict of interest, not assurances of honesty.
| Surface | Main metric | Threshold named in advance |
|---|---|---|
| Search | The share of queries with a specific confirmed answer | Less than a quarter against four major players means the combination does not work |
| Search, honesty | The share of honest nothing fits | Counted separately; a fall to zero means we are padding the results with junk |
| Profile | The share of visits that led to an action | A save, a route, a profile or an order. Time in the app is not a metric |
| Community | Digest open rate and the share of actions afterwards | If the digest is not opened, the surface is not a reason to return |
| Business layer | The number of supplier requests and the share of those acted upon | Measured separately, not mixed with consumer ones |
| External access | Keyed requests and the share of answers with attribution | Payment per citation only on a measurable base: visits and requests |
| Merchant | The owner's own repeat use of the product | If the owner does not return, the confirmation channel does not exist |
The version tests three things and nothing more: whether the system understands a specific query, whether the confirmed information is sufficient for a decision, and whether a person returns without a reason to search. Anything that does not serve those three questions is postponed, even if it looks useful.
| What is included | What is postponed and why |
|---|---|
| An assistant that talks to the owner and asks for confirmation | A full conversational interface with memory and agentic functions: in the first version there is at most one clarifying question |
| Profile, capabilities, live layer as fields with a lifetime | Point of sale and booking integrations: not needed to launch, the complexity is not justified |
| Search with two rankings over the same data | A separate business platform or marketplace: there is no new data |
| A profile card with the terms before a visit | Reputation mechanics: there is no data at pilot scale, it is being designed now and shown later |
| A weekly digest of changes in the area | A live feed and notifications at scale: with fifteen merchants the feed is empty |
| An open layer plus a license and preference headers | Paid agent access: first we need to be noticed at all |
The search loop runs on intent and returns rarely. The update loop runs on curiosity and returns often. That is why the community is not decoration but a second reason to exist, and it is what turns the product from a directory into a place people visit without a reason.
And for the same reason the two loops must be measured separately. If a person comes only with a query, the product competes with Maps on their own turf. If they come to learn what changed, they compete with social networks, but with one advantage: it does not demand attention for the sake of attention and does not force scrolling.
The what is happening around idea is analysed separately, because it is new and because whether the product becomes a place with a habit depends on it.
| Its proposition | My verdict | What changes |
|---|---|---|
| Show changes around you instead of waiting for a query | Agreed, this answers the main open question | A second retention loop appears, independent of intent |
| Assign no rating and never call anything best | Agreed, it is the same principle on a new surface | The confirmation label becomes the only mark, and it speaks of provenance, not quality |
| Every update lives a limited time | Agreed, with an addition | On expiry the event writes a durable attribute into the profile, otherwise the durable value is lost |
| Four formats: opened, soon, new, offers | Agreed, but one is missing | A fifth format: closed or moved. The most useful news and the most honest |
| Personalisation by area, interests and past interactions | Agreed with a caveat | At least one item from your own area regardless of interests, otherwise an echo |
| Ordinary updates and paid placements are distinguishable | Disagree, it must be stricter | There are no paid placements in the community at all. Paid content lives in a separate module with a label |
| A business does not have to pay for an opening to become news | Fully agreed | This is the fair chance in action, and it must be written in the rules in plain words |
| The owner tells the assistant, the assistant confirms | Agreed, it is the same channel | Every update strengthens the reason to keep the assistant in daily use |
| The goal is not for a person to spend more time | Agreed, and this must be turned into a metric | The metric is the share of visits with an action, not time in the app |
| Test in the pilot whether people come back for updates | Agreed, but with a cheaper method | A weekly digest for one area is tested, not a live feed |
A frequency rule: one update per business per period and a rotating queue. Without it a fair chance turns into whoever announces loudest, and the feed starts rewarding activity instead of relevance. Plus feedback to the owner: he must see that someone opened his update or followed it. That is the reason to publish a second time.
Some questions are decided neither by research nor by conversation, and it is worth admitting that in advance so as not to argue about them for months.
Completeness must be verifiable, so below is the correspondence between what came from the author of the concept and where it is covered in the product. Coverage is checked by a separate script across all statements from all messages.
| Source | What was taken from it into this document | Where it is covered |
|---|---|---|
| The main concept | Five surfaces, data model, flows, three lifetimes, ranking rules, community, personalisation, retention | Sections 1-11, 17 |
| Corrections to the analysis | The business layer, the optional live layer, the mixed catalog, reputation, registration, the boundaries of the first version | Sections 5, 12, 13, 15, 16 |
| The supplement on the assistant and the business network | Conversation as a source of data, the business network, the owner's motivation, the scope of the first version | Sections 4, 12, 14, 16 |
| The access analysis and transparency | Four modes, three switches, the terms card, the boundary of transparency, monetising the work | Sections 11, 13, 14 |
| The updates idea | Community, five formats, frequency rules, personalisation against the echo, the visit-with-action metric | Sections 8, 9, 10, 19 |
The product is viable and internally consistent: one confirmed record feeds five surfaces, the two retention loops work on different psychology, and all the ranking rules serve one promise. The vulnerability is not in the construction but in two numbers nobody has measured yet: the density of confirmed data and the owner's return rate. Both numbers are tested by the first pilot, and both decide more than any feature added after it.
ARLI membership: the notes from the workshop
One site of yours, measured, with the price for the work in the same document
ARLI, Inc., a Delaware corporation. Questions: hq@arliwork.com.