T

Two hundred thousand euros of annual recurring revenue, and nobody on the sales team could say which requirement had failed. The questionnaire had arrived on 3 March. It went to the founder, who forwarded it to the one engineer who might know, who was mid-incident that week. Then it sat. When it went back on the 24th, the champion inside the buyer had already stopped replying in the thread, because he had spent his internal credibility arguing for a vendor who took three weeks to answer a form.

Enterprise readiness for a SaaS startup is a revenue problem assembled out of engineering parts, and it is worth being precise about which parts. Seven things block these deals with any regularity. Together they run somewhere between twelve and twenty-eight engineering weeks from a standing start, two of them poison your codebase permanently if you bodge them under deadline, and the one that kills the most deals is not on the list at all, because it is the three weeks the questionnaire spends in somebody's inbox.

What actually blocks an enterprise deal?

Seven items, and they arrive in a predictable order because procurement processes are more similar to each other than founders expect.

Identity is where most of the time goes, and it splits into two requests that founders routinely treat as one. SSO through SAML 2.0, an OASIS standard since March 2005, means their identity provider decides who gets in. SCIM, specified in RFC 7643 and RFC 7644 and published in September 2015, means accounts get created and, more importantly, destroyed automatically when their HR system says someone has left. Enterprise IT cares more about the second one, because deprovisioning is what their own auditor samples. A team that ships SSO and calls identity done gets asked about SCIM four weeks later, usually by email, usually with a deadline.

Both protocols are old and that is a feature. Okta and Microsoft Entra ID, which most of your customers still call Azure AD, have documented, stable behaviour, and services like WorkOS exist precisely because implementing the assertion handling correctly for every IdP quirk is a worse use of six weeks than paying somebody.

Audit logging is the one nobody scopes properly, because it sounds like something you already have. Application logs are not audit logs. What is being asked for is a durable, attributable record of who performed which action against which record at what time, retained for a defined period, in a store the acting user cannot edit. That is a different artefact with different retention and a different write path, and it is the engineering half of ISO 27001 as much as it is a sales blocker.

The DPA and the subprocessor list read like legal work and are mostly an inventory exercise against your own outbound traffic. Cheap, fast, and wrong in almost every company that assembles it from memory rather than from the code.

Residency is narrower than it sounds in the questionnaire, and for the majority of companies at this stage it means running one stack in one EU region rather than building anything exotic. There is a whole project hiding behind the wrong reading of that question, and answering the residency question without rearchitecting is worth understanding before anyone estimates it.

Recovery commitments are where a questionnaire stops accepting adjectives. RPO is how much data you are willing to lose, RTO is how long you are willing to be down, and both have to be numbers you can defend with a test record. Getting from "we take nightly backups" to "RPO four hours, RTO six hours, last verified 14 May" is real architecture work involving replication and restore rehearsal, and it sits on the same foundations as scaling the backend generally.

Uptime commitments belong in the same conversation and behave differently, because signing one costs nothing on the day and everything afterwards. The first uptime commitment you sign is usually agreed by a salesperson who has never seen your on-call rota.

Penetration testing is the cheapest item on the table and the one most often bought at the wrong moment. A test against a product of this size runs one to two weeks of elapsed time, and the deliverable buyers ask for is either the full report or a summary letter confirming scope, date and that findings were remediated. The variable cost is remediation, which is unknowable until the report lands, though the shape is consistent: a handful of medium findings around access control and session handling, something about rate limiting, and one thing nobody expected. Budget for a retest as well, since most buyers want evidence that high and critical findings were closed rather than acknowledged, and the retest is a separate engagement with a separate invoice.

Why do deals die when nothing is technically missing?

The seven blockers are what founders investigate after a loss. The thing that actually kills the most deals is response latency, and it leaves no trace in the CRM because nobody records it as a reason.

The mechanism is organisational rather than technical. Inside the buyer, one person has staked their judgement on you. They ran the evaluation, they argued for you against a larger incumbent, and their credibility is now attached to the outcome. That person has a security team, a procurement team and a legal team who did not choose you and have no particular interest in your success. Every week the questionnaire sits unanswered, the champion has to defend a vendor who appears disorganised, in meetings you are not in, using information you have not given them.

Three weeks of silence does not read as "they are busy". It reads as a small company without process, which is the precise fear the security review exists to test. By week four the safe recommendation inside the buyer is to defer to next quarter, and deferred enterprise deals close at a fraction of the rate of live ones because the sponsor changes, the budget moves, or the incumbent gets another year.

The fix costs days rather than weeks and it is almost entirely writing. Assemble the answers to the forty questions that recur across every questionnaire, keep them current in one document, and give sales direct access so the first response goes back inside 48 hours with the honest gaps named as gaps. A buyer will accept "we do not have SCIM today, it is scheduled for Q3, here is the design" far more readily than three weeks of nothing followed by a polished yes.

Naming the gaps also protects you later. Every requirement you overclaim in a questionnaire becomes a contractual representation, and the security team will sample it during onboarding rather than taking your word.

Which of these can I fake for one deal, and which compound?

Five of the seven can be handled as a one-off without lasting damage. Two cannot, and knowing which is the difference between a hard quarter and a codebase you are still apologising for in 2029.

Residency for a single customer can be done by hand. Stand up a separate regional environment, put that tenant on it, operate two stacks for a while and accept the tax. It is an ugly arrangement that stays contained to one customer, and you can unwind it later without touching anything else.

Penetration test remediation is bounded by definition, because the report tells you the finite list. The subprocessor list and the DPA are documentation done properly the first time, and doing them properly is cheaper than doing them twice. Recovery numbers can start conservative, since an RPO of twenty-four hours honestly stated and genuinely tested beats four hours claimed and never rehearsed.

Identity is the first one that compounds. Building SAML as a per-customer special case is the single most common architectural wound I see in companies at Series A. It starts reasonably: one enterprise customer, one certificate, a branch in the login handler. Then the second customer's IdP sends a persistent opaque NameID instead of an email address and wants just-in-time provisioning from a custom attribute. The third is on Entra ID with a different assertion shape. By the fourth you have password login, Google OAuth, and three SAML paths that do not share session handling, token expiry or logout behaviour, and every one of them is a security surface somebody has to reason about during the next review.

The tell is a line like if (tenant.id === "acme") sitting in authentication code. Once that exists, the fifth customer's review costs more than the first four combined, because the reviewer has to trace every path.

What breaks is rarely the login itself, which is the part that gets tested. It is everything downstream that quietly assumed one code path. Session lifetime differs between the branches because two of them were written eight months apart. Single logout works for the customer who asked for it and silently does nothing for the other two, so a terminated employee stays authenticated until their token expires. Token refresh behaves differently again. Each of these is a finding waiting for somebody to look, and the person who eventually looks is an auditor or a penetration tester you are paying.

Audit logging is the second. Bolted on reactively, feature by feature, it produces partial coverage, which is worse than none. None is an honest gap you can describe. Partial coverage means you have asserted in a signed contract that user actions are recorded, and that statement is true for about sixty percent of the write paths, and nobody knows which sixty. Retrofitting it properly means revisiting every mutation in the system, and that work does not get smaller as the codebase grows.

Why does building this per deal ruin the codebase?

Because each enterprise buyer asks for a slightly different version of the same thing, and slightly different is the expensive part.

The requests genuinely differ in the details. One wants group membership mapped to roles, another wants roles managed entirely in your product with SCIM only creating the accounts, a third wants both plus an approval step. Handled as one abstraction, that is a mapping layer with configuration. Handled as three deals with three deadlines, it becomes three implementations with shared symptoms and no shared code.

There is an organisational half to this that engineering usually notices too late. The first time engineering says yes to a bespoke requirement under deal pressure, sales learns that the answer to "can we do X" is yes if the contract is large enough. Nobody is acting in bad faith. The feedback loop simply teaches everyone the wrong lesson, and it runs on every subsequent deal until someone changes what gets promised.

The way out is unglamorous. Build the general version once, before the deal that needs it, and let the first enterprise customer configure rather than special-case. That requires deciding to spend engineering weeks on something no signed contract is yet demanding, which is exactly the decision that feels irresponsible in the moment and obvious eighteen months later.

What order should I build them in?

Sequence by how badly each thing retrofits, not by which deal is loudest.

Start with the ability to answer the questionnaire at all, because it costs days and it is what actually killed the deal in the opening of this article. Write down your architecture, your data flows, your subprocessors and your current honest answers to the forty questions that recur, and keep it somewhere a salesperson can reach without asking an engineer. Half of this is a written inventory of your infrastructure that you should have anyway. Turnaround time on the first response is a signal buyers read as competence, and it is the cheapest signal you will ever buy.

Then the DPA and subprocessor list, because legal review runs in parallel with technical review and blocking on paperwork wastes calendar you cannot recover.

Audit logging comes third, ahead of identity, which surprises people. It goes early because it is the item that retrofits worst, touching every write path in the system, and because the compliance work later depends on it existing. Identity can be bought in a fortnight at almost any point. Audit coverage cannot be bought at all.

Identity fourth, designed as one path with configuration, with SCIM in scope from the first line of design rather than added the following quarter.

Recovery numbers fifth. Rehearse a restore, time it, write down what broke, and publish numbers you have actually observed.

Residency sixth, and only against a real contractual requirement rather than an imagined one.

Penetration testing last, because a pen test measures what you built. Commissioning one before the work is paying a specialist to confirm you have not started.

What does enterprise readiness cost in engineering weeks?

Between twelve and twenty-eight weeks from a standing start, depending mostly on whether you buy identity and how much of your infrastructure is already reproducible.

At a fully loaded senior engineer cost of roughly €2,500 per engineering week, that is €30,000 to €70,000 of engineering, spent by a team that probably has between two and eight engineers. Sixteen weeks of work in a team of four is a quarter where one person does nothing else, which is the number that matters for planning rather than the euro figure.

Two things move that range more than anything else. Buying SSO instead of building it removes four to five weeks immediately. Having infrastructure defined in code rather than configured by hand in a console removes several more across residency, recovery and evidence collection, because every one of those tasks starts with reproducing an environment.

The figure nobody puts in a plan is the second deal. The first enterprise customer pays for machinery the next three use unchanged, which changes the arithmetic completely and is the only honest way to evaluate whether the work is worth doing.

Which enterprise deals are not worth the engineering?

Some of them, and the ratio is calculable before you commit.

Take the first-year contract value, the engineering weeks required, and how much of that work survives to the next deal. A €200,000 contract needing sixteen weeks is roughly €40,000 of engineering against €200,000 of revenue, which is fine on its own terms and clearly right if the same machinery serves three more buyers next year. The same sixteen weeks against a €35,000 contract, for a bespoke integration with one customer's internal system that nobody else will ever ask for, is a services engagement wearing a SaaS badge. Price it as services, or decline it.

The rule I use: if the work is generic and repeatable, the first deal is funding product development and you should take it even at an uncomfortable ratio. If the work is specific to one buyer and disappears when they churn, the engineering has to pay for itself inside the first contract term or it should not happen.

That is advice against our own commercial interest, and it is worth saying plainly, because we are the people you would hire to do this build. We would rather quote for the sixteen weeks. The number of times I have watched a small team burn a quarter on a deal that was never going to be repeatable, and then lose the customer at renewal anyway, is high enough that the honest version is more useful than the profitable one.

There is one more caveat on the other side. If your entire enterprise pipeline is a single deal, the readiness work is a bet on a pipeline that does not exist yet. Two or three prospects asking the same questions is a signal. One is an anecdote.

Questions founders ask after a failed security review

Why do enterprise deals stall after the commercial agreement? Because commercial and security approval run on separate tracks, and the second one starts late. The person who agreed the deal usually has no authority over the security review, so the questionnaire reaches your engineers weeks after everyone in the room believed it was done.

Do we need SOC 2 or ISO 27001 to sell to enterprise? Not always. Plenty of buyers accept a completed questionnaire, a recent penetration test and a signed DPA, particularly below about €100,000 of annual contract value. Certification earns its cost once the same questions arrive several times a year, at which point it stops being a hurdle and starts shortening every subsequent review. Ask the specific buyer in front of you rather than assuming, because the answer varies more by sector than by deal size.

How long does it take to add SSO to a SaaS product? One to two weeks using a provider that abstracts the identity protocols. Three to six building SAML yourself, plus another two to four for SCIM, which enterprise IT asks for separately and cares about more.

What is the difference between SSO and SCIM? SSO controls authentication, so their identity provider decides who can log in. SCIM controls provisioning, so accounts appear and disappear automatically as their HR system changes. Deprovisioning is the half their auditor samples, which is why shipping SSO alone rarely ends the conversation.

How much engineering time should a startup budget for enterprise readiness? Twelve to twenty-eight weeks from nothing. Buying identity rather than building it removes four to five of those immediately.

Pull up the last security questionnaire you received and check one number: how many days passed between it arriving and you sending it back. If that number is above five, fixing it is the cheapest revenue work available to you this quarter, and it requires no architecture at all.