Every operator has lived this. A price changes in the spreadsheet, a unit turns over, a service area expands, a product gets retired. The real change happens inside your operation instantly. The website finds out days later, when someone remembers to log into the CMS and retype it. Between those two moments, your public site is lying to customers, and you are the one fielding the calls. The problem is not laziness. The problem is that your website and your operational data live in two different systems that only a human keystroke connects. Mulstra removes the keystroke.
The real problem is two copies of the truth
Most businesses run their operation in one place and their marketing site in another. The operation is where the actual records live: the units you manage, the jobs you dispatch, the products you sell, the availability you track. The website is a separate frozen snapshot that was accurate on the day someone published it.
Every drift you have ever chased traces back to this split. A single source of truth means there is exactly one record for each fact, and everything else reads from it. The moment you keep a second copy for "the website," you have signed up for a permanent reconciliation job that no one ever finishes.
When your website reads from the same records that run your business, "updating the site" stops being a task. It becomes a side effect of doing the work.
Your workspace is the database, and the site reads it live
In Mulstra you model your business as objects, fields, and records — the same structured data that powers your internal tools. A property manager keeps units and listings. A field-service firm keeps service areas, crews, and job types. An agency keeps a services catalog. That workspace is not a copy of anything. It is the operational system of record.
Your public site then reads from that workspace through a published API. There is no export step, no nightly sync, no CMS holding a second draft of the same information. When you edit a record, the site is already looking at the new value. This is what a live data website actually means: the page is a view over your database, not a photograph of it.
Because the data is structured rather than pasted into freeform content blocks, the site can render it properly — pricing tables, availability badges, filterable catalogs — and it stays correct because it never had its own copy to begin with.
You still decide what goes public
Reading live does not mean exposing everything. An operator's real fear is not staleness — it is a half-finished record or an internal-only field leaking onto the public site. Mulstra handles this with a workflow-controlled publish gate. Your data is the source of truth; a workflow decides which slice of it the public API is allowed to serve.
The flow is deliberate and repeatable:
Edit the record in your workspace, the same way you would for any internal update
A workflow evaluates the publish gate — status is
published, required fields are filled, the object is marked publicly readableThe published API exposes only what passed — draft, archived, and internal records never reach the public endpoint
The site renders the live value on the next request, with no redeploy and no manual step
You get both properties at once: the site is always current, and it only ever shows what you deliberately released. Change a price and publish — it is live. Pull a listing offline — it disappears from the public catalog the moment its status flips.
What this looks like in practice
Picture a property management workspace. Each unit is a record with rent, bedrooms, photos, and an availability status. Your public listings page reads that object through the published API. A tenant gives notice, you flip the unit to available, and the listing appears — no marketing handoff, no CMS re-entry, no "we'll update the site next week."
Or a field-service operation with a catalog of service areas and job types. You expand into a new zip code by adding one record. The coverage map and the services page both update, because both are views over the same object. There was never a second list to keep in step.
The pattern generalizes to any catalog: products, pricing tiers, team rosters, case studies, open roles. Anything you already maintain as operational data can become a public page that maintains itself. And because Mulstra fields support real structured content — not just short text — your marketing pages can carry the depth they need, which we covered in rich content, finally.
We build our own site this way
This is not a pattern we recommend and quietly avoid. Mulstra's own marketing site is built on Mulstra. Our solutions catalog, the pages describing what we do, the structured content behind them — they are records in a Mulstra workspace, served through the same published API and the same publish gate that your workspace uses.
When we ship a new solution, we add a record. The page exists. When we revise how we describe something, we edit the field, and the site reflects it. We feel the same feedback loop we are asking you to trust, which is the only honest way to build a product like this.
Stop maintaining two versions of the truth
The copy-paste website was always a workaround for a missing connection between your operation and your public presence. Close that gap and an entire category of work disappears: no reconciliation, no stale pages, no redeploy to change a price. Your workspace runs the business, the publish gate decides what is public, and the site simply reflects it — correct by construction, because there is only one copy of the truth and everyone is reading from it.