Development team working on a business application in an office
Registered activity 62012

SoftwareDevelopment

We build the systems an organisation runs on: the record of what happened, the queue of what happens next, and the view that tells somebody senior whether any of it is going well.

Positioning

Not websites. Operating systems for a business.

Alvoris develops operational software: applications that hold records, move work between people, control who can see what, and produce a defensible account of what was done and when.

This is a different discipline from building a brochure site or configuring an off-the-shelf product. The value sits in the data model, the permissions, the state transitions and the reporting — not in the visual surface, however carefully we design it.

We build when a purpose-built system is genuinely the right answer. When it is not, our consultancy practice exists precisely so we can say so.

Our build model

Four layers, built in this order.

Most failed business systems were built from the screen inwards. We work from the record outwards, because the record is the part that has to survive five years of daily use.

The four layers of an Alvoris business system A stack of four layers built from the bottom upward: the record layer, the rules and workflow layer, the access and permissions layer, and the interface and information layer. Layer 04 — built last Interface & information Screens, forms, lists, filters Dashboards, exports, printed output Only as complex as the task requires Keyboard-first where staff use it all day Layer 03 Access & identity Roles, permissions, record-level rules External users kept in their own lane Every action attributable to a person Audit trail written, not optional Layer 02 Rules & workflow Valid states and permitted transitions Assignment, escalation, due dates Encoded once, applied everywhere Exceptions handled deliberately Layer 01 — built first The record Entities, relationships, identifiers History that cannot be quietly overwritten Modelled from your actual process Designed to be reported on later Build order
Foundation — agreed before any screen is designed Layers built on top of it
When a build is justified

Signals that a purpose-built system will pay for itself.

Bespoke software is not automatically the right answer. These are the conditions under which it usually is.

“The spreadsheet has become the system, and only two people understand it.”

Concurrency, version conflicts and undocumented formulas are structural problems, not discipline problems. A real record with real permissions removes them.

“We tried an off-the-shelf product and spend more time working around it than in it.”

Where the workaround cost is recurring and measurable, a system modelled on your actual process is usually cheaper over three years.

“Nobody can answer a simple question without asking three people.”

If status lives in inboxes and heads, it cannot be reported on. Making status explicit is often the entire return on the project.

“Our process is genuinely unusual, and it is the reason we win work.”

Distinctive process is worth protecting. Software should encode it, not flatten it to match a vendor's assumptions.

“Clients keep emailing to ask where their job has got to.”

A controlled external view removes a recurring administrative load and improves how the organisation is perceived at the same time.

“We need an audit trail we can actually stand behind.”

Where evidence matters — regulated work, disputes, complaints — attribution and immutable history need to be designed in from the first day.

And when it is not justified: if a well-supported product covers eighty per cent of what you need and the remaining twenty per cent is not commercially important, we will say so — and a software selection engagement will cost you considerably less than a build.

How we build

Conventional technology, applied carefully.

We choose boring, well-documented technology on purpose. A system you can hand to another developer in three years is worth more than a system built on something fashionable.

  • 01Process before schemaWe walk the process with the people who run it, including the exceptions they have stopped mentioning because everybody knows about them.
  • 02A documented data modelEntities, relationships and states written down and agreed before build. This document outlives the project and belongs to you.
  • 03Interfaces that respect the userFast entry, sensible defaults, few clicks, no decoration that slows down somebody doing the same task ninety times a day.
  • 04Permissions and audit as first-class featuresWho can see it, who changed it, and when — designed in, not bolted on after a compliance question.
  • 05Integration where it earns its placeConnections to accounting, email or existing line-of-business systems where they remove duplicate entry, not for the sake of an architecture diagram.
  • 06Data you can take with youExport routes and documented structures from day one. You should never need our permission to get at your own records.
  • 07Handover that means somethingWritten documentation, an administrator walkthrough and a defined support window after go-live.
Cost and duration

Development engagements start at £2,100.

The starting figure covers a first working system for a defined process, not a prototype. Broader scope, more integrations or migration of existing data will increase it.

Indicative starting price From £2,100 Depending on which of the four development services applies. Every engagement is quoted in writing after scope is agreed. Third-party hosting, licences and subscriptions are charged at cost and identified separately.
Typical first delivery 4–10 weeks From agreed scope to a first usable release, depending on complexity, the number of user roles, data migration and how quickly review feedback comes back. Timing always depends on scope.
Start a conversation

Describe the process. We will tell you whether it needs software.

Bring us the workflow that is causing the most friction. If a build is not warranted, you will get that answer in the first conversation rather than in a proposal.