Enterprise software has to satisfy the people who approve it and the people who open it every day.
Those are different requirements and only one is usually in the room. We scope both from the first fortnight, because the daily work is never on the procurement sheet.
Building and running software since 2007We will tell you when buying a product is the cheaper answer
- ProcurementCommercial terms, exit
- SecurityReview, pen test, SSO
- LegalData residency, retention
- ITIntegration, support model
Every one of those approvals is reasonable. They are simply a different set of requirements from daily use, and both sets have to be met.
Three ways enterprise software gets delivered and not used.
None of these is a failure of engineering. Each one is a requirement that was real from the beginning and was not scoped until late.
It satisfied the approvals and nobody uses it
Every requirement on the procurement sheet is met. The people who do the work keep a spreadsheet beside it, because the sheet never asked how the job is actually done.
The integration was the project, and it was scoped as a line item
Connecting to the systems that already hold the data turns out to be most of the work. It was estimated as a fortnight because nobody had opened the other system.
It works for one business unit and not the next
The first rollout goes well. The second unit has a different approval chain, a different regulator and a different definition of the same field, and the software has none of that as a setting.
What we take on.
Six pieces, and the last two are the ones most often left until the system is finished.
Systems for work that crosses departments
Where a process starts in one team and finishes in another, and the handover between them is the part nobody owns.
Integration with what you already run
The ERP, the finance system, the directory, the ticketing tool. Establishing what each one will actually let you do comes before design, not after it.
Access, roles and delegation
Who sees what, who can act for whom, and what happens when the person who normally approves is away. Retrofitted permissions are the expensive kind.
Audit trail and retention
What was changed, by whom, when, and how long it is kept. Written into the design because it is a legal question long before it is a technical one.
Configuration for more than one business unit
Which parts must be identical everywhere and which must vary. Deciding that late produces either a fork of the codebase or a unit that stops using it.
Handover to your own team or supplier
Documented, deployable and changeable without us. A system only its builder can change is a dependency you have bought rather than an asset you own.
Where the work is one tool for one team, custom software development is the cheaper route and the same engineers. Where the system already exists and is holding you back, that is system modernisation.
See system modernisationSix approvals, none of which waits for the others.
These are not stages and they do not run in order. Any one of them can hold a release on its own, and a team that treats them as a final phase meets six of them at once, six weeks before a date.
Security review
Threat model, dependency scanning, a penetration test and the fixes from it, and single sign-on against your directory rather than a separate password.
Met lateAuthentication rebuilt after the fact, and a test booked into whatever slot the assessor has free.
Data residency and retention
Where the data physically sits, which jurisdictions it crosses, how long each category is kept and what proves it was deleted.
Met lateA hosting decision reversed, which usually means a migration rather than a setting.
Procurement and exit
Commercial terms, support model, and what happens to your data and your ability to run the system if the relationship ends.
Met lateA contract negotiation blocking a release date that was set before anyone read the terms.
Accessibility
Keyboard operation, semantic structure and readable contrast, tested rather than asserted, because a public body or a large customer will ask.
Met lateInterface work across every screen, which is the one item on this list that cannot be bolted on.
Integration and support
Which interfaces you are allowed to use, who runs the connection at three in the morning, and what the escalation path is when it breaks.
Met lateA route discovered to be unsupported after the design assumed it, which changes the design.
Audit and evidence
What the system records, how an auditor retrieves it without an engineer, and whether the record survives a change to the software.
Met lateLogging added to a finished system, which produces evidence starting from the day it was added.
Any one of these holds a release on its own, and none of them waits for the others.
Almost all of this is knowable in the first fortnight. Being surprised by it is the expensive part, not the requirements themselves, and every one of them is reasonable.
How an enterprise build runs.
Approvals and integrations first, because both are discoveries rather than estimates, and both change the design when they arrive late.
Establish what the approvals will actually ask
Security, legal, procurement and IT, in the first fortnight rather than the last. Almost all of it is knowable on day one, and none of it gets cheaper by waiting.
Open the systems you have to integrate with
Before estimating anything. What a vendor says an interface supports and what it supports are separate facts, and only one of them is checkable.
Watch the work in the unit that will use it first
Including the spreadsheet beside the current system. That spreadsheet is the requirement nobody wrote down.
Build one unit end to end, then the second
The second unit is where you find out which of your assumptions were configuration and which were hard-coded. Finding that out at unit two is cheap. At unit nine it is a rewrite.
Hand it over with the reasoning
The code, the deployment, the decisions and what was deliberately not built. Your team or your supplier should be able to change it without asking us.
The second unit is the test. It is where you find out which of your assumptions were configuration and which were hard-coded, and it is much cheaper to find out there than at unit nine.
What the record supports, and what it does not.
We have no published enterprise engagement with a named client and a measured outcome. Rather than borrow a figure, here is what the record does support.
Nineteen years of delivery since 2007
Across six countries and more than 500 projects.
Evidence of building inside other organisations' constraints over time. Not an enterprise engagement of the kind this page describes.
Vizitor, a platform in daily multi-site use
Across 500+ workplaces in 15+ countries.
The closest published evidence for the multi-unit configuration argument above, because the same flow genuinely runs differently per site. Cited as scale context, not as an enterprise contract.
Jewellerybox, a commerce integration still in production
The longest running client integration on the record.
An operations record rather than a launch record, which is the relevant test for software that has to keep working after the approvals are signed.
Deliberately absent
Every competing page in this search result carries at least one of these. None of ours is sourced, so none of them appears.
- No named enterprise client
- No contract value or programme size
- No user or seat count
- No compliance certification we have not audited against
- No saving or efficiency figure
What an enterprise system costs after it is live.
We do not publish figures, because they depend on your directory and your regulator. We do model these four before the build, so running cost is a decision.
- Continuous
Identity is a standing cost, not a setup cost
Directory changes, joiners, leavers and role changes never stop, and every one of them touches access. Budget it as an ongoing obligation.
- Annual
The security review recurs
A penetration test is not a one-off. Most large customers and most insurers want a current one, which makes it an annual line rather than a launch line.
- On their schedule
Every integration is somebody else’s release schedule
The systems you connect to will change without asking you. Monitoring the connection is cheaper than discovering it at month end.
- Per rollout
Each new business unit costs less than the last, or the design was wrong
If unit five costs what unit two cost, the variation between them was never made configurable and you are paying for that decision every time.
What you have when the engagement ends.
Including the approval evidence assembled, so an auditor is handed a record rather than an engineer reconstructing one.
The system in your repository
Deployable by your own team, with the environment described as code.
The approval evidence, assembled
The threat model, the test results and the retention decisions, in a form an auditor can be handed rather than an engineer reconstructing them.
Access and roles as configuration
Changeable by an administrator rather than by a release, because the people change more often than the software.
What varies per unit, written down
Which settings exist, why each one exists, and which behaviours are deliberately identical everywhere.
A written list of what we did not build
Deferred scope with the reason, so the next decision starts from the record rather than from a surprise.
Five kinds of build, and this page is only one of them.
Enterprise is the heaviest of these and most readers who arrive here need a lighter one. The distinction is departments, approvals and more than one business unit.
- One system, one organisation, built around how the work is doneEnterprise Software · you are hereCrossing departments, with approvals and integration as first-class scope.
- Software you intend to keep selling and keep changingProduct DevelopmentA product has customers rather than an internal owner.
- A system you already run is holding the business backSystem ModernisationChanging what exists, without stopping it.
- The problem crosses several systems, teams and operating rules at onceDigital Transformation ConsultingThe decision comes before the build.
- One defined tool, one team, built onceCustom Software DevelopmentWithout the multi-unit and approval weight this page carries.
Tell us which approval you expect to be the hard one.
A senior engineer will tell you whether it is on the critical path, and whether what you are describing is an enterprise build or smaller work wearing the word.
What teams ask before they start.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.