LiquidSilicon runs franchise development as a briefing, not a database. It watches your candidate pipeline from first inquiry through qualification, Discovery Day, validation, the FDD and the franchise agreement into onboarding and active — then deals you the one decision that needs you: a territory two applicants both want, a candidate stalled before their FDD, a royalty report drifting from its baseline. One card at a time, each carrying why it surfaced and how to answer. Reply in a tap, or just talk back.
This is not a generic CRM with the word “franchise” pasted on. The console models the objects and stages franchise development runs on — candidate leads, territories, and the financial qualification in between — so the briefing speaks in your terms from the first morning.
The candidate lifecycle as it really runs — Inquiry, Qualified, Application, Discovery, Validation, Approved, Agreement, Onboarding, Active, Renewal. Every lead sits on exactly one stage, so a briefing can tell you who is stuck where without you opening a report.
Investment capacity, liquid capital, and net worth are first-class fields, alongside a lead score and the source that brought them in — website, referral, broker, trade show. The console qualifies on the numbers a franchisor actually screens on, not a generic contact record.
Territories carry region, state, city, population, franchise fee, and an availability flag — so an application against a territory already taken is a fact the console can see, not a spreadsheet someone forgot to check.
This is the adaptive core doing the work. You describe your operation in plain language; the config-driven runtime generates the console — no schema to author, no rebuild to sit through. The right-hand side below is not a mockup: every object, stage, view, and menu is read straight from the franchise template the product actually runs on.
We develop two fast-casual franchise brands. Candidates come to us through our site, referrals, and brokers. We qualify them on liquid capital and net worth, check the territory they want is still open, and run a Discovery Day. Approved candidates get the FDD, sign the franchise agreement, and move into onboarding until the location is active.
The agents triage the whole pipeline in the background and only bring you what needs a decision. These are the kinds of thing they watch for — capabilities of the same briefing engine, not numbers from a fictional customer.
A territory two applications both want. Two candidates advancing on the same preferred territory, or an application against a territory already marked taken. The console reads the territory field on every lead, so the conflict surfaces as one decision instead of a collision found after an offer goes out.
An application stalled before its FDD. A candidate sitting in Application, Discovery, or Validation with no movement toward Agreement while their expected close date slides past. The briefing names the one going cold before the FDD, so a good candidate does not quietly age out of the pipeline.
A recurring number drifting from its baseline. The Observer watches any recurring figure you describe to it — a royalty report, a weekly unit sales number — and flags the one that breaks from its own trailing baseline. It is the same anomaly engine the rest of the console runs on, pointed at whatever stream your config models.
A lead that never got qualified. An inquiry that has been assigned but has no liquid-capital or net-worth figure recorded, or no score — a candidate in the pipeline you cannot actually judge yet. The console flags the gap so qualification happens before a Discovery Day is spent on it.
Between franchisors: hard isolation, today. Every tenant is separated from every other in PostgreSQL itself, with row-level security that is not just enabled but forced — so even a bug in application code cannot leak one brand’s pipeline to another. This ships now; the security brief names the file that backs it.
Within one franchisor: one shared workspace, today. All of a brand’s locations and development staff currently share a single tenant. There is no per-location wall yet — a regional manager sees the whole pipeline, not only their territories.
Per-location scoping is on the roadmap, not shipped. Scoping a user to their own territories and locations is planned, and we will say so here the day it lands. We would rather name the gap than claim an isolation boundary we have not built.
Describe your franchise operation, and the console is generated to fit it — free to start, with the agents drafting and you confirming everything. Move up the trust scale as they earn it.
The territory checks, the stalled applications, the numbers that drifted — surfaced one decision at a time, each ready to answer in a tap or a sentence. And as your franchise system changes, the console changes with it.
Free tier · Humans confirm every change