I used to think compliance was something that happened to other people. Like, sure — banks and hospitals needed to worry about it. But I was building a SaaS tool for small businesses. Who was going to come after us? We were nobody. We had maybe 800 users and a Postgres database running on a single EC2 instance. Then one of our users emailed us asking why their account password appeared in a Slack message our support bot had sent them. I still cringe thinking about it. Somewhere in our logging setup, we were capturing raw form inputs — including passwords — and piping them into our internal Slack channel so the team could debug user issues faster. It had been running that way for probably four months before anyone noticed. Nobody’s data got stolen. No breach, no headlines, no lawyers. But that user — who was actually pretty chill about it — told us they were moving to a competitor “just to be safe.” And I understood completely. I would have done the same. That was the moment compliance stopped being an abstract concept for me and started being something I genuinely cared about
Why Most Dev Teams Get This Backwards
The standard approach in a lot of startups goes something like: build the thing, get users, raise money, then think about security and compliance when an enterprise customer asks for a SOC 2 report or when something breaks. I get it. When you’re trying to ship and survive, slowing down to think about audit trails feels like the opposite of what you should be doing. There’s always a more pressing thing. There’s always a feature that someone is waiting on. But here’s the problem with that logic — the longer you wait, the harder it gets. Security and compliance are much easier to design in from the beginning than to retrofit onto something that’s already in production with real users and real data. I’ve been on teams that tried to do the retrofit. It’s painful in a way that’s hard to describe. You’re essentially trying to change the plumbing while people are using the showers. Every decision from three years ago that seemed fine at the time becomes a liability you have to untangle carefully so you don’t break something live. Building it right from the start isn’t slower. It just feels slower because the payoff isn’t immediate.
The Trust Problem Is Quietly Getting Worse
Here’s something I’ve noticed that doesn’t get talked about enough — users have gotten genuinely more suspicious over the last few years, and honestly, they have good reason to be. People have been burned. They’ve had email addresses leaked. They’ve gotten phishing emails that referenced real orders they placed on sites they trusted. They’ve watched companies get caught doing things with their data that they never agreed to. And they’ve learned — slowly, sometimes painfully — that the fine print matters. So when someone lands on your product and decides whether to hand over their email address, their payment info, or any real details about their life — they’re making a trust calculation. Often in the first few seconds. Often unconsciously. The stuff that influences that calculation isn’t your privacy policy (nobody reads it). It’s things like: does this site use HTTPS? Does the login page feel professional? What happens when I try to delete my account — do they actually let me, or do I get stuck in a dark pattern loop? When I emailed support, did I get a real answer or an obvious template? None of that is compliance in the regulatory sense. But all of it is trust. And the two are more connected than most people realize.
What Compliance Actually Looks Like Day to Day
I want to get specific here because I think a lot of the content on this topic stays too abstract to be useful. Compliance isn’t one big thing. It’s dozens of small decisions made constantly at every level of a software team. It’s the backend developer who, when building a new feature that touches user emails, takes five extra minutes to ask: do we actually need to log this? Could we store just the hash instead of the full value? What happens to this data after 90 days? It’s the product manager who pushes back on a request to “just add the user’s location to every event we track” because nobody’s really thought through why we need it or what we’ll do with it. It’s the engineer reviewing a PR who notices a new API endpoint doesn’t have rate limiting on it and flags it before it ships — not because they were told to look for it, but because they’ve been around long enough to know that an unprotected endpoint is an invitation. It’s the engineering lead who insists that secrets go into the secrets manager and not into the repo, and holds the line on that even when someone is in a hurry and says “I’ll fix it later.” None of these moments are glamorous. None of them show up in the changelog. But they’re the actual substance of what a security-conscious team looks like in practice
The Part Where Culture Does More Than Process
You can document every policy in the world and still have a team that quietly ignores them under pressure. I’ve seen it. Good engineers, smart people, who would do the wrong thing when deadlines got tight because nobody had ever really explained why the rule existed — only that it did. Rules without context are things people follow when they think someone’s watching. Values with context are things people follow because they’ve actually internalized why it matters. The difference between those two things is enormous. One concrete thing that actually helps: talk about mistakes openly. Not to shame anyone, but because near-misses are incredibly valuable learning opportunities that most teams waste by brushing them under the rug. When someone catches something — even if they were the one who introduced it — that should be treated as a win. The alternative is a culture where people hide problems because they’re afraid of how they’ll be received. Another thing: make the right behavior the easy behavior. If your security tooling requires three extra steps and a Jira ticket to do the safe thing, people will find a workaround. Friction is the enemy of good security hygiene. Reduce it wherever you can.
Trust Takes Forever to Build and Almost No Time to Lose
I keep coming back to something a founder told me years ago: users will forgive you for a lot of things, but they won’t forgive you for making them feel stupid for trusting you. That framing has stuck with me. Because “making them feel stupid for trusting you” covers a lot of ground. It’s not just a breach. It’s selling their email to a list without making it clear you’d do that. It’s making it genuinely difficult to cancel or delete an account. It’s the dark pattern that tricks someone into opting into something they didn’t want. It’s the customer service response that makes them feel like a number rather than a person. Trust is built in tiny increments over a long time. Every interaction is either a small deposit or a small withdrawal. The account balance matters. Compliance matters because it creates the structural conditions for trust to be possible. But compliance alone doesn’t create trust — that requires actually caring about the people on the other side of your software, and letting that care show up in decisions at every level of the product
The Practical Stuff That Actually Moves the Needle
Since I don’t want to end on pure philosophy, here’s what I’ve found actually makes a difference on real teams:
Do dependency updates on a regular schedule, not when you get around to it.
Old packages are how a lot of real-world vulnerabilities sneak in. Make it a habit, not a reaction.
Log what you need, not everything.
The reflex to log every input “just in case” creates a liability. Be deliberate. Ask what you’ll actually use the data for.
Handle incidents transparently.
When something goes wrong — and it will — tell users what happened in plain language. The companies that come out of incidents with their reputation intact are almost always the ones who communicated clearly and quickly, not the ones who minimized
Build deletion and data export into your product early.
Retrofitting this is miserable. If you’re storing user data, the ability to remove it cleanly should be part of the original design.
Have someone on the team who genuinely likes thinking about security
Not a security team necessarily — most early teams can’t afford one. But someone who finds this stuff interesting, reads about it, and brings it up. That person is worth their weight in gold.
Compliance and trust aren’t obstacles to building software. They’re part of what it means to build software that’s actually worth using — and worth sticking with. The teams that figure that out early tend to build things that last. The ones that don’t… well. They usually learn eventually. Just the harder way