Scheduling, memberships, checkout, payments, a real ledger, messaging, staff, reporting and automation — already built, configured by describing what you need. Rebuild your screens here without code, or keep your front end and wire it to one API. Either way, your customers come over as they are.
See it before you integrate. Describe one of your customers’ businesses to Beth, our AI assistant, and she builds a working copy you can book into, at its own address, for a week. No card.
Describe one customer’s business to Beth in plain words — what they book, what they sell, who works there, when. She builds a working copy at its own address: their schedule, catalog, prices, people and hours, running. Book yourself in and watch it land before you write a line.
Two ways, and both keep your product. Rebuild it here: the page builder drafts a screen from a description, shows it with that business’s real data as you adjust it, and publishes it — no code, no developers. Or keep your front end and wire it to one API with a published spec, written for coding agents as much as for people. The roadmap after either is configuration, not code.
Upload each customer’s export — CSV, JSON, XLSX or a whole ZIP. The mapping is proposed for you, a dry run shows exactly what would be created before anything is saved, and files that refer to each other are stitched back together. Every feature you have not built yet is now a setting.
Nothing here forces a look on your customers. What changes is what your screens are talking to.
One API, one credential per business, every call audited. Switch the surface above — nothing down here changes.
Every part shares one customer record, one ledger and one event stream, 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 you set instead of a script you wrote.
Tabs and carts, tips and splits, cards through Stripe or Finix under each customer’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: 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.
A customer asks for a waitlist. It is on the roadmap for next quarter.
It is a setting. Beth turns it on for that business today, and the seat fills itself the moment someone cancels — text included.
They open a second location, and now every screen needs a location filter.
Locations are a scope the platform enforces on every read and write. Your screens do not change; the credential does.
They want to plug their own AI assistant into their business.
Connect it over MCP. A grant says what it may read and what it may propose; anything consequential parks for a person; every call is audited. You build none of that.
Beth is the assistant inside LatticeKit. She sets a business up from a description, changes it when asked, drafts screens in the page builder, and finishes the setup with whoever is doing it — you, or your customer if they use our console. If you keep your own front end, your coding agent reads the same documentation the platform serves to connected agents, starting at llms.txt.
Beth sets a business up. The next piece lets each business define its own assistants — as many as it wants — and put them in front of its staff and its customers.
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. Author “location manager”, “shift lead” and “customer” once, and every location of every customer gets all three.
The one invariant. A toolset reaching past what that kind of person could do themselves is refused when it is saved, and checked again on every turn — so a permission you narrow later narrows the assistant, with nothing to re-audit. A member’s assistant reads that member’s own records because the platform scopes the read to the proven session, not to an id the model wrote.
Knowledge is something it searches, not something stuffed into a prompt: entries you write, plus the business’s own published pages read exactly as a visitor sees them. A page behind a sign-in is filed staff-only and never answers a customer. It is told to search first, answer from what it found, name the source, and say when it found nothing.
Any workflow a business has built can be exposed as a tool with a name, a description and a declared input. The assistant calls it like any other tool — validated before a run exists, confirmed by a person where it matters, and traced from the run back to the conversation that asked for it.
The same definition answers a customer instantly in the message thread they already use — stepping aside the moment a human replies, until the desk hands it back — or sits as a chat component on a published page, or opens as a staff thread in the console.
Turns, tool calls and tokens 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 every turn is metered on the same page as the rest of the usage.
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 travelling in the business document. Not on production yet. The spec is on the Ellis page.
CSV, JSON and XLSX are read directly; a ZIP is opened so a whole legacy export becomes one upload. The mapping is proposed from the column headers, a dry run validates every row with nothing written, and where file two refers to file one — customers, then their bookings — the old ids are remapped onto the new records.
A business’s whole configuration — schedules, offers, resources, catalog, pricing, tiers, pages, workflows — is one portable document you can read before it runs. Ten working businesses ship as starters; begin a new customer from the closest one and change what differs.
Run the migration against a working copy first — the same one Beth builds from a description — and book, sell and message in it. Nothing sends, charges or reserves. Then do it for real with the same files.
If your customers’ data lives in your own database, you do not have to produce files at all. Point us at a read-only replica — PostgreSQL, MySQL or SQL Server — and we map your tables onto the platform’s model with you: customers and their contact preferences, staff, services with their real durations and prices, the appointment history, memberships, packages and balances.
It runs like every other import, because it is one: a dry run first that shows every row that would be created, changed or rejected before anything is written; ids remapped so records that point at each other still do; and a re-run that catches up whatever changed while you were testing, so the cutover is a re-run rather than a freeze. We set this up with you as part of onboarding — tell us what you are on when you get in touch.
No platform fee, no per-seat licence, no minimum. Each business you run on LatticeKit is billed each month for what it actually did — bookings made, sales rung up, messages sent. API calls are free, so a busy integration costs nothing extra. A quiet customer is a small bill.
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 booking 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 businesses you run.
No, and you get to choose how. Rebuild it here in the page builder — your layout, your palette, your pages, staff-facing screens included — without writing code. Or keep your front end, on your domain with your login, and wire it to the API. Either way it is on your domain.
If you rebuild your screens here, it means exactly that: the builder drafts a screen from a description, you adjust it on a canvas, you publish. No engineer in the loop. If you keep your own front end, wiring it to the API is integration work sized like any other, and the spec, the structured errors and the agent-oriented documentation mean a coding agent can do most of it. After either, the features you would have built — waitlists, memberships, retries, a second location, gift cards, staff scheduling — are configuration Beth makes from a description.
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. Imports go through the same validation as a single record, so bad data surfaces per row instead of landing quietly.
Yes — a read-only replica of your PostgreSQL, MySQL or SQL Server database, mapped onto the platform’s model with you. Same dry run, same per-row validation, same id remapping as a file import, and it can be re-run to catch up changes so the cutover is not a freeze. It is part of onboarding rather than a self-serve button: tell us what you run on and we will scope it with you.
That is the piece in build now. A business defines its own assistants — who may talk to each one, what it may do, how it speaks, where it appears — and an assistant can never do more than the person talking to it. It answers customers in their message thread or on the business’s own site, and staff in the console. Their tools are platform capabilities plus the business’s own automations. It is in review, not on production yet.
Every record belongs to exactly one business, and nothing crosses between them. The business is carried by the credential, never by a parameter, so a bug in your code cannot reach across. Getting a second business means getting a second credential. Locations inside a business are a further scope, enforced centrally.
Over MCP, behind a grant an operator consents to. The grant says what the assistant may read, the small set of routine actions it may take, and what it may only propose. Consequential actions park for a person to approve. It cannot reach anything a human operator could not, and every call is recorded.
Each business on LatticeKit has its own account, its own usage bill and its own card, with no platform fee and no per-seat licence. Your product can take a customer through creating one over the same agent API, though confirming the email and adding the card stay theirs. 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.
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.
Describe one of their businesses and see it running in a few minutes. No call, no card, and nothing to integrate until you decide it is worth it. Starting a SaaS rather than moving one? Start here.