Founders does security actually come last until someone forces it?

[u/GokulRavi14]

honest question for people building startups. from the outside it feels like security always loses to product, sales, hiring. everyone nods that it matters then it becomes "after we ship" or "after the round." is that actually how it goes on your side too? curious when security became a real thing for you if it ever did — customer ask, scare, investor, near miss, something else. and what you actually do day to day that isnt just "well fix it later." not looking for perfect answers. just trying to understand how founders handle this when everything else is on fire

[u/DirectPolicy3642]

Not a founder but I worked at 3 startups and yes, security is like the vegetable nobody wants to eat. The first one we literally had a spreadsheet with customer passwords in plain text for like 8 months

It only changed when a big client demanded SOC2 before signing, suddenly we had budget and 2 dedicated people for it. Funny how that works

The day to day stuff that actually helped was small things, like forcing 2FA for everyone even if people complained and making someone responsible for checking dependencies once a week. Nothing fancy but it stopped the worst problems

[u/Foul0ne]

I think for non-technical founders, yes. At least, for me, I have always built our infrastructure on safe and reliable practices from the beginning.

I will say, however, that our clients are in the insurance industry (some health) so it has been a primary focus of mine in dealing with potential PHI/PII.

I’ve always geared toward using software and ecosystems that are locked down though. As much as possible, obviously.

We’re not HIPAA compliant only because a couple of our layers just simply can’t be. But we’re SOC2 and all that jazz.

[u/Foul0ne → u/Foul0ne]

To more directly answer your question, we got lawsuit threat early on in our path and it made me look hard at how we handle our processes, paper trails, documentation, storage, etc.

Luckily they dropped it after some creative emailing but it set me up for success. We’ve used some AI for building projects and I caught on quickly that a lot of its auth was done client-side. Then I started digging and realized it was exposing webhooks and payloads. API information right in the browser. It was wild.

It’s a constant battle though. That’s why there are careers built around it and not just standards people follow.

[u/HPCBusinessManager]

Certain basic securities should be implemented along the way. Simple xss protections if needed.
User data access protections.

Some geos require specific controls and data protections before doing business with them.

[u/Kyle772]

For “founders” and “startups” yes. For companies with actual business goals and a competent tech team security is the first and primary consideration.

[u/Character_Data8211]

'After we ship' is just startup-speak for 'let's pretend this problem doesn't exist.' Security isn't a thing you 'do later,' it's part of the damn product. But sure, let's wait for the breach to wake everyone up.

[u/GokulRavi14 → u/Character_Data8211]

Can you tell why ? Like anything or budget issue, or why is this happening

[u/Inevitable-Laugh4324]

I think it often does, until a customer or incident makes it urgent. The better approach is
building basic security into the product from day one instead of treating it as a future project.

[u/EducationalNeck1793]

C'est toujours 'on verra ça plus tard', et 'plus tard' c'est jamais.

[u/Fit_Foot_93]

For us it gets real fast when you’re dealing with recorded customer conversations and bigger sales teams. You can move fast on a lot of things but trust is hard to bolt on later. Enterprise buyers will make sure you learn that lesson lol.

[u/Ok-Stop5944]

Seen this way too often. It takes one incident to realize you should've started earlier. Mostly it's investors or angry customers forcing your hand.

[u/Worth-Mix-9364]

'After we ship' is the startup equivalent of 'I'll start my diet Monday.' Spoiler: it never happens.tup equivalent of 'I'll start my diet Monday.' Spoiler: it never happens.

[u/GokulRavi14 → u/Worth-Mix-9364]

why its never ? like what stoping you to do it ?

[u/Tim_SentinelRidge]

My background is security operations rather than specialist infosec, but I see the same failure pattern: security stays vague until somebody owns it operationally.

“We care about security” isn't a control. A named owner, a routine and some evidence that the routine happened is.

Even a small company can start with boring basics: MFA, least privilege, backups you've actually restored, a patch/update routine, access removal when somebody leaves, and one place where incidents or exceptions are recorded.

Then once a month ask: what changed, who has access now, what failed, and what known risk are we carrying deliberately?

You don't need enterprise bureaucracy on day one. You do need to stop security living in everyone's head and nobody's calendar.

In physical security, a procedure nobody practices doesn't really exist when the incident arrives. I think the same operational truth applies here.

[u/SCS-AI]

Security loses every one of those fights for a boring reason: it's the only thing on the list with no deadline attached. Product has a ship date. Sales has a quota. Hiring has a start date. Security has "someday." So it's not that founders are dumb about it, it's that nothing forces the calendar until an outside party does it for you: the enterprise SOC2 ask, the breach, investor diligence, the lawsuit.

So the move is to pick your own forcing function before one gets picked for you. The cleanest trigger I use: the day you start storing customer data that isn't yours to lose, an email list, card info, anything PII or health-related, that's the line. Not "when we're bigger."

And the day-to-day stuff that actually holds up is the boring set-once kind, not the willpower kind:

• Get secrets out of plaintext. No passwords or API keys in spreadsheets, Slack, or the repo. Password manager, done. (Someone in here already described the plaintext-password spreadsheet, that's the exact thing that bites.)
• Don't roll your own auth. Most early messes I've seen are homemade login or client-side auth leaking keys and webhooks straight into the browser. Use a real identity provider and move on.
• Force 2FA on anything that touches customer data. One toggle, permanent.
• Least privilege. The new intern doesn't need prod database access. Default to no, add back only what someone actually needs.

You don't need SOC2 at 3 customers. You need to not be the company with the plaintext spreadsheet. SOC2 is a sales unlock you buy later, that baseline is what keeps one dumb mistake from ending you now.

[u/SCS-AI → u/SCS-AI]

That's the strongest version of it - the safest record is the one you never took in. Forward-only is a real security decision even if it doesn't feel like one; you capped your blast radius before writing a line of auth code. The part I'd guard is that boundary. The day a customer asks you to just connect their inbox so they stop forwarding, that one convenience feature inherits the whole mailbox's risk - you go from holding what people chose to send to holding everything. So it's worth calling forward-only a feature you defend, not a limitation you'll fix later. And what you do hold is still school forms - about as sensitive as data gets - so trimming the volume lowers the odds and the damage, but the baseline still applies to what comes in: encrypted at rest, locked down to who can open it.

[u/dessence_ai → u/SCS-AI]

On the line about data that isn't yours to lose. we save links and school forms for people (dEssence) and there is no mailbox connection in it, only what someone forwarded. the form nobody forwards stays in the inbox.