Security isn't a feature you bolt on. It's how the team works.

There is one line in almost every software proposal I read: "we'll handle security later". That "later" has a date and a price, and it is rarely the person who promised it who pays. Why security is a team habit, not a backlog item, and how to spot it before you sign.

Por Raquel Reis

Raquel Reis

I read software development proposals almost every week. Part of my job at Revin is to look at what a founder is about to sign before they sign it. And there is one line that shows up so often it has become a running joke on our side. It turns up in fintech, in healthtech, in marketplaces, regardless of the sector. Always somewhere in the middle of the document, in the calm tone of someone simply sorting priorities: "we'll handle security in a later phase".

A later phase sounds perfectly reasonable when you are racing to launch and the budget is tight. The trouble is that this "later" almost never becomes a real date on the calendar. It becomes an item that slides down the backlog every sprint, pushed aside by something that feels more urgent. And almost everything feels more urgent than security, right up until the day it doesn't.

This piece is for whoever is about to hire the people who build their software, and wants to know in advance whether security is something that team does or something it merely promises to do. Those are very different things, and the difference is visible before you sign.

Where security shows up, or doesn't: less in a contract clause, more in the lines the team writes every single day.

The "later" that never comes

Why is security always the easiest thing to postpone? Because it is invisible while it works. Nobody opens the app in the morning and thinks "great, my data didn't leak today". A new feature gets a demo, a screenshot in Slack, a round of applause from the board. Security done well shows up nowhere, until the day its absence becomes the only thing anyone can see.

Then there is the vendor incentive nobody mentions in the room. Whoever gets paid for visible output optimizes for visible output. A body shop billing by the screen has no reason to spend three days reviewing an access rule the client does not even know exists. It is not bad faith. It is the contract spelling out what matters, and security was not written into it.

I have seen exceptions, of course. The careful freelancer who does the right thing without being asked does exist. You just have no way of knowing which one you have got before you hire, and betting your customers' database on "maybe this one is a good one" tends to get expensive.

Where the gap shows, and it's never a movie hack

When a system leaks, the real story is almost never the one from the films. There is rarely a hooded hacker breaking encryption at three in the morning. What is there is a lot more boring than that.

Earlier this year Revin was brought in to review the code of a marketplace with around 20,000 active users. Lean team, built entirely by two freelancers in a hurry. Within half a day of reading we found the usual suspect: the payment API key written straight into the code, in plain text, in a commit from 2023. It was sitting in the Git history, visible to anyone who cloned the repo. Nobody had rotated it because nobody remembered it was there.

That kind of hole tends to live in four places:

• A secret in the code: API keys, database passwords and tokens committed in plain text.
• Access nobody revokes: the freelancer left eight months ago and his production credential is still alive.
• Permissions that are far too broad: everyone became an admin because setting up proper roles was a hassle at the time.
• A dependency frozen in time: a library with a known flaw for two years that nobody updated because it was working.

None of these needs an evil genius to exploit. It needs a curious intern, a resentful former contractor, or just a bad day. And they all share the same root: they appeared because nobody on the team was in the habit of looking.

Finding this early is half the battle. The Diagnostic Sprint grew out of roughly that: two weeks, code on the table, and an honest picture of what is exposed handed back to you while fixing it is still cheap.

Real security doesn't live in an annual report. It lives in the code review that happens before the merge.

Security is code review, not an audit

The difference between a team that has security and one that only promises it is not an expensive tool or a certificate framed on the wall. It is a habit, and that habit is visible in the working rhythm of whoever you hired.

On a senior squad, security is not a stage that happens at the end of the project. It is a lens that stays on the whole time. When someone opens a pull request, the reviewer does not only check whether the code works. They check whether the new endpoint verifies permissions, whether some sensitive field is being written to a log by accident, whether that query accepts a parameter it should not. Least privilege stops being a nice phrase in a policy doc and becomes the default way to create access: it starts closed and opens only as much as needed.

That is how it works on Revin's squads, and not out of any special virtue on our part. It is simply cheaper. Reviewing a permission inside the pull request costs ten minutes of whoever is on review duty. Discovering the wrong permission after it has already leaked costs you the client.

This is not the same as chasing SOC 2

A caveat here, because security as a habit keeps getting confused with security as paperwork. They are not the same thing. You don't need SOC 2 in year one, nor a pricey quarterly pentest, and you certainly don't need a CISO before you have product-market fit. Chasing compliance too early is usually money down the drain, something we argued in why a year-one startup shouldn't chase SOC 2.

A certificate is something you buy off the shelf. The habit comes from the team itself: either they already work this way, or they will learn it on your project, on your timeline, with your data. When it is already baked into how people write code, it costs very little.

So next time a proposal lands in your lap and your eyes catch that line, "we'll handle security later", be suspicious of the verb. The question that matters is not when it will get done, it is whether that team already does it by default. A team that treats security as a habit does not even write the sentence, because for them there is no later phase: it has been part of the work since the first commit. Whoever promises it for later is telling you, in plain words, that the habit is not there. You can hire them anyway, but at least you heard the warning.

In the end, security is less about what you buy and more about who you let into your code. If you want to see how an embedded squad handles this day to day, or to read about the other vectors that show up once AI enters the workflow, just book a call with us.