Your Data Has a Legal Shape. Find It in Week One.

One of the changes we shipped on a build this week was not a feature. It pulled a set of institution names off every page of the site. The content in that app came from an organization whose name was not ours to publish, so the name came out. Nobody requested it during discovery. It was not on any list of things the product should do. By any normal reading of a scope document it was invisible work, and it still had to happen before a single real user saw the thing.

Most founders have a mental slot for that kind of work. It is called legal review, and it sits near the end of a project, somewhere between writing a privacy policy and picking a launch date. That slot is the problem. By the time you get there, every decision legal review would have questioned is already sitting in a database.

Two questions decide more of your architecture than your feature list does

The first is who your users are, said specifically. Not "small business owners." Not "families." Specifically. Are any of them under thirteen. Are any of them patients. Are any of them students, or employees whose employer has rules about where their information is allowed to live. Those answers are not compliance footnotes. They are instructions about what your sign-up flow has to collect, who has to consent, how long you are allowed to keep anything, and what your own admin screen is permitted to show you.

Founders tend to assume this is a healthcare and banking problem. Usually it is not. The triggers are ordinary: one user group under eighteen, a content library somebody else owns, an employer with rules about staff information, a pile of scanned documents that was never meant to be public. You do not have to be in a regulated industry to have a rule that decides your schema.

There is a prospective build on our board where the users would include children. That single fact rewrites a surprising amount. Account creation stops being an email field and becomes a consent path that involves a second person. The admin console, which the founder pictured as a list of real people doing real things, may have to be a page of counts instead, because looking at identifiable individuals and looking at aggregate numbers are two different products with two different data models behind them. None of that is expensive if you know it before design starts. All of it is expensive after.

The second question is what is actually inside the material you are bringing with you. Almost every founder arrives with a pile: exported spreadsheets, a folder of PDFs, a database from the tool they are replacing, years of documents somebody once scanned. On one archive project, the first real task was not building search. It was confirming that the documents held nothing personal or protected before they could be indexed and made findable. That is an engineering dependency wearing a legal costume. You cannot build the search until you know what you are allowed to index.

A feature request and a legal question look identical on paper

This is why it goes unnoticed for so long. Both arrive as one sentence. "Admins should be able to see activity by account." "Users can search the full archive." "Let people share their profile publicly." Say them out loud on a call and they sound like scope. Say them again with the user question answered and half of them turn into decisions that have a right answer and a wrong one, where the wrong one is not a bug you patch later.

There is also the ownership question, which almost nobody raises early because it feels rude to ask. Which legal entity owns this product. Who signs. Who holds the license to content the founder did not create. We put that question on a recent deal and the honest answer was that the entity did not exist yet. That is a fine answer in week one. It is a bad answer in week ten, when the app is built, the domain is registered in somebody's personal name, and the accounts are scattered across three inboxes.

Found late, the fix is a migration, not a memo

When a compliance question lands at the end of a project, the repair is almost never a document. If you stored something you were not supposed to store, you are not writing a policy, you are running a migration and deleting data that something else probably depends on. If your permission model shows an admin more than it should, you are not flipping a toggle, you are rewriting queries that every screen sits on top of. If the content your whole product is built around carries a name you cannot use, you are not editing copy, you are hunting that name through pages, exports, title tags, and email templates.

We have written before that scope is the product. This is the same idea from another direction. A regulatory constraint is scope, and it is the most rigid kind you will ever carry, because unlike a feature, it does not negotiate. So it belongs in the conversation where you decide what the first version does, not in a review held after that conversation is over.

What to ask in week one

You are not hiring a lawyer in week one. You are working out which questions need one, and that list is usually short. Four of them do most of the work.

1. Who are your users, specifically, and is any group of them protected (minors, patients, students, anyone whose information carries its own rules).
2. What is inside the material we are migrating, and who has read it recently enough to say so with confidence.
3. Which entity owns this product, and does that entity exist today.
4. What is the admin allowed to see: individual people, or numbers about them.

The objection we hear is that this sounds like front-loading that turns a six-week build into a four-month one. It does not, because the goal in week one is not to answer these questions. It is to find out which ones are live. Three of the four usually get settled in the call where they are asked. The one that does not is the one that would have detonated in week nine.

If a development partner never asks you any of this, that tells you something. Not that they are careless, necessarily, but that they are treating your product as a set of screens rather than a system that holds real information about real people. The screens are the easy part. What you are allowed to put behind them is the shape of the actual product.