Skip to content
Zorix Systems — software that powers your business

Services

Custom software development

We build the systems that run an operation: case management, scheduling, quoting, field work, compliance records and the reporting that sits on top of them. These are the systems where an off-the-shelf product forces the business to change its process, and the business quietly refuses.

Engagements typically start at £250,000 and run in phases, with the first phase in production within months rather than at the end of a multi-year programme.

When you need this

Recognisable symptoms

  • Your operations team maintains a spreadsheet that the system you bought was supposed to replace, and the spreadsheet is now the version of record.
  • A process that takes two minutes in practice takes eleven screens in the software, so people batch it up and do it badly on Friday afternoon.
  • Every new client, site or product line requires a configuration change from a vendor who quotes six weeks and delivers in twelve.
  • Two departments hold the same customer record and neither will accept the other's version, so a third person reconciles them by hand.
  • You have three systems that each hold part of a job, and no system that can tell you the status of the job.

What we build

Deliverables

  • A domain model and database schema designed around your actual records — jobs, matters, sites, assets, tenancies — rather than a generic object called an opportunity.
  • Core workflow application with role-based permissions, audit trail and configurable status transitions that your administrators can change without a release.
  • Operational dashboards showing live state — what is late, what is unassigned, what is blocked — rather than end-of-month reporting.
  • Integration adapters to the systems the workflow depends on, built as a separate layer so a vendor change does not become an application rewrite.
  • Data migration from the spreadsheets and legacy tables, including a reconciliation report that shows what did not migrate cleanly and why.
  • Automated test suite covering the workflow rules, run on every commit, plus a staging environment your team can use throughout the build.
  • Deployment pipeline, infrastructure as code, environment runbooks and an architecture decision record log, all in your repository.

Our approach

How we run this work

Process observation before specification

We start by watching the work, not by workshopping requirements. Two or three days sitting with the people who do the job produces a materially different specification from a room of managers describing what should happen. The spreadsheets people have built for themselves are the most reliable requirements document in most organisations, because they represent what the business actually needed and did not get.

Vertical slices, not layered phases

The first release is a complete slice of one workflow — screen, rules, integration, reporting — used by real people, rather than a finished data layer with no interface. That means the first thing you evaluate is whether the system fits the work, at a point where changing the answer is still cheap.

Explicit domain rules

Business rules live in one named place in the codebase, expressed in the language your team uses, and each has a test that states the rule in plain English. When a rule changes, we can show you which test changed. Rules scattered through UI validation and stored procedures are the main reason internal systems become unmaintainable.

Fortnightly demonstrable output

Every two weeks there is something running in a staging environment that you can open and use. Progress is reported as working functionality against the phase plan, not as percentage completion. If a sprint produced nothing usable, we say so in the review and explain what changed.

Operational readiness treated as scope

Monitoring, alerting, backup verification, restore rehearsal and access management are delivered as part of the build, not raised as an afterthought at go-live. Handover includes a runbook that a person who did not build the system can follow at three in the morning.

Technology

Named stacks, named versions

Backend

.NET 8Java 21Python 3.12Node.js 22

Frontend

React 19Next.jsTypeScript 5Tailwind CSS

Data

PostgreSQLSQL ServerRedisElasticsearch

Platform

AzureAWSDockerKubernetesTerraformGitHub Actions

Applied by industry

What this looks like per sector

Healthcare and dental

Multi-site clinical operations tooling — recall scheduling, referral triage and treatment plan tracking — built against EMIS Web, SystmOne and Dentally records with clinical risk documentation under DCB0129.

Energy and utilities

Settlement and exception-handling systems that reconcile Elexon data flows against supplier records, replacing the analyst spreadsheets that currently absorb the differences.

Hospitality

Multi-site operations platforms covering rota, stock and margin, taking sales data from EPOS platforms and giving area managers one live view instead of five overnight exports.

Real estate

Lettings and property management workflow across applicant, tenancy, compliance certificate and maintenance job, integrated with Reapit or Alto and portal feeds.

Manufacturing

Professional services

Matter and engagement management with time capture, conflict checks and billing handoff into the practice management system already in place.

Financial services

Industries in detail

Typical engagement

Shape, duration and budget

Discovery
2 to 4 weeks, fixed fee, credited against the build.
Phase one to production
Typically 12 to 20 weeks from the end of discovery.
Team shape
Solution architect and delivery lead in the UK or Germany; pod of 3 to 6 engineers, a QA engineer and a part-time designer.
Indicative budget
£250,000 to £600,000 for a first production phase; larger programmes are phased annually.
Contract
UK entity, English law, fixed-scope phases or dedicated team; IP assigns on payment.

Questions

Frequently asked

How do you estimate a build before the requirements are stable?

We do not estimate a full build from a requirements document. We run a paid discovery sprint that produces an architecture, an integration map and a phased estimate with a stated confidence range per phase. Phase one is then fixed-scope and fixed-price; later phases are re-estimated as earlier ones complete.

Who owns the source code and the intellectual property?

You do. All intellectual property, including source code, designs and documentation, assigns to you on payment for the relevant phase. Repositories can be hosted in your own GitHub, GitLab or Azure DevOps tenancy from the first commit, so ownership is a matter of fact rather than a contractual promise.

What happens if we want to move the system to another supplier?

Everything needed to do that is produced during delivery, not on exit: infrastructure as code, a documented build and deploy pipeline, an architecture decision record log, and environment runbooks. We also support a paid handover period where your team or a new supplier works alongside ours.

Do you work with our existing in-house development team?

Frequently. The usual shape is that our pod owns a defined set of services or modules with its own repository and pipeline, while your team owns others, and both work against a shared architecture agreed at discovery. We do not require ownership of the whole estate.

What is the smallest engagement you take on?

The discovery sprint is the smallest commitment, and it is deliberately small. For build work our typical engagement size is £250,000 and above, because below that a distributed pod with dedicated architecture and QA is not the right cost structure for the client.

Tell us what your systems are doing wrong.

Send the problem, not a brief. We will tell you whether it is a project we should be involved in.

Talk to us