Client website data ownership is a question of where the records live.
Do your records live in your database or someone else’s?
Not who can see the data. Who holds it.
Client website data ownership sounds like a privacy question. It is a plumbing question. When a visitor fills in the enquiry form on a client’s site, that submission lands somewhere. The Data test asks where, and whether the client can take it with them in a format they can read without asking anyone.
A record you can view in a dashboard but not export in full is a record someone else holds. A record you can export only as a picture of a table is the same. The test passes when the data sits in storage you can point at, query, back up and delete, on an account that is yours or the client’s.
This letter is the honest soft spot of any static stack, and this page does not step around it. Static pages have no database. That is a strength for most of the site and a gap exactly where the form is, so the form is where the test gets decided.
The export that omits the part you needed.
Check it on the platform your clients are on now. Open the form submissions for one site and export them. Then open what you got. Look for the fields the form had and the export does not. Look for the attachments. Look for the timestamps, and whether they are the visitor’s or the platform’s. Look for what happens to the record if the site is deleted.
Then do the same for anything else the site collects: newsletter signups, bookings, comments. Each is a store of records with an owner, and the owner is whoever can produce the complete file without a support ticket. Three platforms have already been read this way, help centre in hand: what a Wix export carries and what it does not, what a Squarespace form block exports, and why a Webflow CSV points at images that die with the site.
The quiet failure is the one where the site is static, built well, on hosting you chose, and the contact form posts to a third party’s endpoint on a free plan. Everything on the page is yours. The one thing a visitor actually gave you is in someone else’s inbox, under someone else’s terms. A commenter will notice, and they will be right.
The full export
Export one site’s submissions and compare the columns with the form. Missing fields, missing files and missing dates are the test result.
The endpoint
Read the form’s action attribute in the page source. If the domain is not yours or the client’s, the records are not either.
The deletion
Ask what happens to submissions if the site or the plan is cancelled. A retention window is an answer. A shrug is also an answer.
Everything on the page is yours. The one thing a visitor gave you is not.
An endpoint you own, and a store you can point at.
The playbook closes the gap the only honest way: the form posts to a route on your own host, and that route writes to storage on your own account. This site does exactly that. The email form at the bottom of this page posts to a route this site owns, on the same origin, and the record lands in a key-value store bound to this site’s account. No form service, no embed, no third-party inbox. Open the network panel and submit: the request goes to this domain and nowhere else.
That is the whole answer for a content or marketing site, which is what the playbook is scoped to. The records a client site collects are enquiries, signups and the occasional file. A key-value store you own, with a route you wrote in front of it, holds all of that and hands it over in full. The stack covers the hosting and the route.
What this is not is a database for a store or a login system. Those are different systems with different tests, and the Scalability page says where the line is.
The form is where Data is decided. Post it to yourself.
Data is the letter you have to earn. Extensibility comes with the stack.
Ownership
Not just “can you leave,” but can someone change the deal while you stay?
Extensibility
Add what isn’t there yet, without waiting on a roadmap.
The full test runs all five, with the assembling word and the rule: pass all five, or don’t build on it.
Read the sharpest chapter first. It costs an email.
We’ll send the build-gate chapter in full: the checks, the code, and the reasoning. Read it. If it doesn’t change how you think about shipping client sites, you’ve lost ten minutes and kept a working release gate.
That did not send. Check the address and try again.