A founder asked me recently whether she should put anything about security in the contract before hiring a freelance developer to build her app. Her instinct was that it might come across as distrustful, like she was accusing someone of being careless before they'd even started. I think it's closer to the opposite: leaving it out is what actually creates the problem, because it quietly assumes an agreement that was never actually made.
Why silence here isn't neutral
When a contract is detailed about scope, deadlines, and payment but silent on security, both sides tend to walk away with different assumptions. The founder often assumes 'obviously the developer will make sure it's secure, that's part of building it properly.' The developer often assumes 'I'll build what's in the spec, and security wasn't called out as part of the spec.' Neither assumption is unreasonable on its own. Together, they leave a real gap that nobody agreed to, and nobody notices until something goes wrong inside it.
What's actually worth putting in writing
- A plain statement of what 'done' includes: does the deliverable include a basic security pass (access control, key handling, database rules), or is that a separate, billable item? Either answer is fine. The point is picking one on purpose.
- Who owns testing for the specific class of bug that lets one user see another's data. This is the single most common gap in AI-built apps, and it's worth naming by name rather than assuming it's covered by 'general testing.'
- What happens to access and credentials at the end of the engagement. Who gets removed from what, and when, is worth stating up front rather than figuring out reactively during a rushed handoff.
- Whether an independent review is expected before launch, and who's responsible for arranging it if so.
Why this protects the developer too
This isn't only about protecting the founder. A developer who's been clear in writing about what was and wasn't in scope has a real answer if something goes wrong later and a client assumes security was always part of the deal. Ambiguity is a bad deal for everyone in the relationship, not just the person paying. Clear scope is the thing that actually lets a good developer point at what they delivered and say, correctly, that it matched what was agreed.
How to actually raise it without it feeling like an accusation
Frame it as a scoping question, because that's what it actually is: 'I want to make sure we're both clear on whether a security pass is included in this build or something we add separately. What's your usual approach?' That's a completely normal question to ask any professional about any deliverable. A developer who reacts well to that question is telling you something good. One who reacts defensively is telling you something too.
None of this needs to be adversarial or heavily lawyered. It just needs to exist somewhere both people can point back to, so that 'I assumed you'd handle that' never gets discovered for the first time after real user data is already involved.