What breaks when your first enterprise customer arrives?
you're moving fast, you've shipped login, it works, users are in. and then an enterprise prospect shows up and the first thing they ask is 'do you support SSO?' and suddenly the thing you built in a weekend is blocking a six-figure deal.
but SSO is usually just the first question. after that comes the security questionnaire. then someone asks about audit logs. then their IT team wants to know how they'll provision and deprovision users at scale. then legal asks about data residency.
none of these are unreasonable asks. they're just things that consumer auth setups were never designed to handle, and retrofitting them while the deal is live is one of the more stressful engineering experiences a startup can have.
the teams that handle this well usually didn't predict every enterprise requirement upfront. they just built on a foundation that could extend without being rebuilt from scratch.
curious what actually broke first for people when the first enterprise customer arrived. was it SSO, audit logs, permissions, something else entirely?
Replies
Data residency is one those things you probably dont think about until a customer actually asks for it.
MonoCloud for Startups
@bradywilfaqn exactly!! and by the time they ask, it's usually not a nice to have anymore. it's a blocker. and retrofitting data residency into an architecture that wasn't designed for it is a very different project than building it in from the start.
none of the four. what broke first was that our data model had no concept of a company.
everything had been built per user, because per user is what you build when your first hundred signups are individuals. then sso shows up, and sso is not really a login feature. it assumes there is a directory of people who belong to an organisation, and that the organisation is the thing that owns the account. we had users with email addresses and nothing above them. so the two week sso ticket was actually a tenancy migration wearing a login costume, and every screen that said your projects had to learn whose.
the audit log one has a nastier shape. you can add logging in an afternoon. what they actually want is the history of who changed what and what it was before, and you cannot backfill a thing you never wrote down. the day they ask is the day the clock starts, and it starts at zero.
so if i were picking one thing to do early it would not be sso. it would be putting an organisation between the user and everything the user owns, on day one, while every customer is still a single person. it costs almost nothing when the table has one row in it.
@rabnoor_s This is the right answer, and I'd sharpen the last part, because "put an organization in on day one" is cheap advice that fails in a specific way.
The table isn't the expensive bit. An organizations table with one row per signup costs nothing and buys nothing either, and it's how you end up modeling an imaginary company that gets thrown away the moment a real one turns up. Every read goes through an owner lookup even while the owner is always the person asking. Then the migration is changing what that lookup returns, in one place, rather than auditing every screen that said "your projects"
The part nobody warns you about is the rows you already wrote. Backfilling an org id is trivial. Deciding which org owns a row created before organizations existed is what eats the week, and the fun case is two individual accounts that turn out to be one customer, with data on both sides that somebody merges by hand while the deal is live.
MonoCloud for Startups
@siarheihamanovich data archaeology problem is the one nobody puts on the ticket. two rows that turn out to be one customer, with data on both sides, being merged by hand while the deal is live. that scenario alone should convince people to think about this earlier than they do.
@riya_pariyar What decides whether that merge is an afternoon or a week is whether the rows carry who made them.
With an actor on every row the merge is a query: same person acting on both accounts, here's the overlap, here's what only exists on one side. Without it you're inferring from email domains and creation order, on data the customer is about to be billed against. And the failure mode is quiet, because the safest merge is usually the one that drops the ambiguous side, and nobody in the room can defend keeping it
@siarheihamanovich you are right, and that is the better version of it. the part that survives your objection is not the table. it is never letting the user id be the owner id in code. one owner column that happens to point at a person today costs nothing and turns the later change into a backfill instead of a rewrite.
@siarheihamanovich yes, that is the sharper version. indirection through the owner lookup is what you buy on day one, not the table itself
MonoCloud for Startups
@rabnoor_s honestly the sso thing is never just an sso thing 😄 it always turns out to be a data model conversation nobody was expecting to have mid-sprint. and the audit log one stings because there's no fix. the history you never captured is just gone.
@riya_pariyar exactly, and it arrives disguised as a two day auth ticket. audit logs are the cruel one, you only miss them when someone finally asks
This is a really relatable point. Enterprise requirements can appear very suddenly once a serious customer enters the picture. 👀
MonoCloud for Startups
@oliver_graf1 and when it does arrive, it arrives with a 40-question security questionnaire 😅
@riya_pariyar Haha, exactly 😅 That’s when you realize there’s a whole enterprise checklist you never knew existed.
I'm on the other side of this one. I run engineering inside a big org, so I'm closer to the people who send you that questionnaire than the people filling it in, and what kills vendors from where I sit is never a missing feature.
It's an answer that shows there's no process behind the capability. "Do you have audit logs" is asking whether anyone ever looks at them. Deprovisioning is the same: the honest failure isn't that you can't remove a user, it's that nobody can tell me who removed the last one or when. A small vendor who writes "no SCIM this quarter, here's when, and here's how offboarding works by hand until then" gets through review. One who answers yes to everything and then can't produce a single example triggers a second round of questions, and the second round is where deals actually die.
SSO, logs and provisioning are things a startup can buy from you. Evidence that somebody reviewed access last quarter isn't, and it's the one item on that list nobody can backfill once the deal is live. So if I were advising the startup side, the cheap thing to start today is writing down who approved what in whatever ugly file, from the first customer on.
MonoCloud for Startups
@siarheihamanovich this is a good distinction. SSO, logs, provisioning etc. get treated as feature requirements, but having them doesn’t mean much if there’s no process behind them.
and agreed on the evidence part. you can add capabilities later. you can’t recreate a history you never recorded.
The evidence point Siarhei made is the one I'd underline from the audit side. Access review is not a feature question, it is whether anyone can produce, for any point in the last twelve months, who had access to what and why it was granted. Most of what fails a control test is not a missing tool, it is that the record only ever lived in someone's head or a spreadsheet nobody touched after month two. Org first data modelling fixes the query problem, you can find the answer fast. It does not fix the review problem, which is a standing process, someone reads the access list on a schedule and signs their name to it, not a report generated the week the questionnaire lands. The cheap thing a solo founder can do before any of this is live is decide who that someone is and put a date on the calendar, even if the list has three rows on it.
MonoCloud for Startups
@oshylabs calendar point is so underrated. most teams treat access review as something they'll figure out when someone asks for it. but by then you're generating a report, not demonstrating a process, and that difference is exactly what fails a control test.
@riya_pariyar The thing that keeps the calendar entry alive is attaching it to something that already happens on its own, not creating a new standalone task nobody defends past month two. Tie it to the payroll run or the deploy cadence, something that already forces someone to look at the account list, and it survives because it is riding on attention that already exists rather than asking for new attention.
the tell is that the sso ticket always gets estimated by whoever knows the auth library, and the work is almost entirely in the part of the codebase they do not own. that is why the estimate is always wrong in the same direction.