From MVP to First Enterprise Customer: What Breaks at 10,000 Users

The foundations problem

Founders describe this moment to us in much the same words each time. They built a house, the product works, and now somebody wants it to carry an apartment block.

The analogy is close without being exact. Software is rarely a straight choice between demolishing and building higher. Most MVPs we look at are structurally sound in the places that matter, and weak in a predictable set of places that only reveal themselves under a different shape of load. The work is usually narrower than it feels from the founder’s chair, and the way to find out how narrow is to look rather than to estimate.

Two things get conflated here that are worth separating. Getting a prototype to production quality is one problem, and our guide to prototype to production covers it. Taking a working production product into a large organisation is a different problem, and that is what the rest of this covers.

What changes when the customer is large

Four things change at once, and each drives a different category of work.

Volume changes the shape of operations rather than just the count. A customer with 10,000 workers does not onboard them one at a time. They arrive as a spreadsheet, get assigned in bulk, and need actioning in a single operation that somebody watches while it runs. Code written to handle a page of records behaves differently when it is handed ten thousand.

The buyer has an IT function. Somebody will ask about single sign-on, data isolation, audit logs, and integration with systems you have never heard of. None of that is unreasonable, and it is much easier to answer if you thought about it before the question arrived.

Your software becomes part of their process. Pilot users work around problems and tell you about them kindly. Enterprise users escalate them, because your product now sits inside a process with consequences attached, and the person reporting the issue is often not the person who chose you.

Administration gets delegated. At small scale, one person at the customer administers everything. At enterprise scale, regional managers, site supervisors, and head office each need a different view and a different set of permissions, and none of them should see everything.

Where MVPs actually break

Tenancy and data isolation

The first question a security reviewer asks is how their data is kept separate from your other customers’ data.

Many MVPs filter by a customer identifier in application code. It works, and it carries a single point of failure, because one query written without that filter exposes another customer’s records. The exposure grows with every feature added by every developer who joins later, and it is the kind of defect that gets found by a customer rather than by a test.

Stronger options include enforcing isolation at the database level with row-level security, giving each customer their own schema, or separating larger customers into their own database. Which of those is right depends on your product, your expected customer count, and what your team can realistically operate. A hybrid is common, where most customers share infrastructure and the largest few are isolated, and that also gives you something to offer a buyer who asks for dedicated hosting.

What will not survive a reviewer’s attention is having no considered answer. If you have chosen application-level filtering deliberately, say so, explain the tests that enforce it, and describe what would have to change to move further. We would also add automated tests that specifically attempt cross-tenant access, because a test suite that proves isolation is worth more in a review than a paragraph claiming it.

Bulk operations

Look at every operation a large customer will run against many records at once:

• Importing a workforce from a spreadsheet
• Assigning a module, licence, or task to everybody in a group
• Sending a notification to thousands of recipients
• Exporting or reporting across a whole organisation
• Any scheduled job that processes all records nightly

These are the most common failure points we find, because each was almost certainly written and tested against a handful of rows. The symptoms are familiar. A request times out behind a load balancer, or a loop issues one database call per record, or a third-party rate limit on email throttles you halfway through. In each case nobody can see how far the job got.

The remedies are well understood and worth doing properly the first time:

• Move the work to a background queue so the user is not holding a browser request open while ten thousand records process.
• Process in batches sized to your database and your third-party limits, with backoff when a limit is hit.
• Make each unit idempotent, so that retrying a failed batch cannot double-send a notification or duplicate a record.
• Give the operation a visible status, including progress, completion, and a per-record result the customer’s administrator can download.
• Make partial failure recoverable, so a job that fails at record 8,000 resumes rather than restarting.

That last pair matters more during a rollout than at any other time, because the customer’s administrator is watching an import of their entire workforce and needs to know which twelve rows failed and why. An operation that succeeds or fails as one opaque unit generates support tickets that a per-record result file would have answered.

Administration, roles, and delegation

Enterprise customers need to delegate. A national organisation will want head office to see everything, regional managers to see their region, and site supervisors to see their site, and they will want to add and remove those people themselves.

If your permission model is a single administrator flag, this is real work, because it touches every screen and every query. It is better done deliberately and early than incrementally under a rollout deadline. Ask the prospective customer for their organisational structure during the sales process, since that tells you what the hierarchy has to support. Check how often that structure changes, because a model assuming a stable hierarchy struggles in an organisation that reorganises twice a year.

Two related requirements usually arrive with this one. Customers ask for the ability to act on behalf of a user so they can support their own staff. They also ask to suspend an account immediately rather than waiting for a nightly synchronisation.

Audit trails

Regulated and safety-critical customers need to know who did what and when, and they need that record to survive the underlying data being changed or deleted.

An audit trail is not a last-modified column. It is an append-only record of significant events carrying the actor, the timestamp, the entity, and the before and after values, retained for a defined period and readable by the customer without asking you. Retrofitting one is manageable when the data model is clean and considerably harder when the application updates records in place with no history.

Decide the retention period explicitly, because customers in regulated sectors will ask, and the answer interacts with your erasure obligations under UK GDPR. You will also need to reconcile two things that pull against each other: an audit trail that must not change, and a data subject’s right to erasure. Our guide to data subject rights, retention, and erasure covers how to remove personal data while preserving the integrity of the record.

Reporting

Reporting against the live transactional database is fine until somebody runs an organisation-wide report during business hours and the application slows for every other customer on that database.

The standard answers are a read replica, a separate reporting store fed asynchronously, or pre-aggregated summary tables maintained as data changes. Which one fits depends on how fresh the figures have to be, so ask that question before building anything. Customers frequently ask for real-time reporting and need yesterday’s numbers, and the difference between those two answers is significant in both build cost and running cost.

Expect a request to export to their own business intelligence tooling as well. A scheduled extract in a documented format satisfies more of these requests than a dashboard does, and it costs far less to build.

Identity and authentication

Large organisations generally want their staff signing in with corporate credentials through single sign-on, most often via Microsoft Entra ID. Where your users are a deskless or contingent workforce without corporate accounts, that may not apply at all, and a phone-based flow will suit them better than anything their IT department would choose.

Ask early either way. Authentication touches everything, and retrofitting an identity provider during a rollout is among the more disruptive changes available to you. If single sign-on is required and not yet built, it is usually better to commit to a date and run the pilot on your existing mechanism than to delay the whole rollout behind it.

Two details tend to be forgotten until late. The customer will want accounts deprovisioned when somebody leaves their organisation, which means either automated provisioning or an agreed process. They will also want to know what happens to a user’s data and audit history once that account is closed.

Integration

At some point the customer will want your system to talk to theirs, whether that is a human resources system, an access control system, or a payroll and time and attendance platform. What they ask for first is usually an export or a webhook rather than a deep integration, and meeting that request well buys you time.

Two things make later integration much easier if you do them now. The first is a documented and versioned application programming interface, and our guide to API versioning strategies covers how to avoid painting yourself into a corner. The second is stable external identifiers for the entities other systems will reference, so that a worker or a site can be matched reliably across systems that each hold their own identifiers.

Be careful what you commit to during a sales process. Integrating with a customer’s internal system means depending on their team’s availability, their change control, and their test environment, and those dependencies belong in the project plan rather than in a sales conversation.

Onboarding and configuration

If setting up a new customer currently involves an engineer running scripts, that model limits how fast you can grow regardless of how good the product is. Enterprise onboarding also takes longer than pilot onboarding, because it involves their data, their structure, their approvals, and often their communications team.

Make configuration self-service and data-driven, and make the onboarding sequence repeatable and documented, with a named owner on both sides. This is operational work rather than architecture, and in our experience it is the constraint that binds soonest once two or three enterprise customers arrive together.

Support load

Support volume scales with active users, and enterprise users report more than friendly early adopters did. They also expect a response inside an agreed time rather than when somebody gets to it.

Size this before signing the service level agreement. Work out expected ticket volume from your current rate per active user, and decide who covers evenings and weekends where the customer operates then. Define what constitutes a severity one incident in terms of business impact rather than technical symptom. A rota built from two or three people works until one of them is ill, and most small product teams find managed application support less expensive and more durable than trying to staff it internally.

What usually does not break

It is worth being clear about what is generally fine, because founders often spend their preparation budget in the wrong place.

• Raw compute capacity. Modern cloud platforms handle far more load than most products will ever see, and scaling up is a configuration change. The bottleneck is almost always one specific query or one serialised operation rather than the size of the server.
• The core data model. Where the domain was modelled sensibly, it holds. Poor modelling causes trouble long before the first enterprise customer arrives.
• The user interface. Screens that work for a hundred users generally work for ten thousand, with the exception of any list or search that now returns far more rows than it was designed to display.

What these have in common is that they were exercised from day one. The things that break are the operations nobody ran at volume and the features small customers never needed.

Migrating the customer’s existing data

Most enterprise customers are not starting from nothing. They have workforce records in a human resources system, training histories in a spreadsheet or an older platform, and site or depot structures that exist in somebody’s head as much as in any system. Getting that into your product is usually the first real deadline of the rollout, and it is frequently underestimated by both sides.

The data will be messier than the sample they sent you. Names will be inconsistent, people will appear twice, leavers will still be present, and the identifiers that should match across two systems will match for ninety per cent of records. Building an import that assumes clean data guarantees a bad first week.

What we would build before a migration of any size:

• A validation pass that runs before anything is written, producing a report of what would fail and why, so the customer can correct their data rather than discovering the problems afterwards.
• A dry run into a staging environment using the real file, repeated until the error list is short and understood.
• A documented decision on duplicates and conflicts, agreed with the customer rather than decided in code by whoever wrote the importer.
• Reversibility, so a migration that goes wrong can be rolled back cleanly rather than unpicked by hand.
• A reconciliation report showing counts in and counts out, which is what the customer’s project manager needs to sign off the step.

Historical data deserves an explicit conversation. Customers often assume their existing training records or compliance history will carry across, and importing history is materially more work than importing a current-state snapshot. Agree early whether you are bringing history, a summary of it, or nothing, because that decision changes the migration and sometimes the data model.

The rollout itself

A large customer does not switch on in a day, and the sequence you agree shapes how much goes wrong in public.

Two things determine whether that sequence holds. The first is whether the customer has a named project owner with the authority to decide things. A rollout that routes every question through a committee will slip regardless of how good the software is. The second is training and communication, which are the customer’s responsibility and frequently become your problem anyway when adoption stalls and the software gets blamed.

Build a pause into the plan after the first live site. In our experience that week produces more useful information than the preceding two months of preparation, and a plan with no room to act on it wastes what the pilot just told you.

What it costs to run at scale

Model your running costs before you price the deal, because a customer with 10,000 users can change your unit economics in ways that are not obvious from a pilot.

The drivers we would look at first:

• Per-message third-party services. Email, SMS, and push notifications are usually charged per send, and a compliance product that notifies a whole workforce weekly can spend more on messaging than on hosting.
• Storage and data transfer, particularly where the product holds documents, photographs, or video evidence.
• Background processing, since the bulk operations you moved to a queue still consume compute, and nightly jobs across a large customer are not free.
• Database tier, which is often the single largest line and the one most likely to need an upgrade partway through a rollout.
• Log and telemetry retention, which scales with traffic and surprises people when a retention period was set generously and never revisited.

Work out the cost of serving one large customer and compare it against what you are charging them. Where the margin is thin, the fix is usually a design change rather than a price change. That might mean batching notifications, moving evidence files to cheaper storage after a period, or reducing log retention to what the audit requirement actually needs.

Load testing that tells you something

Load testing an enterprise rollout is less about concurrent users than founders expect and more about the specific operations that will run during onboarding.

Use the customer’s actual numbers rather than round figures. If they have 9,400 workers across 37 sites with an average of 6 training modules each, test with those numbers, because the shape of the data matters as much as the volume. Test the bulk import with a realistic file, including the messy rows that real workforce data contains. Run the organisation-wide report while other traffic is present rather than against an idle system.

Two failure modes are worth hunting deliberately. The first is the operation that works at 1,000 records and fails at 10,000, which usually points at something loading a whole collection into memory. The second is the query that is fast with one customer’s data and slow once the table holds several customers’ data, which usually points at a missing index.

A sequence that works

1. Assess with the specific customer in mind. User numbers, organisational structure, integration requirements, availability expectations, and their security requirements. A generic scalability review is far less useful than one aimed at the deal on the table.
2. Fix anything that could leak or lose data. Tenancy isolation, backup and restore verification, and audit trails come before everything else, because these are the failures you cannot apologise your way out of.
3. Harden the operations that will run at volume. Bulk import, bulk assignment, bulk notification, and reporting.
4. Build the enterprise features the contract needs. Roles and delegation, single sign-on where required, exports, and integration points.
5. Instrument before you roll out. Structured logging with a correlation identifier, application performance monitoring, and alerting on error rates and latency rather than on server metrics alone.
6. Load test against realistic numbers, concentrating on the bulk operations rather than on concurrent browsing.
7. Stand up the operational side. An incident process, an on-call arrangement, and the support cover your SLA promises.
8. Pilot inside the customer. One region or one site before the full rollout, which is the cheapest way to find what the assessment missed.

Steps two and three are what protect you from the failures that lose a customer. Steps four to six are what the contract and the rollout depend on. The pilot in step eight turns the remaining unknowns into a list you can work through before the whole organisation is watching.

Deciding what to say yes to

A first enterprise customer will ask for things specific to them. Some of those are general requirements arriving early, and others are customisations that will constrain your product for years.

Apply one test: would you build this if a second customer asked for it? If the answer is yes, build it properly as a product feature with configuration rather than as a special case. If the answer is no, price it as bespoke work or decline it. Reshaping the platform around one customer is how a product company turns into an agency with a single client, and unwinding that two years later is expensive.

The same discipline applies to commitments. An availability target, a recovery time, or a support window you cannot meet today is a liability you have chosen to take on. The customer will hold you to it during the first incident rather than during the negotiation. Negotiate on what you can evidence, and revisit it at renewal once you have a track record to point at.

Where to go next

• For the evidence that customer’s procurement team will ask for: enterprise buyer security evidence
• If your product was built by a partner and you are not sure what you control: do you actually own your software
• If the product is closer to a prototype than a live system: prototype to production
• On the support model once you are live: managed support versus hiring
• On the audit and erasure requirements that arrive together: data subject rights, retention, and erasure
• If the team who built it is no longer available: your development team left, what happens next

We take on products built by other teams, assess what a rollout at scale will expose, and run them under an agreed service level once they are live. To talk through a specific rollout, book a consultation.