Custom software development

>reading the systems you already run...
>mapping what has no interface...
>ready to build.

When no product fits, we build the one that does.

One team, accountable end to end. No handoff between the people who design it, the people who build it, and the people who keep it running.

Agentic AI · Build agents · Now live

Agents do the reading. The engineer commits every change.

Most of the cost in a custom build is not typing. It is understanding a system nobody documented, written by people who have left. Our agents carry that load, and the work they produce is evidence an engineer reviews, never a change an agent ships on its own.

Migration analysis

Reads the legacy codebase and data model, then produces the integration map a rewrite actually needs: what is referenced, what is dead, and what has no owner left.

Integration probe

Exercises an undocumented endpoint or an old system and reports how it really behaves, rather than how its documentation says it behaves.

Test generation

Writes coverage against the specification, including the edge cases the specification implies but never states.

Review agent

Reviews every diff against the conventions of your codebase, not against a generic style guide.

A glimpse of the work

Code on the left. The screen your team will use on the right.

QueueRow.tsx · intake-console · live preview
Editor
0 / 15 lines
1export function QueueRow({ item }) {
2const tone = statusTone[item.status]
3
4return (
5<div className="row">
6<Ref value={item.ref} />
7<Source value={item.source} />
8<Badge tone={tone}>{item.status}</Badge>
9<Owner value={item.owner} />
10</div>
11)
12}
13
14// one row, then the queue maps it
15queue.map(item => <QueueRow ... />)
Live preview
building
INT-4473Needs review
Scanned formOps reviewer
INT-4474Matched
Supplier portalAutomatic
INT-4475Approval pending
Email attachmentTeam lead

One component, then the queue that maps it. The reviewer sees the exception first, because that is the only row that needs them.

Illustrative build session · synthetic component

The case for building

Buy the product when the product fits. Build when it does not.

We sell thirty-two products across seven industries, and we will point you at one of them if it covers your problem, because a product you can run next quarter beats a build you can run next year. This service is for the cases a product does not reach: a process nobody has productised, a regulatory variant that does not exist yet, a system of record with no usable integration path, or a tool that currently lives in a spreadsheet three people email around.

What you are buying

Most builds do not fail on the code. They fail on the seams.

Between vendors. Between the prototype and production. Between the handover and the team left holding it. Here is what we commit to on each one.

One team, one accountability line

No handoff between an AI vendor, a web agency, and an infrastructure contractor, and no argument about whose fault it is when something breaks. The people who design the intelligence are the people who ship the software and keep it running.

We reach the systems others quote around

The twenty-year-old ERP with no API. The machine that speaks its own protocol. The database whose documentation left with the person who wrote it. This is normally the part a proposal excludes from scope, and it is usually the part that matters most.

Built on what you already run

No rip and replace, no new platform to adopt, no migration project hiding inside the build. Your environment decides the stack, not our preference.

Working software throughout, not at the end

You see it running early and keep seeing it, so the scope conversation happens against something real rather than against a document.

Your team can run it without us

Deployed, monitored, documented, and handed over properly. We stay for the operational work if you want us to, and we leave cleanly if you do not. Nothing is engineered to make you dependent.

We will tell you not to buy it

If one of our thirty-two products already covers your problem, scoping says so and the engagement changes shape. A product you can run next quarter beats a build you can run next year.

What we build

01
Product engineering

Product engineering, end to end.

Discovery, architecture, build, deployment, and handover. Not a prototype thrown over a wall for somebody else to productionise.

02
Your environment

Built on what you already run.

Your environment decides how we build, not our preference. If your organisation is standardised on Microsoft, we build there. Nothing gets replaced to suit us.

03
Legacy reach

Integrations into systems that were never meant to be integrated.

ERP, MES, SCADA, CRM, and proprietary systems, including the ones with no usable API and no documentation left.

04
Product extensions

Extensions to any Aelix product.

Shaped to an industry, a region, or a compliance regime, so you keep the product roadmap underneath and still get the variant you need.

05
Policy fit

Workflows configured to your policy, not our default.

Rules, thresholds, and approval flows matched to how your organisation actually decides things.

Architecture and scale

On Monday at nine, the whole month arrives at once.

Software that holds up in a demo and falls over on the first real batch is not finished. We build as separate services so the one under pressure can grow without the rest of the system being dragged along, and shrink again when the batch clears.

Documents arriving

09:00 · the month's invoices land together

05010006:0009:0012:0015:00

Running instances, per service

06:00

Intake API

2 instances

Accepts documents from four sources

Extraction

2 instances

Reads each document and pulls the fields

Matching

2 instances

Checks values against the systems of record

Notifications

1 instance

Tells a person only when one is needed

By early afternoon the batch has cleared and every service is back to its baseline. Capacity follows the work, so the quiet hours do not cost what the peak does.

Runs in your cloud account

Illustrative load profile · synthetic data

Range

We have already shipped at both ends of the range.

Every firm says it can build anything. Almost none can show you where. Each line below is a product you can open right now.

A regulated medical-device floor

Production scheduling on a floor where every decision has to satisfy an auditor, not just a planner.

A national payments network

Connected directly to the rails Indian banking settles on, where a failed call is somebody's money.

Hospital clinical systems

Patient records moving between systems that were never designed to talk to each other, under clinical governance.

Live machinery on a plant floor

Reading equipment directly, in the industrial languages the machines already speak, with no new sensors bolted on.

A construction site, through a camera

Tracking what is actually happening on site where there is no document to read and no system to query.

A team trusted on a hospital floor and a factory floor can handle what sits between them. Whatever your environment is, it is unlikely to be stranger than the ones already on this list.

Work delivered

Real briefs, described exactly as they ran.

Two things are missing below, on purpose. Client names, because naming a client without their written permission is not ours to do. Outcome numbers, because none were given to us to publish, and inventing one is how a case study becomes fiction. What is left is the work itself, which is the part worth reading anyway. See all case studies.

A customs import and export team

In production
The brief
Import and export documents were read and keyed in by hand, and export paperwork was prepared manually. Each document needed careful checking before it could move on.
What we built
Two platforms: one for import documentation and one for export documentation, including the paperwork needed to clear shipments. A chain of AI agents reads and checks each document, people review only the flagged items, and approved data moves on through a process automation layer.
Delivery note
Built on Microsoft Power Apps and Power Automate, because the client already ran a Microsoft-centered environment. Their environment decided the build. Ours would have been the wrong answer.
Read the case study

A management consultancy

Ongoing
The brief
A consultancy that helps people find work, holding millions of candidate records, and without full access to the server those records lived on. Before anything could be built, the estate had to be back in their hands.
What we built
Recovered access to their own infrastructure and migrated the platform onto hosting with a stronger security posture. With the estate stable, we extended their existing Python Django application with the features they had been waiting on.
Delivery note
We did not propose a rewrite. Their codebase was sound, so we worked inside it rather than around it. Taking over software somebody else wrote is ordinary work here, and it is almost always cheaper for the client than starting again.
Read the case study

A branding and design agency

Website development
The brief
Website development for an agency whose own business is craft. A client who sells design judgment for a living sets a higher bar on execution than a brief from outside that world.
What we built
The agency's website, built to their design.
Delivery note
The agency owned the design. We owned the build. We say so plainly, because claiming design credit for a design agency's own work would be the easiest claim on this page for anyone to check.

How an engagement runs

The first phase can end the engagement, and sometimes should.

Scope

We map the process, the systems it touches, and the people who own them. If an Aelix product covers it, we say so here and the engagement changes shape.

Architecture

Integration map, data model, and the decision about which stack fits your environment rather than our preference.

Build

Working software in your hands throughout, with agents carrying the reading and engineers committing the changes.

Handover

Deployed, monitored, and documented, with your team able to run it. We stay for the operational work if you want us to, and leave cleanly if you do not.

Tell us what does not exist yet.

Bring the process, the systems it has to touch, and the constraint that rules out everything off the shelf. We will tell you whether a product covers it, and build it when nothing does.

Scope a build