Retrofitting authentication and permissions into a live product is one of the most expensive jobs in software, because identity touches every endpoint, every query and every screen. The teams that suffer least made three decisions before their first customer signed up: where identity lives, how permissions are modelled, and where tenant boundaries are enforced. None of those decisions requires much code. All of them are brutal to reverse once real accounts and real data exist.
Identity and access management is the part of your system that answers two questions on every request: who is this, and what are they allowed to do? Authentication answers the first, authorisation the second. Conflating them is where most early codebases go wrong.
Access control is the bug you will actually ship
This is not a hypothetical risk. Broken access control sits at number one in the OWASP Top 10 for 2025, and every single application tested for the list showed some form of it, with over 1.8 million occurrences in the contributed data. The most common shape is mundane: an endpoint that checks whether a user is logged in but never checks whether the record they requested belongs to them.
Credentials are the other half of the story. The 2025 Verizon Data Breach Investigations Report found compromised credentials were the initial access vector in 22% of breaches, and credential stuffing made up a median 19% of all daily authentication attempts at the organisations studied. Verizon's related analysis puts stolen credentials in 32% of breaches overall, more than double any other vector. Your login page will be attacked with leaked passwords whether you have ten users or ten thousand.
Buy authentication, design authorisation
The pragmatic split for a small team is simple. Authentication is a solved commodity: password hashing, MFA, sessions, social login and token issuance via OAuth 2.0 and OpenID Connect all come from managed providers or mature open-source projects. Building this yourself buys risk, not differentiation.
Authorisation is the opposite. Nobody can buy you a permissions model, because it encodes your product's domain: what a workspace admin can do that a member cannot, whether billing is separate from ownership, who can invite whom. Sketch this as data early. A plain roles table with one permission check helper beats scattered ad hoc conditions, because you can migrate a model; you cannot easily migrate five hundred inline checks. It's the kind of foundational decision worth pressure-testing with experienced backend development hands before the schema hardens.
Why does password hygiene belong here? Because your users bring their habits with them.
Verizon's infostealer analysis found that for the median user, only 49% of passwords across services were distinct. Half of your customers' passwords already sit in someone else's breach dump, which is why rate limiting, breached-password checks and MFA are launch features, not hardening tasks for later.
Tenant isolation is a day-one schema decision
If you're building anything multi-tenant, decide where the boundary lives before the first table exists. Every tenant-owned row should carry a tenant identifier, and every query should be scoped by it, enforced in one place such as a repository layer or row-level security policies rather than by developer discipline. The OWASP Application Security Verification Standard is a useful checklist here, and far cheaper to satisfy at design time than during a customer's security review.
That matters commercially. Your first serious B2B customer will send a security questionnaire, and "we enforce tenant isolation at the database layer and centralise authorisation checks" is an answer that closes deals. Bolting it on after signing is how launches slip by a quarter.
FAQ
Should a startup build its own authentication?
No, in almost every case. Managed identity providers and mature open-source options cover passwords, MFA, sessions and OAuth flows for less than the cost of one engineer-week, and they absorb the security maintenance burden. Reserve custom effort for the authorisation model, which is unique to your product.
When is the right time to add roles and permissions?
Before your first external user, at least as a data model. You don't need a policy engine on day one, but you do need roles stored as data and a single helper through which every check flows, so the model can evolve without a rewrite.
What is the difference between authentication and authorisation?
Authentication verifies who someone is, via credentials, tokens or MFA. Authorisation decides what that identity may do, such as reading a record or changing billing. Most real-world access bugs are authorisation failures, not login failures.
Your pre-launch identity checklist
1. Pick a managed authentication provider and enable MFA and breached-password checks from day one.
2. Model roles and permissions as data, with one central check function that every endpoint calls.
3. Add a tenant identifier to every tenant-owned table and enforce scoping in one layer.
4. Rate limit login and password reset endpoints, and log every authorisation denial.
5. Write your permissions model down in one page, so security questionnaires answer themselves.
If you'd rather not learn these lessons on live customer data, BeyondPixl Studio runs identity and access design reviews as part of backend engagements. Book an architecture session and bring your current auth sketch, however rough.