Enterprise software development is the design, build, integration and ongoing support of custom systems that run part of an established business, usually alongside ERP, CRM and legacy platforms. In 2026 a departmental system costs $80,000 to $200,000 (€70,000 to €175,000, £60,000 to £150,000), a core business platform $200,000 to $600,000 (€175,000 to €520,000, £150,000 to £445,000), and an enterprise-wide program $600,000 to $2,000,000+ (€520,000 to €1,740,000+, £445,000 to £1,480,000+) delivered in phases. The decisions that determine success are made before code is written: whether to build or buy, which partner and engagement model, how to modernize incrementally, and who owns adoption.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
Most guides to enterprise software are written for vendors or for engineers. This one is written for the person who has to sign the purchase order: a CTO, CIO, head of operations or managing director at a company of fifty to five thousand people that has outgrown its spreadsheets, its vendor's road map or its twenty-year-old core system. It covers what enterprise software development is and is not, what it costs, how to decide between building and buying, how to choose and contract a partner, how to modernize without stopping the business, and how to make sure the people who are supposed to use the result actually do. Each section links to a detailed post, so you can read the summary here and go deeper where your decision is.
What is enterprise software development?
Enterprise software development is the building of custom systems for an established organization, where the software has to fit into an existing landscape of ERP, CRM, finance, HR and legacy applications, serve several departments with different needs, meet security and compliance obligations, and keep working for a decade. It differs from startup product development in three ways. The users already exist and have a way of working that the software must respect or deliberately replace. The data already exists, usually in several places that disagree. And the project competes for attention with a business that must keep running while it is built.
That is why the hard parts of enterprise work are rarely the code. They are integration, data, governance and adoption. The posts in this guide are organized around those decisions rather than around technology.
How much does enterprise software development cost?
The honest answer is a set of bands, with the band decided by how many systems, roles and workflows the software touches.
| Scope | Cost | Duration | Typical examples |
|---|---|---|---|
| Departmental system | $80,000 to $200,000 (€70,000 to €175,000, £60,000 to £150,000) | 3 to 5 months | A field service tool, a quoting system, a compliance workflow, an operations dashboard with one or two integrations |
| Core business platform | $200,000 to $600,000 (€175,000 to €520,000, £150,000 to £445,000) | 6 to 12 months | An order management or logistics platform, a customer portal on top of the ERP, a multi-role system with several integrations |
| Enterprise-wide program | $600,000 to $2,000,000+ (€520,000 to €1,740,000+, £445,000 to £1,480,000+) | 12 to 36 months, in phases | Replacing a legacy core, a modernization of a portfolio of applications, a platform that several business units share |
Expect support and maintenance at 15 to 25 percent of the build cost per year, and hold 15 to 25 percent of the program budget as contingency. The full breakdown, the drivers that move a project between bands and where the money goes line by line are in how much enterprise software development costs. If you are planning across several budget years, how to budget a multi-year software program explains phasing, contingency and what finance will ask. What you pay after go-live, and what each support tier buys, is in enterprise software support and SLAs.
Should you build, buy or customize what you have?
Custom software is the right answer less often than vendors suggest and more often than SaaS vendors suggest. The rule we use: buy when the process is the same as everyone else's, customize your ERP or CRM when the process is close to theirs and the vendor's tooling is good, and build when the process is how you compete or when no product fits without a chain of workarounds. The five-year total cost of ownership comparison, including the hidden costs of each route, is in build vs buy: custom software vs SaaS vs ERP customization. The same question for operations tooling specifically is in custom internal tools vs off-the-shelf, and if your current state is a web of spreadsheets, email and re-keying, workflow automation with custom software shows where the payback is.
How do you choose and contract a development partner?
The partner decision is the largest in the program and it is usually made on the two weakest signals: the lowest price and the biggest logos. Price tells you how narrowly the vendor read your scope. Logos tell you what they can put in a case study. Neither tells you whether they will deliver a system your people will use. The signals that do are in this group of posts.
| Decision | What it determines | Read |
|---|---|---|
| Which company | Whether delivery, integration and support are real capabilities or sales claims | How to choose an enterprise software development company, with a weighted scorecard |
| How to ask | Whether the proposals you receive can be compared at all | How to write an RFP for custom software development |
| Engagement model | Who carries delivery risk, how fast you can change direction, what it costs per month | Dedicated team vs project-based vs staff augmentation |
| Where the team sits | Rates, time-zone overlap, management overhead, data residency | Nearshore vs offshore vs onshore |
| Security and compliance | Whether the vendor can be trusted with your data and your auditors | Security and compliance questions to ask a software vendor |
| The contract | Ownership, acceptance, change control, exit | MSA, SOW and change requests |
Two shorter posts apply at any scale: who owns the code and fixed price vs time and materials. And whatever the vendor says about being end-to-end, what end-to-end really means lists the seven things the phrase has to cover.
How do you modernize a legacy system without stopping the business?
Every established company runs on software someone would love to replace. It is slow to change, hard to hire for and increasingly expensive to secure, and it also processes every order, invoice or patient record. Replacing it in a single cutover is one of the riskiest projects a company can take on. Our position, explained in software modernization without the big bang, is to put an interface in front of the old system, replace it slice by slice, migrate data deliberately and switch the old system off when nothing depends on it.
The decisions inside that approach each have a post:
- Which option for which system. Rehost, replatform, refactor, rebuild or replace with SaaS, with the relative cost and risk of each, in legacy system modernization: the five options compared.
- How systems talk to each other. Point-to-point, an API layer, middleware, iPaaS or events, and the system-of-record question, in enterprise application integration.
- How the data moves. Profiling, mapping, cleansing, three rehearsal runs and reconciliation, in data migration from legacy systems.
- Whether to split the monolith. The honest cases for and against, by team size and release pain, in monolith to microservices.
- Where it runs. Cost, sequencing and the risks nobody puts in the business case, in cloud migration for enterprise applications.
If the system is in a regulated industry, building software for regulated industries covers what changes when compliance is a requirement from day one.
Where does AI fit in an enterprise program?
Most enterprise AI projects fail on integration and data, not on models. The use cases that reach production are narrow, measurable and attached to a process someone already owns: document handling, classification, routing, summarization, forecasting on data the company already keeps. The pilot that proves one of these costs $30,000 to $80,000 (€26,000 to €70,000, £22,000 to £60,000) and takes six to ten weeks, and hardening it for production typically costs two to three times the pilot. Enterprise AI pilots: how to pick the first use case has the scoring table. The broader stance is in AI business empowerment, and what data you need before AI can help answers the question most leaders ask first.
How should the program be run?
Roughly half of large software projects overrun their budget or schedule, and the causes are structural rather than technical: no single accountable owner, decisions that take weeks, scope that nobody controls, and a business that is not ready for the result. The three posts in this group are the ones to read before the kickoff meeting.
- Start with discovery. Three to eight weeks, $15,000 to $60,000 (€13,000 to €50,000, £11,000 to £44,000), producing a written scope, a system map, an integration inventory and an estimate you can hold a vendor to. The discovery phase for enterprise software lists the deliverables and explains why it is worth paying for.
- Set up governance that decides. A steering group that meets to decide rather than to be informed, named decision rights, and one owner on the business side. Why enterprise software projects fail maps each cause to its early symptom and its structural fix.
- Plan adoption before go-live. Software that is delivered and not used is a failed project with a passed acceptance test. User adoption for internal software covers champions, training, the old system and the first ninety days.
Two general posts are worth having on the steering group's reading list: why software projects go over budget and signs your development project is going wrong.
What does a well-run enterprise program look like?
| Phase | Duration | Output |
|---|---|---|
| 1. Discovery | 3 to 8 weeks | Written scope, system and data map, integration inventory, risks, phased estimate |
| 2. Foundations | 4 to 8 weeks | Environments, pipelines, security baseline, the API layer in front of legacy systems, the first thin slice in production |
| 3. Delivery in slices | 3 to 24 months | Working software released every two to four weeks, each slice replacing or extending something real, data migrated with each slice |
| 4. Rollout and adoption | Per slice, plus the first 90 days | Trained users, champions in each team, the old process switched off, adoption measured |
| 5. Support and evolution | Ongoing | An SLA that matches how critical the system is, a backlog owned by the business, a budget for change |
The ten decisions that decide the outcome
- Build, buy or customize, decided per process rather than for the whole company.
- A discovery phase with written outputs before any fixed price.
- A partner chosen on a scorecard, with references you have called.
- An engagement model that matches how much you expect the scope to change.
- A contract that assigns ownership, defines acceptance and controls change.
- Security and compliance answered in writing before signing.
- Modernization by slices, never by a single cutover date.
- One system of record for each kind of data, and an integration layer that enforces it.
- Governance that decides within days, with one accountable owner on the business side.
- An adoption plan and a support tier agreed before go-live.
How 7L approaches enterprise software development
7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens. We started during the Greek financial crisis, which taught us to deliver with constrained budgets, and we have since supported more than one hundred organizations across healthcare, finance, hospitality, fleets, IoT and smart buildings. We work end-to-end, from discovery through design, build, launch and support, and we modernize incrementally rather than with a big bang, because the legacy system is the business until the day it is empty. If you are at the start of a program, a discovery engagement is the right first step, and if you already have a scope or an RFP, we are glad to review it and tell you what we would change.
Frequently asked questions
What is the difference between enterprise software and SaaS?
SaaS is software a vendor builds once and rents to many companies, so the process inside it is the vendor's. Enterprise custom software is built for one organization and fits its processes, data and existing systems. Most companies run both: SaaS for processes that are the same everywhere, such as payroll or email, and custom systems for the processes they compete on or that no product fits.
How long does an enterprise software project take?
A departmental system takes three to five months. A core business platform takes six to twelve months. An enterprise-wide program or legacy replacement takes one to three years and should be delivered in phases, with working software in production every few months rather than at the end. The first three to eight weeks of any of these should be a discovery phase that produces the scope and the estimate.
Should we hire in-house developers or use a software development company?
For a defined program with a start and an end, a development company is usually faster and cheaper, because hiring a team takes three to six months and the team is hard to scale down afterwards. For a product your company will change every week for years, in-house ownership matters, and a common pattern is a partner to build and launch while you hire the team that will take it over. Dedicated team vs project-based vs staff augmentation compares the engagement models.
What is the biggest risk in an enterprise software project?
A big-bang cutover from the old system to the new one, followed closely by scope that nobody controls and decisions that take weeks. Each is structural rather than technical and each has a known fix: replace the old system in slices, run a change control process from the first week, and give one person on the business side the authority to decide.
How much should we budget for support after go-live?
Plan for 15 to 25 percent of the build cost per year. That covers security updates, dependency upgrades, small fixes, monitoring and the occasional incident. An SLA with 24/7 coverage and a one-hour response for critical issues costs $15,000 to $40,000 (€13,000 to €35,000, £11,000 to £30,000) per month for a core system, while business-hours support for a departmental tool costs $2,000 to $5,000 (€1,500 to €4,500, £1,500 to £3,500) per month. The post on enterprise software support and SLAs has the tiers.