You know an industry — climbing gyms, dog groomers, tutoring centers, tattoo studios, dance schools. LatticeKit already runs scheduling, memberships, checkout, payments, a real ledger, messaging, staff and automation for businesses like them, one isolated business at a time. Build the part only you know, and sell it.
See it before you build anything. Describe one of the businesses you would sell to, and Beth, our AI assistant, builds a working copy you can book into, at its own address, for a week. No card.
Pick the industry you know. Describe one business in it to Beth — what it books, what it sells, who works there, when — and she builds it as a working copy you can book into. That is the first customer-shaped thing your product runs.
Your vertical: the vocabulary, the screens, the flows the industry expects. Build the screens in the page builder without code, or bring your own front end over the API. Everything under them — scheduling, memberships, checkout, payments, ledger, messaging, staff, automation — is already there, configured rather than coded.
Every customer is its own business on LatticeKit: its own data, its own credential, its own usage bill. A new one starts from a starter bundle — ten ship — or from the configuration you proved with your last customer, exported as one document and applied to the next. Whatever they used before comes over with the import engine.
# One customer, as one document
business: crux-climbing
hours: Mon–Sun 6:00–22:00
offers: day pass · monthly
· intro class
resources: walls ×12 · belays ×4
tiers: member · family
pages: home · book · passes
workflows: waitlist-fill
· dues-retry
plan → what would change,
nothing destructive
apply → summit-bouldering (#2)Every part shares one customer record, one ledger and one event stream per business, so a booking, a sale and a reminder never disagree about who the customer is.
Courts on the hour, services that take as long as they take, classes with capacity and a waitlist, queues, multi-day stays, group bookings with rosters, and rules for who may book when.
Tiers, households, class packs, dues on a stored card, and retries that follow a policy instead of a script.
Tabs and carts, tips and splits, cards through Stripe or Finix under each business’s own account. Double-entry books, invoices, gift cards and store credit, CSV to the accountant.
Email, text and push from templates, sent only to people who said yes. Two-way conversations between a business and its members, and among its staff.
Shifts, swaps, a time clock, timesheets and payroll-ready totals. Purchase orders, receiving into inventory, bills and reorders.
Workflows without code, triggered by an event, a schedule or a state, durable when they span days. Reports off every event, live feeds, and experiments that find the better price.
Also in the box: an AI assistant your customers can talk to, an MCP endpoint for the assistants they bring, partner channels and calendar feeds in both directions, support cases and a post-visit feedback funnel, marketing audiences and promo codes, access control at the door, and a bulk import engine. E-signature is in progress.
Each of these is live for every business and switched on by configuration, not by a project.
Price by tier, channel, time and demand: overrides, pricing rules written as expressions, yield and surge, bundles, buy-one-get-one and promo codes redeemed at close. Rules are checked when written and fail safe when they run.
Multi-armed bandits over a price, an offer, a page layout or a setting. Each customer is assigned to one arm and stays there, revenue is attributed to the arm that earned it, and the experiment converges on its own and hands over the winner.
Durable execution keeps its place across restarts and days-long sequences. Every side effect runs with idempotency, retries and compensation, and every state change lands in a transactional outbox before anything downstream reacts. Nothing fires twice; nothing is lost.
A scenario runs against the real configuration with every side effect neutralised and returns a verdict. A plan shows what a change would do before it does it, a pinned plan cannot drift, and an earlier document re-applies to roll back.
Double-entry ledger, invoices, multi-rate tax, stored value on the same ledger, exports for the accountant. Money is a balanced posting rather than a status field, which is what makes a period closeable.
Several processors behind one interface, tokens only, refund caps, signature-verified webhooks, disputes with evidence submission, and card-present terminals.
Operator screens update from the event stream as it happens, keyed per business and per location, so a second site sees its own numbers move.
Every action lands on a named meter and is rated per business. Limits the business sets are enforced within fifteen minutes, and usage is on the page hourly.
Tiered writes, proposals for anything consequential, daily ceilings on calls and money, sandbox-only grants, and an audit line for every call.
Beth sets a business up. The next piece lets each business have its own assistants — and lets you define them once and hand them to every customer you onboard.
An assistant is a short definition: who may talk to it, whose authority it runs with, which tools it may use, how it speaks, and where it appears. It travels in the same business document your starter does, so the assistant you get right for customer one applies to customer two.
The one invariant, and the reason you can put one in front of customers. A toolset reaching past what that person could do themselves is refused when it is saved and checked again on every turn. A customer’s assistant reads that customer’s own records because the platform scopes the read to the proven session, not to an id the model wrote.
Knowledge is searched, not stuffed into a prompt: entries the business writes, plus its own published pages as a visitor sees them. Anything behind a sign-in is staff-only and never answers a customer. Search first, answer from what was found, name the source, say when there was nothing.
Expose any automation you have built as a tool with a name and a declared input. The assistant calls it validated, confirmed by a person where it matters, and traceable from the run back to the conversation that asked.
The same definition answers instantly in the message thread a customer already uses — stepping aside the moment a human replies until the desk hands it back — or sits on a published page as a chat component, or opens as a staff thread in the console.
Turns run under the smallest of three limits: the assistant’s, the business’s and the platform’s. One switch stops them all, a business can bring its own model key, and the tokens land on the same usage page as everything else, so nobody is surprised by a bill.
Working in the build and in review now — the definition and its authoring screens, the engine with confirmation and a full record of every call, knowledge, the customer thread with staff takeover, workflows as tools, the site component, and assistants in the business document. Not on production yet. The spec is on the Ellis page.
Your first customer wants memberships that bill themselves, and all you have is a booking calendar.
Tiers, households, class packs and dues on a stored card with retries are already there. Turn them on for that business.
Customer three opens a second location.
Locations are a scope on every record and every credential, enforced centrally. You wrote no filter, and the reports come out per location on their own.
A customer asks whether their data is separate from everyone else’s.
Every record belongs to exactly one business and nothing crosses between them; the business is carried by the credential, never by a parameter. You can say yes and mean it.
You set your own price for your product and bill it however you like. LatticeKit bills each business for what it actually did — bookings, sales, messages — on the card on that business’s account, and takes no percentage of what they sell. Two small bills: one for your product, one for the engine. A wholesale plan, one bill to you for all of your customers, is a conversation today rather than a switch — hello@latticekit.app.
No platform fee, no per-seat licence, no minimum. Each business your customers run on LatticeKit is billed each month for what it actually did — bookings made, sales rung up, messages sent. API calls are free. A quiet customer is a small bill, and a customer you have not signed yet costs nothing.
Also on the bill
Estimate for one business, not a quote — each is billed for what actually happens, itemised on its Usage page. Bookings and sales are 5¢ each, email 60¢ a thousand, texts 2¢ each (what the carriers charge us), a hosted page 3¢ a thousand views. Beth is billed by the token — about 8¢ for a typical question. Forms and API calls are free; imports and automations come to cents at these volumes. Multiply by the customers you sign.
Not to build the screens or to set a business up. The page builder drafts a screen from a description and you adjust it on a canvas; Beth changes a business’s configuration from a sentence. If you want your own front end, wiring it to the API is integration work a coding agent can do most of — the documentation is written for them, starting at llms.txt.
You charge for your product, at your price, on your terms. LatticeKit bills each business for its own usage on that business’s card, with no platform fee and no percentage of what they sell, so your margin is yours. If you would rather hold one account for all of your customers, tell us at hello@latticekit.app — that is a conversation today, not a switch.
One export per customer — CSV, JSON, XLSX, or a ZIP of the lot — with the mapping proposed from the column headers, a dry run that shows every row before anything is written, and old ids remapped so files that point at each other still do. If their data sits in a database you can reach, a read-only replica works instead of files: PostgreSQL, MySQL or SQL Server, mapped onto the platform’s model with you and re-runnable so the cutover is not a freeze. That one we set up with you during onboarding — tell us what they are on.
Through your product: the agent signup API walks a person through creating their business and comes out holding a credential to it. Two steps stay theirs, confirming the email and adding a card. Or they describe their business at latticekit.app and connect your product from their console. Either way each customer is its own business from the first minute.
You do not build it. Every record belongs to exactly one business, the business is carried by the credential rather than by a parameter, and locations inside a business are a further scope enforced centrally. Getting a second business means getting a second credential. There is no cross-business query to get wrong.
Your vertical, your screens, your customer relationship and your price. Each business’s configuration exports as one portable document that can be compared with what is live, applied to another business, and rolled back. Ledger data exports as CSV. Card numbers never pass through LatticeKit at all; they live with the processor under each business’s own account.
One export per customer — CSV, JSON, XLSX, or a ZIP of all of it. The mapping is proposed for you, a dry run shows every row that would be created or rejected before anything is written, and old ids are remapped so files that refer to each other still do.
It is new, and we are welcoming businesses a few at a time. You will be talking to the people who build it, and the working copy Beth builds is the real thing, not a sample. Already running a SaaS and thinking of moving it? That page is here.
Describe it and see it running in a few minutes. No call, no card, and nothing to build until you decide it is worth it.