Frequently asked questions

Security reviews of AI-generated applications repeatedly note missing audit and verification layers — the code works, but nothing records what happened or lets you reconstruct it afterwards. An audit trail is invisible when everything is fine, so it is the first thing left out and the last thing anyone thinks to ask for. The financial record is append-only: entries are added, never edited away and never deleted, so the history of what happened cannot be quietly rewritten — by a person, a bug, or an assistant having a bad day. Records that leave your working views are retained rather than destroyed, so “undo” is a real question with a real answer.

Your organization’s own records and events — scoped to your org, used to answer your questions. It is a lens on your data, not a pipe out of it.

People apply to a named program, you approve the ones that fit, and each approved ambassador gets a role in your organization plus their own trackable code and link. They can see their own results and a leaderboard, and they are paid on revenue that actually cleared, with refunds reflected. Payout method and tax forms are collected when they opt in rather than chased later.

Yes. Each ambassador has a report for their own code and a leaderboard, plus a partner surface of their own to log into. Ambassadors who can see their numbers promote considerably more than ambassadors who have to ask you for them.

On money that actually cleared, with refunds accounted for rather than ignored. Because the referral engine and the sales records are the same system, the figure the ambassador sees and the figure you owe are the same figure.

Yes. Contacts, Pursuits (leads), Products, Orders, Payments, Reports, Workflows and runs, Events and webhooks are all reachable through a machine-authenticated API using named scopes. Access is least-privilege by default: a token that requests no scope receives nothing rather than everything, tokens can narrow themselves but never widen, and there is deliberately no admin or wildcard scope.

No. Fields are never removed, renamed, or retyped; the surface evolves by adding beside what exists. Identifiers are opaque and responses are deliberately shaped rather than database rows, so internal change does not reach your code. Events are versioned by name, so a subscriber never receives a payload shape it was not written for.

Yes. A plain-text map for language models is published at /llms.txt and the full capability catalog as JSON at /features.json, so an assistant can discover what the platform does and how to reach it without a support ticket or a sales call.

Yes. Attribution is included rather than a separate subscription: a first-party tracking tag for your own site, connected ad accounts, a return-on-spend board by channel and campaign, journey reconstruction for any individual customer, call tracking numbers, and campaign results credited against revenue actually collected.

An ad platform reports the conversions it believes it caused, and each platform grades its own homework — which is why their numbers add up to more sales than you made. Here, attribution is credited against the same financial record your accountant would use, so a campaign gets credit for money that was genuinely collected.

Backend-as-a-Service means a provider runs the server side of your application — database, authentication, storage, APIs — so your team only builds the front end. The usual trade is that you get primitives: auth, a data store you design yourself, file storage and serverless functions. Every business concept on top of them — what a customer is, what a quote is, how a refund touches your books — is still yours to build and maintain.

Those give you excellent primitives and an empty database. This gives you the business domain already built: customers, quotes, orders, payments through your own Stripe, scheduling, messaging, documents, permissions shaped like your org chart, and double-entry books. The difference is where you start — with a data store you must design, or with the objects a business actually runs on. For a game or a developer tool, primitives are the right answer. For a business operation, most of what you would build on them already exists here.

Yes, and it is the core design constraint. Every file declares its owner: framework files are content-hash-locked, and your brand, words, pages, and components live in separate lanes upgrades never touch. Utah’s Events runs 50 files of custom work — its own homepage, components, and CSS — has merged 13 upstream releases, and still reports zero framework files edited.

Run npm run upgrade:check. It reports how many framework files exist, how many you edited, and how many are missing — for example “166 core files, 0 edited, 0 missing”. It also runs inside the standard verify command, so drift is caught before it reaches your repository.

Restore it with git checkout template/main -- <path> and re-apply your change in a customization lane. Your content and pages are untouched by that restore, because they live in different files — so recovering costs you nothing but the edit itself.

Yes. Bookings, published open slots, field jobs, events, tasks, follow-ups, blocked busy time and available time all render on the same calendar, with day, week, month and whole-team views. In most software stacks those live in four separate products that cannot see each other, which is why the schedule is never right in any of them.

Yes — connected calendars sync both ways. What is booked in the platform appears in their calendar, and what they accept in their calendar blocks the time here so it is never offered to a customer. Nobody has to abandon a calendar that already works for them.

You publish bookable times, and those are generated from what is genuinely free — after your availability rules, your blocked time, and anything synced from your own calendar. The booking page cannot offer an hour the schedule does not actually have.

The booking is the beginning of a customer relationship rather than a calendar entry: the person becomes a contact with history, the deposit becomes an order on real books, the reminder comes from your own number, and everything after — quotes, delivery, documents, a portal — lives in the same place.

Yes. Public booking is zero-login by design, and customers manage or reschedule through a secure link in their confirmation.

Yes — it lives on your site at /m/your-slug with your branding, configured live from the dashboard.

Passwordless magic links by email — secure, and no password resets for anyone.

Keep the pages, styling and flow the tool generated and replace the generated data layer. Get a narrowly-scoped token, point one low-logic screen at real data first to surface the shape assumptions cheaply, then delete the generated data layer in a single deliberate step rather than gradually. Finish by subscribing to events instead of polling.

No. Auth is the piece most likely to be quietly wrong in generated code and the piece you least want to debug later — missing access rules on generated tables are behind a documented CVE affecting hundreds of AI-built apps. Replace it in the first sitting, before other screens depend on its assumptions.

No. Sites built on this platform are pre-wired: every public form writes to the backend with source attribution. A front end built elsewhere (Lovable, v0, Bolt) connects through the same public API.

Yes — rename, reorder, add, and retire stages from the dashboard, with open deals safely moved when a stage retires. Saved views track stages by ID, so renames never break reports.

Yes. The operator app is code in your own repository — the same kind of front end as your public site, calling the same API. You can restyle it, add screens to it, and build reports and internal tools we never imagined, without asking anyone.

Not if you add your own screens beside ours, which is the supported path — those are never overwritten and every upstream release still merges cleanly. Editing a screen we maintain is the case that costs you: our next improvement to that file then collides with your change. A checker reports how many framework files have been edited and names them, so you always know where you stand rather than finding out at upgrade time.

Yes, and this is the most common reason to touch the admin at all. A report is a page in your repository using the shipped components and the same data your other screens read. You own it, you support it, and it survives every upgrade because it is yours rather than a modified copy of ours.

A CSV of contacts is not the same as your books, your documents and your website. Ask for the specific list, not "of course you can export".

If payments settle into the vendor’s account and are paid on to you, then a dispute, an outage, or their bad quarter is your cash-flow problem.

A page builder inside a subscription is rented. Source code in your own repository is owned. The difference only becomes visible on the day you want to leave.

Yes — public event registration is zero-login. Attendees can later claim their history with a magic link, which turns them into portal members.

Both — free registration or paid tickets through your own Stripe, with capacity and waitlists either way.

Yes — the board is just your own week. It matters more as you add crews: assignment, notifications, and per-job economics scale without new tools.

Customers get confirmations and reminders via SMS/email automatically; the member portal can expose order status when you enable it.

The client does. Their payments settle directly into their own processor account, so the agency is never in the flow of funds, and their business data belongs to their organization and exports on demand. The front-end code sits in a repository under an MIT licence.

Sign-up and sessions, roles and permissions, taking payments and the books behind them, a real customer record, scheduling that cannot double-sell a slot, transactional email and SMS from the client’s brand, a customer-facing logged-in area, and the admin screens the client runs the business in. What remains is the front end — the part clients judge and pay for.

Yes. Each client is its own organization with separate data, brand and members, and you switch between them with one login, with roll-up views across the whole family. The stack white-labels, so your clients experience your brand rather than ours. Each client’s payments settle into their own processor account, so the agency is never in the flow of funds.

Sign-up and sessions, roles and permissions, taking payments and the books behind them, a real customer record, scheduling that cannot double-sell a slot, transactional email and SMS from the client’s brand, a customer-facing logged-in area, and the admin screens the client runs the business in. What remains is the front end — the part clients judge and pay for.

Less than with most vendors, by design rather than by promise. Your website is MIT-licensed code in a repository you own, so it keeps running and any developer can maintain it. Your payments already settle directly into your own Stripe account, so revenue never depended on us being alive. Your customer data belongs to your organization and exports on demand. What you would lose is the managed backend and future releases — a real loss, but a survivable one rather than a business-ending one. Ask any other vendor the same question and compare the answer.

Nothing extra for people. Seats are free and never gate access, so adding a team member — including the part-timer, the bookkeeper, or the crew member who only needs their own schedule — does not change your bill. You pay for what genuinely costs money to run: storage, AI usage and heavy processing. Credit is bought up front rather than invoiced, so there is no bill chasing you and no surprise at month end. Payment processing goes through your own Stripe account, so we never take a percentage of your revenue either.

No. Contact forms, lead-qualifying quizzes, recommendation flows, customer surveys, NPS runs and intake questionnaires are all the same engine with different settings. That means a contact form can branch and score like a survey can, and every answer lands on the customer record instead of in a separate form tool you then have to reconcile.

Yes. Questions can be grouped and connected so a run follows the path the answers open, and nobody is asked questions that do not apply to them. Answers can also be scored, so the same run can recommend something to the visitor and qualify them for your team at once.

Yes. Build an audience, invite them, see exactly who has not responded, and remind only those people. You can also publish the same questionnaire as a public link that works with no login. Response rate is mostly a chasing problem, and the chasing is built in rather than left to you.

A complete working site with marketing pages, a blog, FAQ, contact, a member portal and a full operator dashboard — deliberately plain, with neutral typography and generic placeholder copy. It is designed to be a starting point rather than somebody else’s design you have to undo first.

Yes. Three live examples share no page design: an event company with a cinematic near-full-screen homepage, its own typography and its own stylesheet; a holiday-lighting installer in a dark, warm-gold night register; and a dense technical platform site with a live animated hero and around ninety generated pages. None edited a framework file and all still merge every upstream release.

A branded site can be deployed the same day: clone the template, set your name and colors, add your API origin, and push to Vercel. Connecting the backend is a single environment variable, and the demo mode lets you tour the entire product with sample data before you connect anything at all.

Yes. Demo mode renders the whole application — dashboard, CRM, orders, member portal — with believable sample data, no login and no backend required. There is also a one-command mock stack if you want a real HTTP round-trip while you build.

A GitHub account, a Vercel account (both free tiers work), and your own Stripe account when you are ready to take money. Everything else — the database, auth, the API — is provided.

This site adds 44 new files and edits 5 template files, all of them content and config lanes, for a difference of about 6,500 lines — and touches 0 framework files. Its upgrade check reports 167 core files, 0 edited, 0 missing. The limit is not how MUCH you change; it is WHERE. Customization lives in lanes that upstream releases never write to, so the amount is effectively unbounded.

A checker that ships with every clone tells you. Core files are content-hash locked, so `upgrade:check` reports exactly which ones drifted and the fix is to move the change into a lane and restore the file — your content lanes are untouched by that, so you never lose your words re-taking a base file.

For small and growing businesses, yes — you get customer records, pipeline, marketing, automation and reporting, plus the website, booking, payments, events and portal that a CRM expects you to buy separately. For a large enterprise sales organization with a customized process and staff to run it, a dedicated CRM platform is still the safer answer.

Adding staff does not change your bill, because seats are free. What you pay scales with what you actually consume — storage, AI usage and heavy processing — which also means a slow season costs less without you having to cancel anything or strip people of their logins. That is usually the largest difference in total cost over time.

It covers the same operational ground — customers, quotes, scheduling, dispatch, invoicing and payments — and adds the things field-service software usually assumes you bought elsewhere: your public website, zero-login online booking, email and SMS marketing, forms and surveys, a customer portal, document sharing, events and marketing attribution. Whether it is the right swap depends on how much of that you are currently paying for separately.

No. You can keep your website and connect it to the backend, replace it with our template, or generate a new one with an AI builder and point it at the same platform. The website and the business system are the same system here, but the front end is yours to choose.

We bill per organization rather than per user, so team growth does not increase the bill, and payment processing goes through your own Stripe account so we take no percentage of your revenue. Compare that shape against what you pay today across every tool in your stack, not just the field-service one.

Either — courses are enrollable per person, so a private staff track and a public customer academy coexist.

With live scenes drawn from a vocabulary of primitive shapes — light, structure, people, motion and objects — composed into an animated tile. Nothing is a photo or a video file, so nothing looks like the same stock image every competitor bought, and the whole scene is a small piece of structured data rather than a media asset.

Yes. Because a scene is described as data rather than drawn, an assistant can author a new one from a sentence describing the feeling you want. The repository ships the shape vocabulary, the composition rules and the cost limits an assistant needs to produce one that passes the same checks as the built-in scenes.

Each scene has a cost ceiling that is checked rather than assumed, and motion stops for visitors whose devices request reduced motion. A scene is a small piece of data, not a video download.

No. The database, services and API are managed for you — running, backed up, patched, monitored and kept secure, along with authentication, permissions, payment plumbing and real double-entry books. Your job is the brand, the design and the customer experience. There are no servers for you to run and no database for you to administer.

Yes. Custom services can be commissioned when your business needs something that does not exist yet. Where the capability turns out to be broadly useful it can be folded into the base, so what you commissioned keeps being maintained and improved in every future release rather than rotting as a one-off nobody dares touch.

Any custom front-end code you write is yours to maintain, though the framework beneath it stays upgradeable. The accounts you connect — your payment processor, your domain, your sending identity — remain your relationships. And what data you choose to collect, and how you honour consent, is a decision only your business can make.

Sweepstakes pages ship with a rules framework — sponsor, eligibility, dates, disclosures — configurable per giveaway from the dashboard.

Optional. Paste a GA4/GTM/Meta ID in the dashboard and it goes live consent-gated in minutes — but first-party attribution works without any third-party pixel.

Yours — your sending domain for email, your number for SMS. The platform is invisible to your customers.

Failures are recorded on the message and surfaced — including to the built-in coach, which watches for delivery problems and tells you.

Yours. You connect your own Stripe and payouts settle directly to your account. The platform never holds, routes, or takes a cut of your customer payments.

You do. The template is MIT-licensed and lives in your repository. Your customer data belongs to your organization and is exportable to CSV across the major lists, with the ledger export-ready for your accountant. There is no lock-in clause and no hostage data.

Yes — a double-entry ledger. Every charge, refund, and commission posts balanced journal entries with a gapless audit trail and monthly periods, and a completeness check proves every order event actually posted. It is bookkeeping, not a payments log.

Yes — that is the point of the platform: they bring any front end (Lovable, v0, Bolt, hand-built) and connect it to their organization’s backend. See /build for the copy-paste prompts.

Yours. You connect your own Stripe; payouts settle directly to you. The platform never holds or routes your money.

Yes — a double-entry ledger with balanced journal entries, monthly periods, and a completeness check that proves every order event posted. CSV export for your accountant.

Yes, and that is the main reason to run them in one system. When a referral program and an ad platform cannot see each other, a customer who was referred and also clicked an ad is claimed by both — so you either pay a commission on a sale advertising produced, or underpay an advocate who earned it. Here both resolve against the same collected revenue, so there is one answer rather than two competing ones.

Personal codes and shareable links per advocate, claimable vanity codes reviewed by a person before going live, a leaderboard, time-boxed promotions, commissions calculated on money that actually cleared with refunds accounted for, and revenue-share opt-in including payout method and tax forms.

Always — CSV export ships across the major lists, and the ledger is export-ready for your accountant. Your data is yours.

Move a team and its access moves with it. Reorganizing does not mean re-ticking permission boxes across every person, which is where mistakes normally creep in unnoticed.

Yes. Any role can be renamed to your own vocabulary — techs, stylists, crew, reps, coordinators — so the software speaks the way your company already does.

Yes. Role and assignment changes are recorded, so "who could see this, and since when?" has an answer rather than becoming a conversation.

Yes. Point the site at your organization and both the blog and FAQ serve live from the dashboard CMS — publish a post and the site picks it up within minutes with no deploy and no rebuild. Until you switch that on, the same content lives in editable files that ship with the template.

Yes — public booking is zero-login by design. Customers see live availability, book a slot, and manage or reschedule through a secure link in their confirmation. Availability rules, buffers, deposits, and waitlists are all enforced server-side, and any booking page can be embedded on a site built elsewhere.

Yes — your own sending domain and phone number, so your customers never see ours. Confirmations, reminders, receipts, and campaigns send automatically, and every message is logged on the customer record with delivery tracking.

Yes — booking is zero-login by design. Customers manage their booking through a secure tokened link in their confirmation.

Yes — every booking page has an embeddable iframe snippet, so a site built in any tool can take real bookings.

Your clone has not edited any framework file. Those files are content-hash-locked, so an upstream release can replace them cleanly. Your brand, words, pages, and components live in separate lane files that upgrades never touch.

Run `npm run upgrade:check`. It prints how many core files exist, how many you edited, and how many are missing — for example “166 core files, 0 edited, 0 missing”. Any non-zero edited count names the exact files.

No. Restore the framework file with `git checkout template/main -- <path>` and move your change into a lane. Your content lanes are untouched by that restore, so you never lose your words or your pages re-taking our base files.

A daily dashboard, an AI business coach, contacts with full customer history, a named-stage lead pipeline, real double-entry books, quotes and invoices paid through your own Stripe, a dispatch board with mobile job cards, events and ticketing, and marketing with attribution. It ships with the website rather than being a separate purchase.

Included. The dashboard your team works in every day ships with the site. Most website projects budget for the public pages and discover the business software they actually needed about six weeks later.

Yes, with a different shape. You get the customer records, pipeline, marketing and reporting a CRM gives you — plus the things a CRM assumes you bought elsewhere: your public website, online booking, payments through your own Stripe, events and ticketing, a member portal, document storage and delivery management. It is one platform rather than a CRM at the centre of five integrations.

Nothing. Seats are free, and adding a team member never changes what you pay — so you can give a login to the part-time person, the bookkeeper, or the crew member who only needs to see their own schedule. You pay for what actually costs money to run: storage, AI usage, and heavy processing. Credit is bought up front rather than invoiced, so there is no bill chasing you and no surprise at month end. The website template is MIT-licensed and free, and payments go through your own Stripe account, so we never take a percentage of your revenue.

BringTheFront is a production business backend you connect your own front end to. You build the website however you like — by hand, or generated with Lovable, v0, Bolt, Claude, or Cursor — and you inherit auth, a multi-tenant database, payments through your own Stripe, email and SMS, scheduling, events, a member portal, and automation. There is no backend to write, host, or maintain.

Yes — that is the intended path. AI builders produce excellent front ends and no backend. Point yours at the API and the pages start reading and writing real business data: customers, orders, bookings, payments. There are copy-paste prompts for Lovable, v0, Bolt, Claude, Cursor, ChatGPT, and Gemini on the Build with AI page.

No. The MIT-licensed template is the fastest start and gives you a full site plus an operator dashboard on day one, but the backend is a normal HTTP API — any front end in any framework can call it. Use the template, fork it beyond recognition, or bring something entirely your own.

The run records the failure, retries where safe, and dead-letters loudly if it cannot proceed — the failure watchdog turns it into a coach observation so a human sees it.

Yes, at four levels. Configure brand, modules, terminology, themes, views and filters from settings. Compose new or restyled pages with an AI assistant using the published conventions. Replace the front end entirely — your own homepage, your own components, or a site generated with an AI builder pointed at the same backend. Or commission a custom interface from us when the thing you need does not exist yet.

No. Your customizations live in files that upstream releases never touch, and a single command tells you whether you are still on the upgrade path. A live business on the platform runs its own homepage, components and styling and has merged every release since launch with no framework files edited.

Yes. Custom interfaces can be commissioned on top of your platform, and where a capability is broadly useful it can be folded into the base so every future release carries it — meaning the thing you paid to have built keeps being maintained rather than rotting as a one-off.