Enterprise Software Development Services: What You Are Buying

Enterprise software development services, as the phrase is used on most agency websites, means the same work with a larger number attached. The team is the same, the process is the same, the pitch deck gains a logo wall, and the price triples. Buyers know this, which is why procurement departments have learned to ignore the word and read the schedules instead.

There is a real distinction underneath, and it is not about company size. A forty person insurer can run a genuinely enterprise programme, and a twelve thousand person retailer can commission something that is really just a website. What separates them is the obligations the system imposes on whoever builds it: how many other systems it must speak to, how long it is allowed to be down, who can veto a release, which regulator has an interest, and what happens if the supplier walks away.

What follows defines the category by those obligations, so a buyer can tell a supplier who can carry them from one quoting an ordinary build with an enterprise cover sheet.

What actually makes a software project enterprise? Not the size of the buyer. A project is enterprise when it carries constraints an ordinary build does not: a wide integration surface, a contractual uptime and recovery obligation, regulatory exposure, several stakeholder groups who can each block a release, data volumes that break naive designs, and the requirement to coexist with systems nobody currently understands. Those constraints, not the feature list, decide the architecture and most of the cost.

What Makes a Project Enterprise

The useful test is a list of constraints, and a project qualifies when it carries most of them rather than one. Applied honestly it disqualifies much of what is sold as enterprise, and qualifies work sold as a small build that then fails because it was scoped as one.

The integration surface

Count the systems your new software must exchange data with, then count the number of separate teams or vendors who own those systems. The second number is the one that predicts cost. Three integrations owned by one internal team is a fortnight of work. Three integrations owned by three vendors, each with its own change window, sandbox availability and support desk, is a quarter.

Each owner brings a schedule you do not control. A vendor whose sandbox refreshes monthly sets your testing rhythm, and a payments provider whose certification takes six weeks sets your go-live date. With a dozen counterparties the integration calendar becomes the project plan, and development fits into the gaps.

The uptime obligation

Ordinary software is expected to work. Enterprise software has a number attached to that expectation, usually in a contract with a service credit behind it. The number changes the architecture first, because a single-instance deployment cannot honour it no matter how good the code is.

The step from a target that tolerates a maintenance window to one that does not is the single most expensive line in most enterprise budgets, and it is frequently agreed by people who have never seen the price. Our piece on uptime SLAs that mean something covers how those numbers are written and how they are routinely written badly.

Stakeholders with a veto

An ordinary project has a product owner. An enterprise project has a product owner, an information security function, a data protection officer, a procurement lead, an infrastructure team who own the network, a service desk who will inherit the support load, and often a clinical, legal or compliance reviewer.

Any one of them can stop a release, and none reports to the person paying for the work. Decisions therefore take calendar time unrelated to how hard they are, and a supplier who has not built that into the plan misses every date from the second month onward.

The Systems Nobody Understands Any More

Every enterprise estate contains at least one system whose behaviour is documented only by its output. The people who wrote it have gone, and the specification, if it exists, describes an earlier version. It works, it is load bearing, and changing it is considered unwise.

New software must coexist with it, so somebody has to establish what it actually does first. That is archaeology, not development: reading production data, tracing calls, running controlled experiments against a copy, and writing down the rules the code implies. On a large estate it is weeks of work, and it is the line item most often deleted during negotiation because it produces no visible feature.

Deleting it moves the work to integration testing, where it is discovered under time pressure by people already fixing defects. A supplier who prices discovery separately and defends it is telling you something true about how these programmes fail. Our note on legacy modernisation and the rewrite versus refactor decision covers what that archaeology finds.

Procurement Is Half the Job

Most technical people underestimate this part by a factor of three. On a genuinely enterprise engagement the work between the first conversation and the first line of code takes longer than the first delivery increment, and it consumes senior time on both sides.

Since 24 February 2025 the UK public sector has run on the Procurement Act 2023, and suppliers bidding for public contracts must be registered on the central digital platform within the enhanced Find a Tender service. Private sector procurement has no equivalent single front door, which paradoxically makes it slower, because every buyer has invented its own.

The security questionnaire

You will be sent a spreadsheet. It will ask about your development lifecycle, your access controls, your patching cadence, your subcontractors, your data residency, your incident response times and your background checks. Larger buyers send several hundred questions, and a bank or an NHS trust will send more.

The questions are not hard, but they are only answerable if the answers already exist as policy. A supplier assembling them for the first time during a bid takes four to six weeks and gets several wrong. One who has done it before answers in days from a maintained response library, which is a legitimate reason to prefer them.

Vendor onboarding, insurance and financial checks

Onboarding is separate from the bid and often runs alongside it. Expect to evidence professional indemnity and cyber liability insurance at a level the buyer specifies, employer’s liability cover, and sometimes product liability. Enterprise buyers commonly require indemnity limits a small consultancy does not carry by default, and raising cover mid-bid takes time.

Financial checks follow. Buyers pull filed accounts, run a credit score and, on larger contracts, ask for management accounts or a parent company guarantee. A supplier whose balance sheet cannot support the contract value is excluded regardless of technical merit, which is why capable small firms lose bids they were right for.

Why the Sales Cycle Outlasts the First Increment

Put the two timelines side by side and the shape of the problem becomes clear. Qualification, requirements, security review, legal negotiation, insurance evidence and onboarding commonly occupy four to nine months on a contract worth several hundred thousand pounds. The first useful increment of software, once work starts, might take ten weeks.

Estimates written at the start of that cycle are stale by signature, and a supplier holding a fixed price across the gap is either padding heavily or planning to argue about scope later. Technology assumptions age too, and a version that was current at bid can be out of support at kickoff.

Date every estimate, state its assumptions, and agree a re-baselining step at signature rather than pretending the number survived. Buyers who insist the original figure stands are buying a change request pipeline. Our guide to writing a software RFP that gets useful quotes covers what belongs in the document.

Non-Functional Requirements Are the Real Deliverable

Feature lists are easy to write and rarely decide anything. The non-functional requirements decide the architecture, the infrastructure bill, the size of the team and the length of the test cycle, and on most enterprise programmes they are two paragraphs long in a document where the feature list runs to forty pages.

That imbalance is the most reliable predictor of an overrun. A supplier who spends the first workshop on availability, recovery, latency, throughput, auditability and retention is not stalling: those six numbers remove most of the architectural options, and fixing them late means rebuilding.

Write them as testable statements with a number and a condition attached. “The system must be highly available” is not a requirement. “The order service must sustain 99.9 percent monthly availability measured at the load balancer, excluding a two hour window notified five working days in advance” is one, because a test can fail it.

Recovery Point and Recovery Time in Plain Language

Two of those numbers drive cost more than any feature, and they are routinely quoted by people who have swapped their meanings. The recovery point objective is how much data you are willing to lose: an RPO of one hour means you accept that up to an hour of transactions may be gone after a disaster, and your backup or replication scheme must guarantee no worse. The recovery time objective is how long you are willing to be down, so an RTO of four hours means the service is serving traffic again within four hours of the incident starting.

Both numbers translate directly into architecture. AWS sets out four broad strategies in its disaster recovery guidance: backup and restore, pilot light, warm standby, and multi-site active/active. They run from cheap and slow to expensive and nearly instant, and the choice is made for you once the two objectives are agreed.

Avoid agreeing aggressive numbers because they sound responsible. An RPO of zero with an RTO of minutes means continuous replication and a second live environment, roughly doubling the infrastructure bill. Our write-up on disaster recovery for small software teams shows what the cheaper tiers buy.

Availability Arithmetic and What an SLA Actually Buys

Availability percentages hide their meaning behind a decimal point. Over a 30 day month, 99.9 percent permits about 43 minutes of downtime, 99.95 percent permits about 22 minutes, and 99.99 percent permits about 4 minutes. Those are the whole month’s budget, including deployments, certificate renewals and the database failover that took longer than expected.

Four minutes a month is not achievable by a team that deploys in working hours and pages one engineer. It needs redundancy at every tier, automated failover, deployments that do not interrupt traffic, and somebody awake at three in the morning. That last item usually costs more than the infrastructure and is almost never in the original budget. Fix the measurement point in the contract too, because availability read at the load balancer and availability read from real user telemetry can differ by an order of magnitude on the same incident.

Latency, Throughput and the Load Nobody Measured

Latency targets need a percentile and a scope, because averages conceal the failures. A stated target of 200 milliseconds at the 95th percentile for the checkout endpoint under 400 requests per second is testable. A target of “fast” is not, and neither is an average, since an average of 200 milliseconds is compatible with one user in twenty waiting four seconds.

Throughput needs a peak, not a mean. Retailers size for the Friday before Christmas, payroll systems for the last working day of the month, and public sector services for the deadline in the letter that went out. Sizing for the annual average is how a launch fails in its first busy hour. Take the peak from the existing system’s logs, where ratios of ten to one are common, because that ratio decides whether the design needs a queue.

Auditability and Retention

Regulated buyers, and increasingly unregulated ones, need to answer who changed what and when, years later. That is a design requirement rather than a logging configuration: a system that overwrites rows cannot answer it, and the answer must survive as long as the retention policy says.

Decide three things early. Which events are auditable, usually state changes to records with legal or financial significance rather than every HTTP request. How long each class of record is kept, a legal question with a data protection constraint attached, since holding personal data longer than necessary is itself a breach. And who can read the trail, because an audit log administrators can edit proves nothing. Retention and erasure rights collide here, and the tension is resolved in the schema rather than in policy.

The Certifications a Buyer Will Ask For

Three come up repeatedly, they are constantly confused, and they prove different things. A supplier who cannot explain the difference does not hold them.

Cyber Essentials and Cyber Essentials Plus

Cyber Essentials is the UK government backed baseline, developed by the NCSC and delivered through IASME as its official delivery partner. It covers five technical controls: firewalls, secure configuration, security update management, user access control and malware protection. The basic level is a self-assessment questionnaire that is independently reviewed, and NCSC lists pricing from GBP 320 plus VAT depending on organisation size.

Cyber Essentials Plus is the same five controls verified by an independent technical audit rather than asserted. The assessor runs internal and external vulnerability scans and tests a sample of user devices, internet gateways and internet-facing servers. The Plus audit must be completed within three months of the basic certification, and both certificates last twelve months.

The scheme matters commercially as well as technically. PPN 014, in force since 24 February 2025 across central government departments, their agencies, non-departmental public bodies and NHS bodies, requires certification where suppliers handle citizens’ personal information, government employees’ personal information, or ICT systems processing data at OFFICIAL.

ISO/IEC 27001

ISO/IEC 27001 is the international standard for an information security management system, published by ISO and IEC. The current edition is ISO/IEC 27001:2022, with Amendment 1 in 2024 adding climate action wording to the context clauses in line with a change applied across ISO management system standards.

It is a management system standard, which is the part buyers misread. It does not specify a fixed set of controls that every certified organisation has implemented. It requires that the organisation define its scope, assess its risks, select controls, and run a documented cycle of review and improvement. Certification is issued by an accredited certification body after an audit, not by ISO itself.

So the useful question is never whether a supplier holds it, but what the scope statement on the certificate covers. A scope limited to a head office function tells you nothing about the team holding your source code and production credentials. Ask for the certificate and read the scope.

SOC 2

SOC 2 is American and different in kind. The AICPA defines it as “a report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy”, performed under its trust services criteria. It is an attestation report produced by a CPA firm, not a certificate, and there is no pass mark or logo to display.

The distinction that matters is the type. A Type 1 report describes the controls and assesses whether they are suitably designed at a point in time. A Type 2 report tests whether they operated effectively across a period, commonly six or twelve months. A Type 1 is a photograph and a Type 2 is a film, and buyers who accept a Type 1 as equivalent are accepting much less than they think.

Read the report, not the cover page. The exceptions section, where the auditor records controls that did not operate as described, carries the information, and it is the part suppliers hope you skip.

What none of them prove

None of the three certifies that your software is secure. Cyber Essentials covers a baseline of infrastructure hygiene. ISO 27001 covers whether the organisation manages security as a process. SOC 2 covers whether stated controls operated over a period. All three concern the supplier, not the product.

Application security is a separate discipline with separate evidence. Ask for the last penetration test report and its remediation status rather than the certificate wall, and check who performed it and against what scope. That is the substance behind our penetration testing services.

Regulatory Exposure by Sector

Regulation is where generic enterprise advice becomes unsafe. What follows names verifiable obligations and stops short of legal advice, which you should take from a qualified adviser.

UK GDPR, which applies to almost everyone

If the system touches personal data, Article 32 of the UK GDPR applies to both controller and processor. It requires appropriate technical and organisational measures, and it names four: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience of processing systems, the ability to restore availability and access to personal data in a timely manner after an incident, and a process for regularly testing and evaluating the effectiveness of those measures.

Read the third of those again, because it makes disaster recovery a data protection obligation rather than an operational preference. The ICO’s guidance on data security points at Cyber Essentials as a useful baseline while stating plainly that it is only a base set of controls and will not address every organisation’s circumstances or every processing operation’s risks.

Financial services and health, briefly and carefully

In financial services, the FCA’s operational resilience regime requires in-scope firms to identify important business services, set impact tolerances for them, and be able to remain within those tolerances during severe but plausible disruption. The transition period ended on 31 March 2025, so the obligation is live and it shapes what a supplier to those firms must evidence.

In health and care, a health IT system engages NHS England’s clinical risk management standards: DCB0129 for manufacturers and DCB0160 for the organisations deploying it. Both are under national review, with a public consultation running from 29 June 2026 to 11 September 2026, so confirm the current position before relying on any summary including this one.

If your sector is not named here, treat the obligation generically: identify the regulator, read its own published requirements, and make the supplier evidence against those rather than a general assurance narrative.

Integration Architecture Is Where the Money Goes

Enterprise cost concentrates in the seams between systems, not inside them. The features are usually well understood. Getting six systems with different data models and different notions of a customer to agree is where the schedule goes.

Point to point versus a broker

Point to point is the default because the first integration really is simpler that way. The cost is combinatorial: with n systems talking directly you head towards n squared connections, each with its own retry logic, credentials and monitoring. At four systems that is fine. At fifteen it is unmaintainable.

A broker or event bus inverts that curve. It adds a component, an operational burden and a single point of failure to design around, and pays for itself around the sixth or eighth participant. The mistake runs both ways: small estates buy an integration platform they do not need, and large ones defer it until the mesh has calcified.

Synchronous versus event driven

A synchronous call is easy to reason about and couples availability. If your service calls four systems inline and each is up 99.9 percent of the time, your own ceiling is roughly 99.6 percent before you have written a bug. Every synchronous dependency is a share of your uptime handed to somebody else’s operations team.

Event driven designs decouple that, at the price of eventual consistency and much harder debugging. Keep synchronous calls for the path where the user is waiting and a stale answer is unacceptable, and move everything else onto events. Decide this per interaction rather than as a house style.

Idempotency, Replay and Reconciliation

Distributed systems deliver messages more than once and lose them occasionally, so every write path crossing a boundary must be safe to repeat. The established pattern is a client-generated idempotency key. Stripe’s implementation saves the status code and body of the first request for a given key, returns the same result on retries, prunes keys after at least 24 hours, and errors if the same key arrives with different parameters.

Replay is the operational half of the same idea. After a downstream system has been unavailable for six hours, somebody must push the missed messages through, which is only safe if consumers are idempotent and the messages were retained. Design the retention window and the replay mechanism alongside the happy path, because retrofitting them means changing every consumer.

Reconciliation gets treated as an afterthought and should not be. It is a scheduled job comparing the state of two systems that are supposed to agree, reporting differences and either correcting them or raising them for a human. Without it, a silent divergence from a finance system is found by an auditor months later. Budget it as a first-class deliverable with an owner and an alert route, not a script somebody writes at the end.

Legacy Coexistence and the Strangler Fig

Wholesale replacement of a working system is the highest-risk option available and is chosen far more often than it should be. The incremental alternative is documented by Microsoft as the Strangler Fig pattern: put a facade in front of the legacy system, route requests through it, and move functionality across piece by piece until the old system has no traffic left and can be switched off.

Every increment is independently valuable and independently reversible: if the third slice goes wrong, you route it back. Microsoft is explicit about where it does not apply, namely when requests to the back end cannot be intercepted, when you cannot modify the legacy source, or when the system is small enough that replacing it outright is easier.

Two details decide whether it works. The facade must not become a bottleneck or a single point of failure, so it needs the same availability engineering as the services behind it. And cross-system calls during the transition need an anti-corruption layer, so legacy semantics do not leak into the new design. The data is harder than the traffic: moving a domain’s tables out means an initial load, a change data capture feed, a validation period where both stores are written and compared, and only then a cutover, with rollback possible until the legacy objects are dropped.

Testing at Enterprise Scale

Testing on an enterprise programme is a logistics problem as much as an engineering one, and it is where optimistic plans die.

Environments

You will need more than you budgeted: development, an integration environment wired to counterparty sandboxes, a performance environment close enough to production for its numbers to mean something, a user acceptance environment stable enough for busy non-technical people, and production. Each has infrastructure cost, a refresh process and an owner. The one that always slips is performance, and skipping it means load testing in production.

Test data and the personal data problem

Enterprise systems need realistic data to test against, and the realistic data is production data, which contains personal information. Copying it into a test environment is processing under UK GDPR and the Article 32 obligations follow it there, including access control and the security of the environment holding it.

The defensible answers are anonymisation, which must be irreversible to take the data outside the regulation, or pseudonymisation, which reduces risk but keeps it in scope. Both need engineering work to preserve the statistical shape that makes the data useful, and a documented process. Restoring a production database into a shared test environment is common, unlawful in many configurations, and exactly what a supplier assessment is designed to surface.

Performance testing

Performance testing answers whether the system meets the throughput and latency numbers agreed earlier, so it can only exist if those numbers were written down. Test the peak profile rather than the average, and include the shape of the peak, because a ramp over ten minutes and a step change in one second exercise different failure modes.

Run it against production data volumes. A query that is instant against 10,000 rows and unusable against 40 million is the commonest performance defect in enterprise software, and it is invisible on a small dataset.

User acceptance testing with people who have other jobs

UAT is scheduled as a two week window and is the phase that most reliably overruns, because the testers are the business experts and the business still needs them. They will give you a few hours a week, and their availability collapses at month end.

Name the testers in the contract, agree the hours per week, script the scenarios in advance rather than asking people to explore, and run defect triage as a joint session rather than a ticket queue. A supplier who quotes two weeks of UAT with no named participants has not run one before.

Delivery Model and Governance

The team shape that works is small and stable rather than large and rotating: a technical lead who owns the architecture for the whole programme, three to six engineers, a delivery lead who handles the counterparty calendar, and shared access to a quality engineer and an infrastructure specialist. Adding people mid-flight reliably slows a programme, because the constraint is context, not hands.

Write decision ownership down before the first sprint. Name one person who can approve scope changes, one who can approve architectural trade-offs, and one who can accept a release. If those are three names, decisions take days. If they are committees, decisions take weeks and the plan is fiction.

Steering cadence keeps a long programme honest: fortnightly delivery review with the working group, monthly steering with the budget holder and the veto holders in one room, and a written status reporting against the original baseline rather than last month’s revised one. A supplier whose status is permanently green is not managing risk, they are hiding it.

Commercial Models and Who Carries the Risk

Four models cover almost everything, and each puts the risk somewhere different. The question is not which is best but which party is better placed to carry the uncertainty in front of you.

Time and materials suits genuinely uncertain work: discovery, legacy archaeology, or an integration against a poorly documented counterparty. The buyer carries the risk and gets full flexibility, which requires trust and a burn rate somebody actually watches.

Capped time and materials adds a ceiling, and is the usual sensible compromise, which is how we structure most of our software development services. The supplier absorbs overrun above the cap, the buyer pays only for what is used below it, and both sides keep scope honest. Expect the cap to carry fifteen to twenty five percent contingency, because a supplier who caps at expected cost is either mistaken or planning a change request.

Fixed price works only where scope is genuinely fixed, which on an enterprise programme is true of an increment rather than the whole. Fixed-price increments of six to ten weeks, each scoped after the previous one lands, give budget certainty without pretending anyone can specify eighteen months up front.

Managed service is the right shape once the system is live: a monthly fee covering support, patching, monitoring and a defined change allowance, priced as a percentage of build cost per year rather than by headcount. Make the service definition name the response times and the escalation path.

Enterprise Software Development Services: What Drives the Cost

Cost drivers in order of impact

The order surprises people, because features come last. The integration surface is first, and specifically the number of external owners rather than the number of endpoints. The non-functional targets are second, because the step from a service that can take a maintenance window to one that cannot changes every layer of the design.

Third is the assurance and regulatory load: bid time, evidence production, audit support and a slower release process for the life of the contract. Fourth is data migration and reconciliation, consistently underestimated because the difficulty lives in the quality of the old data rather than the volume. Fifth is the number of stakeholder groups, which sets decision latency. Sixth is environment count. Feature scope is seventh, and it is usually the only thing in the original budget.

Indicative UK price bands

The bands below are house estimates from UK engagements, expressed as first-year cost including discovery, build, testing and go-live but excluding the buyer’s own staff time. They are indicative rather than quotations, and the ranges are wide because the drivers above move them.

Stated without the table: a single service with two or three integrations, internal users and a 99.5 percent target lands between GBP 120,000 and GBP 250,000 in its first year. A customer-facing departmental system with five to eight integrations at 99.9 percent runs GBP 300,000 to GBP 700,000. A core platform replacing a legacy system, with ten to twenty integrations and a 99.95 percent target, runs GBP 900,000 to GBP 2.5 million. A multi-entity regulated programme at 99.99 percent starts around GBP 2.5 million and rises.

The run cost that is not in the budget

Add annual run cost on top, which lands between fifteen and twenty five percent of the build cost per year once support, hosting, patching, security work and a modest change allowance are included. A budget that funds the build and not the run produces a system that decays visibly in its second year, and our breakdown of software maintenance cost sets out where that money goes.

Exit and Continuity

A supplier you cannot leave is a risk sitting on your balance sheet, and it is the clause most often left to the end of the negotiation when nobody is paying attention. Four things make an exit possible.

Source code and its history belong in a repository the buyer owns or can take on notice, with the build pipeline and infrastructure definitions. Code without the pipeline that builds it is an archive, not a working asset.

Documentation should let a competent third party operate the system: architecture, integration contracts, runbooks for failure modes that have actually happened, and the credentials inventory. Our piece on technical documentation that gets read covers what survives a handover.

Escrow covers the supplier failing rather than departing, by lodging the source with a third party for release on defined triggers. It is worth having where the supplier is small relative to the contract, and worth reading carefully, because an unverified deposit releases code that does not build. We looked at when it is justified in software escrow, who actually needs it.

Finally, price the handover in the contract. A named number of days of knowledge transfer at an agreed rate, triggered on notice, turns an argument into an invoice. The same discipline applies to your suppliers’ suppliers, covered in our note on software supply chain security.

Judging a Supplier’s Enterprise Credibility in One Meeting

Five questions establish most of this in an hour, and the hesitation tells you as much as the answer.

Ask what availability and recovery objectives they have delivered against, and how availability was measured. A supplier who has carried a 99.95 percent obligation names the measurement point and the on-call arrangement without prompting. One who has not talks about redundancy in general terms.

Ask to see the scope statement on their ISO 27001 certificate, or the exceptions section of their SOC 2 Type 2. Both are ordinary requests to a supplier who holds them and awkward to one who has a logo. Then ask how they handled a reconciliation break in production, which nobody can answer from theory.

Ask what their last three programmes overran by and why. Everyone overruns, and the informative part is whether they know the number. Then ask what their exit process looks like, in days and deliverables. A supplier who has written that down expects to be judged on it.

Where This Leaves a Buyer

The word enterprise should describe obligations, not a price band. Once the integration surface, the availability and recovery objectives, the regulatory exposure and the exit terms are written down, the shortlist sorts itself out, because most suppliers cannot evidence against those four.

Mecanik works on this shape of engagement through our software development services, and the assurance side through penetration testing services. If you are assembling the requirement rather than the shortlist, the technical due diligence checklist is a reasonable start, and the non-functional numbers are worth arguing about first.

Frequently Asked Questions

What counts as enterprise software development? Enterprise is defined by constraints rather than by the size of the buyer. A project qualifies when it has a wide integration surface owned by multiple parties, a contractual availability and recovery obligation, regulatory exposure, several stakeholder groups who can each block a release, data volumes that break naive designs, and a requirement to coexist with legacy systems nobody fully understands. A large company can commission an ordinary build, and a small regulated firm can commission a genuinely enterprise one.

What does an enterprise software development programme cost in the UK? As house estimates from UK engagements, a single service with two or three integrations and a 99.5 percent availability target runs GBP 120,000 to GBP 250,000 in its first year. A departmental customer-facing system at 99.9 percent runs GBP 300,000 to GBP 700,000. A core platform replacing a legacy system runs GBP 900,000 to GBP 2.5 million. Add fifteen to twenty five percent of the build cost per year for run and support.

Does an enterprise supplier need ISO 27001, Cyber Essentials or SOC 2? They prove different things. Cyber Essentials is a UK government backed baseline of five technical controls, with a Plus tier verified by independent technical audit and required by PPN 014 for many public sector contracts. ISO/IEC 27001:2022 certifies an information security management system, so the scope statement on the certificate matters more than the certificate. SOC 2 is a US attestation report by a CPA firm, and only a Type 2 tests whether controls operated over a period.

What are recovery point and recovery time objectives? The recovery point objective is how much data you accept losing after a disaster, so an RPO of one hour means up to an hour of transactions may be gone. The recovery time objective is how long you accept being unavailable, so an RTO of four hours means the service must be serving traffic again within four hours. Both drive architecture and cost more than any feature, because they select between backup and restore, pilot light, warm standby and multi-site active/active.

What should be in an enterprise software contract about exit? Four things. Ownership or transferable access to the source repository, the build pipeline and the infrastructure definitions. Documentation sufficient for a competent third party to operate the system, including runbooks and a credentials inventory. Source code escrow where the supplier is small relative to the contract value, with verified deposits rather than unverified ones. And a priced handover clause naming the days of knowledge transfer and the rate, so leaving is an invoice rather than a dispute.