Validating an idea does not secure your data. If security feels boring, wait for the first night an account that is not yours is open and you do not know who has the keys. At Snowinch it is a pillar of live, even when eyes glaze over on the call.
The typical conversation is: "we ship first, then we fix access and backups". It sounds agile. It is how you send a toy out with real people's records.
What belongs in scope (before it is "later")
You do not need a movie. A service token in the repo is enough, a staging environment that got indexed, an admin given "just to test", an export in a shared folder. Those are the ways "we validated" becomes "they walked away with it".
In scope, on live, sit boring things. Who can get in, and how you take them out. Where the copies are, and who reads them. What lands in the logs (passwords, tokens, health data pasted by mistake). What happens when someone asks to be deleted. What happens when someone on the team leaves with a laptop.
None of this sells. None of it shows on the landing page. It is still what the business stands on, if the business is other people's data.
Validation is not enough for this reason. The hypothesis can hold and you can still fail to sleep. The interview does not touch who has the keys.
I would rather slip a launch and close access, backups, and deletion than ship the test. The cost is visible: you look slower than the founder who just demoed. I take that. The alternative is explaining that the data left an environment that "was only for validation".
What is not phase two: real authentication (not a magic link dropped in a group chat), roles that are not all admin, copies you have restored at least once, a way to revoke access without asking whoever built the toy. If one of these is missing and you already have strangers as users, you are not in an intermediate step. You are exposed.
A specific aside: I opened an "example" .env that was the staging env, with a real key, committed so "the colleague can start". The colleague started. So could anyone else, in theory. It was not an attack. It was hurry.
Trade-offs I take (and which I do not)
There is a real trade-off. You can ship thinner, with less ceremony, if the data scope is thin: a waitlist, no payments, no heavy records, and you both say so. A sign can live with less. A product with cards and documents cannot.
What I do not take: "zero problems", "they will not get in", "the vendor covers us". We do not sign zero. We do not have a benchmark to hang on the wall. We can tell you what is closed, what is accepted in writing, and who answers. The rest is fear marketing or reassurance marketing. Both are the wrong call.
The other trade-off is time. Closing it properly delays the slide. Opening it badly brings the night forward. I stay with the first. If you need the second for a pitch deadline, find someone who says yes.
There is a case where "later" is honest: there is no one else's data yet, and the prototype does not ask for it. Then live security is not that week's job. The job is not pretending the prototype is production. We wrote that on the MVP that is not in production.
What this page is not
It is not an audit. It is not an ISO list. It does not tell you how to configure a vendor. It does not promise that nothing will happen. If someone promises you zero breach, they are selling sleep in a bottle.
On services security sits inside the live perimeter, not in a side offer you unlock after the wow. If the scope is "we ship, then we look at the data", we say no.
If you already have a signal and you need something that holds other people's accounts, the conversation is concrete: what is in, what stays out, who answers. That happens on contact.
