Dorset Software makes a business of keeping yours running

An emergency control room is an unforgiving place to discover that your software cannot give you the full picture. At Wandsworth Borough Council, ageing, disconnected systems made it harder to see incidents, track responses and produce management information. Research ruled out an off-the-shelf package. The council commissioned a bespoke replacement, with a seven-month deadline.

Dorset Software built SITREP, an incident-tracking system using Microsoft .NET and SQL Server. Its design combined connections to existing information with scheduled downloads, helping preserve key reporting functions when connectivity became a problem. Automated reports helped with shift changes. Less retyping meant less administrative friction. These are modest-sounding improvements until you imagine being the person taking over the next shift. The Wandsworth project gives the company’s work a useful human scale.

Founded by Jonathan Gerson in 1987, Dorset Software occupies a durable corner of the technology market: organisations need software to match how they actually operate, and somebody has to build it, connect it and answer the phone afterward.

“SITREP has exceeded our expectations.”

Kevin Hayter · Wandsworth Borough Council

The awkward jobs between the big systems

The company sells development expertise, bespoke applications, consultancy and ongoing support to public and private organisations. A customer can bring in developers to work alongside an existing team or commission a system around a particular business process. Its Digital Marketplace listing describes both remote work and on-site assistance across the UK.

That puts Dorset Software among enterprise technology service providers. The deliverable depends on the assignment: usable code, a working integration, technical capacity or a maintained system. Its value is tied to the customer’s operations, rather than to the number of people who download a standard app.

Consider NHS Resolution. Its old claims-management system was approaching its limit for simultaneous users, with worsening performance and greater failure risk. The replacement combined an intranet with a web-based claims system. The brief also included compatibility with financial software and better communication with outside organisations. The case study describes a familiar trigger for buying bespoke work: the existing system had become a constraint on the institution using it.

Waitrose’s problem was different. Its ageing employee-training system had limited room for improvement. An infrastructure upgrade created an opportunity to replace it, with head-office and branch applications sharing a database. Scheduling training and seeing who needed what became a software brief. The attraction of the Waitrose project lies in that specificity: an ordinary organisational headache, translated into something a developer can actually build.

Shoes, books and the price of extra hands

At Clarks, the requirement was partly about capacity. Its permanent development team needed help when demand rose or particular skills were missing. Dorset Software consultants worked on integration, migration, testing and applications around the retailer’s enterprise systems. One was Orderwell Planner, supporting warehouse planning for the dispatch of 100,000 pairs of shoes a day, according to the historical case study.

The commercial logic was flexibility. Clarks could add suitable developers for specified work instead of staffing permanently for every possible peak. The account of the engagement also makes a pleasingly unglamorous point: Dorset Software arranged travel and accommodation. A buyer acquiring temporary engineering capacity was also avoiding some of the work of organising it.

At The Book Service, Dorset Software’s role was technical support for a voice-directed warehouse-picking system involving Psion and Vocollect. The distributor wanted greater accuracy, efficiency and visibility than its paper-ticket process allowed. An 18-month return on investment was anticipated in the published account. That was an expectation for the system, not a verified payback result or a price tag for Dorset Software’s contribution.

A smaller client, White Knight Traders, illustrates another buying calculation. Infrastructure care had sat with a full-time employee whose support workload did not fill the role. Dorset Software supplied pooled support, addressing matters including backups, server maintenance and network security. The trading firm’s account describes a search for proportionate support costs. The purchasing lesson is to separate the amount of expertise a business needs from the number of permanent jobs it can sensibly sustain.

Those cases suggest a useful way to frame cost. A development assignment buys time and skills; a support engagement buys access to help; a bespoke build buys a defined capability. Comparing them requires a buyer to decide which problem is being priced. A lower day rate can still leave expensive coordination work inside the customer’s own organisation. Conversely, a long relationship alone does not establish that the next commission is good value. A concrete brief makes the comparison possible: what must work, who will test it, and who will maintain it after handover?

A repeat customer called them “Dorsets”

RM Education first sought Dorset Software’s help in 1996, when it needed development skills for a substantial programme of work. The relationship expanded beyond the original department. In a historical case study, RM described the consultants as “Dorsets”, an affectionate nickname that says something a procurement chart cannot.

The same account explains the mechanics: RM’s manager contacted an account manager, who proposed developers based on expertise and suitability for the organisation. Extra people could cover a vacancy or help deliver a project with additional budget. Familiarity reduced the burden of repeatedly finding and introducing outside developers. RM’s experience makes continuity part of the service being purchased.

Dorset Software says roughly three-quarters of its revenue comes from repeat business and that some major client relationships have lasted more than 20 years. Those are company-reported figures, useful for understanding its commercial emphasis. The company also advertises a perfect record of delivering projects on time and within budget. That remains a supplier claim; buyers should judge the proposed scope, acceptance criteria and support arrangements in front of them.

Five months before the client work

Software consultancies depend on people. Dorset Software has made training those people part of the business. Ofsted’s April 2024 inspection recorded 52 apprentices, all employed by the company. Their two-year programme began with five months of off-the-job training, followed by client work and further scheduled learning. Twelve were still in that initial phase when inspectors visited.

The company had gained its own employer-provider contract for the Level 4 software developer apprenticeship in November 2021. Ofsted graded the provision Good. These inspection findings put numbers and an external assessment behind the training story.

Its graduate recruitment proposition is unusually welcoming to people who did not study computer science. The careers site looks for analytical STEM graduates and says previous IT experience is helpful rather than essential. On its staff pages, developer Sarina has a chemical-engineering degree, while developer Lauren studied mathematics. Project manager David studied music performance. The range of backgrounds is more memorable than another list of programming languages.

Training is paid at full salary. The current syllabus covers programming languages, testing, application engineering and cloud infrastructure, with further supported learning after the first live assignments. For another employer, the copyable idea is the sequence: recruit for aptitude, provide protected learning time, then introduce commercial responsibility. The programme requires an employer willing to carry that preparation period; it is poorly matched to a vacancy that needs an experienced specialist immediately.

The biscuit cupboard has competition

Dorset Software’s culture page promises flexitime, shorter core hours on Fridays and 25 days of holiday plus eight bank holidays. It describes company-supported sporting groups, beach barbecues and a regular Friday pub visit. Office refreshments extend to a well-stocked chocolate-biscuit cupboard, with fresh fruit available for anyone determined to resist it.

These are the company’s own descriptions of working life, but they fit the practical recruitment offer: a paid route into software, continued development and a life outside the office. Its current company page lists Poole, Oxford and Manchester and describes work for clients across Europe. It also lists Microsoft and Salesforce partnerships, Cyber Essentials Plus and ISO 9001 certification. For a buyer, those provide useful context alongside the more revealing detail of what a particular team has delivered.

AI arrives at the maintenance desk

The current website leads with AI. Dorset Software now markets agentic engineering, AI-assisted development, AI features inside applications and preparation of data and processes. This broadens the language around an established services business. The important distinction for a customer is what is being commissioned.

AI-accelerated development concerns how software gets made: assistance with planning, architecture, code and testing. AI software engineering concerns features within the resulting system, including agents, generative AI, computer vision and machine learning. Its agentic engineering offer extends to agent lifecycles, platform engineering and code audits. These describe services being offered, rather than measured outcomes from named deployments.

The most grounded part of the pitch may be preparing for AI: cleaning data, reducing database duplication and clarifying workflows. Western Riverside Waste Authority’s earlier project offers a useful parallel. Waste data had been emailed to councils, with problems around accuracy and communicating corrections. Dorset Software’s work there addressed central collection and publication. Reliable information was already a business problem long before AI became the headline.

For prospective customers, the sensible starting point is a concrete obstruction: a system at capacity, information that has to be entered twice, or a team missing a particular skill. Standard software and internal recruitment remain alternatives. Bespoke work earns its place when the requirements justify the build and the organisation can support decisions, testing and upkeep. Dorset Software’s most persuasive invitation is to bring it a difficult operational problem. Preferably one with a person, a process and a consequence attached.