Enterprise software development

Enterprise software, in the sense this page covers, is internal: the systems that run approvals, operations, logistics, reporting and the corporate functions between them. Most companies start on packaged tools and spreadsheets, and for a while that works. The breaking point comes when the process is the business – when how you route an application, schedule a workforce or reconcile a ledger is exactly what differentiates you, and the package forces you to do it the vendor's way.

Bespoke development reverses that relationship. We build applications from scratch, tailored with the specific modules and features needed to digitise critical business processes, instead of asking the business to bend around a licence. The economics only make sense when the workflow is core to how you compete: commodity functions belong in commodity software, and if analysis shows a package fits, we will say so before you spend on custom code.

One boundary to draw early: this page is about systems you run, not products you sell – product and SaaS builds are a separate discipline with their own economics.

Enterprise builds sit inside our wider software development practice, which sets the engineering standards every project here inherits.

A new internal system never lands on a green field. It arrives into an estate of ERP, CRM, identity, finance and data platforms that were not designed to talk to it, and that integration surface – not the new feature set – is where enterprise projects succeed or fail. So we treat the estate as a first-class input: which system owns each record, where the data quality problems hide, and which constraints are actually immovable. These are the questions we settle before any code is written:

• Which system masters each entity, and which ones hold copies
• How authentication and access map onto your identity provider
• Whether integrations run over APIs, middleware or asynchronous messaging
• What the system does when a dependency is unavailable
• How legacy data migrates, and how it is reconciled

Answering these on paper costs days; answering them in production costs quarters. The architecture document we deliver captures each decision and its reason, so a question asked long after handover is answered from the record, not from whoever remembers the meeting.

When the starting point is an existing system that needs rebuilding rather than a new build beside it, that is application modernisation – a separate discipline with its own page.

Internal systems outlive the assumptions they were built on. The stack chosen at kick-off must still be hireable, patchable and observable a decade later, so we bias towards proven, well-governed technology and keep the novel parts small and behind stable interfaces. That applies to AI too: where the workflow justifies it, AI is integrated as a replaceable component, not poured into the foundations.

PushMaster, the push notification server we built for reliable multi-channel delivery across web and mobile, shows the bias in practice: every technology in it is deliberately unexciting – widely deployed, well documented and straightforward to hire for – because a messaging layer an entire estate leans on cannot afford an exotic foundation. Client builds get the same treatment: every dependency has an owner and an upgrade path, and nothing critical rests on a library one maintainer could abandon.

Technology governance is part of the deliverable: a documented stack decision record, a dependency and licence inventory, and an upgrade cadence your security and compliance teams can actually audit.

For the full build story, read the PushMaster case.

No one can fix a credible price for an enterprise system before the estate and the requirements are mapped, so we price in two stages. A bounded analysis phase comes first, at a known cost, and produces the roadmap; the build price is then quoted against that roadmap rather than against a feature wish-list. If the analysis shows the build is not worth it, you keep the roadmap and walk away – that is the point of pricing it separately.

Cost is driven by a handful of variables you can see and control: the number of systems to integrate, the volume and quality of legacy data to migrate, compliance and security requirements, and how many environments the rollout needs. Analysis, engineering, design, testing and the management that coordinates them are all present, but their weight shifts with the roadmap – heavier on analysis at the start, on engineering through the middle, on testing towards release.

Transparency is the working rule throughout: an open backlog, demos on a regular cadence and progress you can verify rather than take on trust – the quality Verysell Group's chairman highlights in his review of our work.

An internal system will spend far longer in service than it ever spent in development, and that long tail is where its reputation is made. The systems that stay healthy are the ones with a clear operating model, agreed before launch: who owns the backlog, how change requests are raised and prioritised, what the release cadence is, and which metrics tell you the system is drifting before users do.

The business will not stand still around it. New departments, new regulations and new acquisitions all arrive as change requests, and the system absorbs them as modules rather than rewrites because the architecture, the test automation and the documentation were built for that from day one. That is the practical meaning of long-life maintainability: a change in year five carries the same risk as a change in year one.

We write the exit into the engagement from the start: the documentation, environments and access are arranged so a new team – yours or anyone's – could pick the system up without archaeology, and whether we keep a role after handover is decided by the results, not by how the system was built.