Custom software development

When a custom build is the right call

Most projects reach us the same way. The process already exists; it just lives in five places at once. A spreadsheet holds the master list, a WhatsApp group holds the decisions, an inbox holds the approvals, and the only person who can reconcile them is on leave. Packaged software tends to fail here not for lack of features, but because it assumes a process you do not run.

A custom build earns its cost when the process is the business: when the way you schedule, price, approve or document something is the reason customers stay. It does not earn it when a mature off-the-shelf product already covers the ground and the build would only reproduce it with fewer features. We say so when that is what we see, before anyone signs anything.

What we read before we quote

Discovery is mostly reading your files. We ask for the spreadsheets, the forms you print, the report someone reassembles by hand every month, and the messages where the real decisions get made. Those artefacts describe a working system far more honestly than a requirements meeting does.

Three documents come out of it: the records the system has to hold and how they relate to each other, the actions people take on those records and who is allowed to take them, and an explicit list of what the first phase will not include. The third one is what keeps a project from drifting for six months.

The build, week by week

Step one, the data model and a clickable prototype. Screens and flows get agreed on something you can click through, before code exists. Changing a prototype costs an afternoon; changing a shipped module costs a sprint.

Step two, the first working slice. We pick the single workflow that hurts most and ship it end to end, with real login, real database and real permissions. You use it against real data within weeks, not at the end.

Step three, weekly deliveries. Every week there is a running version on a test environment with your own records loaded into it. Feedback from the people who will actually use the thing goes into the next week, not into a change request queue.

Step four, parallel run and cutover. The new system runs alongside the old way for a period you choose. We migrate the historical data, compare the two, and only then switch off the spreadsheet.

Permissions are a design decision, not a checkbox

ASNPRO carries 22 modules and is used by office staff, field technicians and company owners at the same time. That forced us to treat authorisation as part of the data model rather than a filter applied to screens at the end: who sees which customer, who can change a price, who can only read what they entered themselves.

We bring the same approach to your project. Roles are defined against your org chart during discovery, and every screen and every API endpoint checks them on the server. An interface that merely hides a button is not a permission system.

Living with the systems already in the building

Very little software gets to start on an empty desk. There is an accounting package, an e-invoicing provider, a device that writes a CSV every night, maybe an ERP nobody wants to touch. We map those at the scope stage and decide for each one whether to integrate, import on a schedule, or leave it alone.

Where an API exists we use it. Where it does not, we move files on a schedule and make the failures visible instead of silent. An import that fails and nobody notices is worse than one that never ran.

After go-live

Launch is not the end of the work; it is the point at which the requests become accurate. People who have used the system for a month ask for things nobody could have specified beforehand.

We continue under a maintenance and development agreement: a release plan with the next items in priority order, fixes, and the operational side of backups, upgrades and monitoring. You hold the code and the database throughout, so continuing with us stays a choice rather than a constraint.