A product with paying customers and one person behind it is not a smaller version of a company with a security team. It is a different shape. The revenue is real, the customer data is real, and the security decisions are real, but there is nobody to hand them to. They get made anyway, usually at the moment the code is written, by the person least able to step back from it.
This is not a warning about breaches. It is an observation about where the decisions actually happen in a one-person product, and which of them are worth someone senior looking at before they harden.
Not deciding is still deciding
Every product has an access-control model, a data-retention practice and a way of handling secrets, whether or not anyone wrote them down. The defaults are set by whatever shipped first.
The user table added in the first week becomes the tenancy model. The credential added to the deployment environment during a late release becomes the secret-management approach. The admin route protected by an unguessable path becomes the privileged access boundary. None of these were decisions in the sense of being weighed. They were the fastest thing that worked, and then the product grew around them.
That is a reasonable way to reach a working product. It becomes a problem later, because the cost of revisiting one of these choices rises with every feature built on top of it.
Where the cost usually appears
Four consequences come up repeatedly, and none of them involve an attacker.
Rework. An assumption about who can read which record is cheap to change across eight endpoints and expensive across two hundred. Access-control models in particular tend to spread, because every new feature inherits the pattern. By the time the problem is visible, the fix is a refactor rather than an edit.
A deal that stops moving. A larger customer sends a security questionnaire and asks for evidence of independent testing. The answers have to be true, and the gap is rarely the control itself. It is that nothing was written down, so a question that should take an hour takes three weeks and the contract waits.
Poor value from the eventual test. When a penetration test is finally commissioned, the budget goes on rediscovering the things the founder already suspected. A test is most useful when the known weaknesses have already been dealt with and the testers can spend their time on the paths nobody has considered. Scoping a test well is most of what determines its value.
Risk that only exists in one head. The founder usually knows the weak spots. If none of it is recorded, nobody else can plan around it: not the first engineering hire, not a technical due-diligence reviewer, not the person covering while the founder is away.
What is actually different about building alone
The risk is not larger than it would be in a small team. The constraints are different, in three specific ways.
There is no second reader. Every design passes review by the person who wrote it, which means the assumptions that feel obvious never get spoken aloud and therefore never get tested.
The context is unwritten. In a team, at least some reasoning surfaces in review comments and design discussions. Alone, it stays in one head, where it is neither challenged nor preserved.
There is no natural pause. Nothing in the workflow forces a decision to be examined before it ships. A team has friction that occasionally works as a checkpoint. A solo founder has to create that deliberately or go without it.
The decisions worth senior time
Not every security question deserves paid attention. The useful sorting rule is reversibility: how expensive is this to change once the product has grown around it?
The ones that are hard to reverse are worth an hour of someone else’s judgement before they set:
- how tenants are isolated, and how object ownership is checked
- how authentication and sessions work, including what happens on password reset and account recovery
- which personal data is collected, where it is stored and how long it is kept
- what the deployment credentials can reach, and who else holds them
- the release path itself, since it is the route by which everything else changes
Most other things can wait. Dependency updates, header configuration and logging improvements are real work, but they can be done later at roughly the same cost as doing them now. The list above cannot.
What advisory looks like at this size
For a one-person team, senior security input is a matter of hours rather than headcount. The work is narrow by design: a second technical reader on the decisions that are hard to undo, and a written record of what was decided and why.
What it is not is a transfer of ownership. The founder still owns the system, the decision and the trade-off. An advisor who takes over the decision has not helped, because the next one arrives in a fortnight and the founder is no better placed to make it. The useful output is a reviewed design and a short decision record, not a report that has to be interpreted by somebody else. Our use cases set out what that looks like across a range of situations, and the sample deliverables show the written form it takes.
The other thing worth saying plainly: at this size the honest answer is often that the decision is fine. That is a legitimate outcome, and it is cheaper to confirm it in an hour than to carry the doubt for another quarter.
Before you buy anything
Try a short test. Name the decisions in the next three months that would be expensive to reverse. Be specific: a change to how accounts are shared, a new integration that holds customer data, a move to a different deployment model.
If nothing comes to mind, the product is probably in a stable stretch and this can wait. If you name one, a single scoped review is likely to be enough. If you name three, and the same class of question keeps arriving, the pattern is no longer occasional and a small standing arrangement will cost less than reviewing each one from a standing start.
The test is not whether the product is secure. It is whether the decisions being made this quarter are the kind that get more expensive with time. Where they are, a second senior opinion is one of the cheaper things a solo founder can buy.