Bespoke business applications
Custom Software Built Around Your Process
If every product you try expects your organisation to change how it works, software written for your own process may cost you less over its life than the workarounds do. This page explains when that holds, what you would be paying for, and when you would be better off not building anything.
Starting points
Which of These Sounds Like Your Organisation?
Few people approach us asking for software as such. They arrive with a problem that has grown big enough to hurt, and each card below is one we hear in some form. A real project usually involves two or three of them together.
Several copies of the same spreadsheet
When a dozen people keep their own version of a file, nobody can say which figure is right, and every meeting opens by reconciling them. A shared application holds one record, checks entries against rules you set, and shows who changed a value and when.
Approvals that rely on one person remembering
If a request only moves forward because someone chases it, the process stalls whenever that person is away. We put the steps, the people allowed to take each one, and the history of every item into the system, so you can see where anything stands without asking around.
Reports rebuilt by hand every month
Copying figures out of several places into a summary is slow and easy to get wrong. Reports that read straight from the records your staff already work in will always agree with the detail underneath, and the hours spent assembling them come back to you.
Tools that cannot exchange data
You may already pay for sound products that simply do not talk to each other, so someone re-keys orders or customer details between them. A connecting layer moves that data automatically, checks it on arrival, and logs any failure so it gets fixed rather than lost.
An old application nobody wants to touch
Software that still matters but runs on unsupported versions, or was written by someone you can no longer reach, becomes a bigger risk each year. We read the existing code and data before proposing anything, then repair or replace it in steps so your organisation keeps working throughout.
Per-seat fees rising faster than the benefit
Subscription costs that climb with every new member of staff can eventually outweigh what running a system of your own would take. That comparison has to include upkeep as well as the build, which is why we work through it with you instead of assuming the answer.
An honest first question
Should You Build This at All?
Commissioning software means agreeing to look after it for years, not only paying for its first version. These are the questions we would raise in an opening conversation, with the answer that would lead us to advise against a build.
Does an established product already cover it?
Worth building if
The gaps are things your staff genuinely cannot work around, such as a rule the product cannot express or data it will not let you take out.
Better to wait if
The differences are matters of preference. Configuring the product you have will nearly always cost you less than writing your own.
Has the way the work is done settled down?
Worth building if
The process has been stable for a while, so putting it into software fixes in place something your team already trusts.
Better to wait if
It is still changing every few weeks. Code written now would need rewriting soon after, so letting it settle first is the cheaper route.
Is it something every business has to do the same way?
Worth building if
It is your own operating logic, the part that makes your organisation different, which is exactly what bespoke software handles well.
Better to wait if
It is accounting, payroll or statutory returns. Established products follow the rule changes for you, and rebuilding them rarely makes sense.
How many people repeat this task each day?
Worth building if
Many people do the same job over and over, so time saved on each repetition adds up quickly across the team.
Better to wait if
Only one person needs it. A well-organised spreadsheet or a lightly configured off-the-shelf tool may honestly be enough.
Who will look after it once it is live?
Worth building if
Someone on your side, or a support arrangement agreed in writing, will take responsibility for its upkeep from launch onwards.
Better to wait if
Nobody will. Systems without an owner tend to drift out of use within months, and the money spent building them goes with them.
If the answers point away from a build, you will hear that from us early. Talking you out of an unnecessary project costs us one piece of work. Agreeing to it would cost you far more, and you would carry that cost for as long as the software stayed in use.
Before code is written
How Do We Pin Down What You Actually Need?
Most troubled projects go wrong at the very start, when both sides accept the same sentence but picture different software. Each step here is there to catch that while correcting it is still cheap.
- 01
Watch the job being done
We talk to the people who carry out the work each day as well as the person approving the budget. They know the exceptions and the shortcuts, and those are what a design has to survive.
- 02
Map the records and who may change them
We list what the system must store, how those records connect, and which roles can view, edit or approve each one. This is often where two teams find they have been using the same word for different things.
- 03
Choose what the first release must do
We agree the smallest version your staff would find worth using. The software becomes useful early, and later features are shaped by how people actually use it rather than by guesswork.
- 04
Record what is deliberately left out
Exclusions are written down beside inclusions. A written exclusion is a decision you can revisit on purpose, whereas an unspoken assumption tends to resurface later as a disagreement.
You receive the outcome as a short written specification: what the system does, what it keeps, who is allowed to do what, what it will not do, and how it is going to be built. Anything that matters is set down in writing rather than left to a phone call.
Delivery
What Happens Once the Specification Is Agreed?
Every build here moves through the same stages. Each one closes with a document, a working screen or a build you can try, so you can judge progress for yourself instead of relying on our word.
- 01
Questions First
Before anything is estimated, we find out who will use the software, what they do today and what has to be different afterwards. The answers are written up for you to correct, and the estimate is built on that document.
- 02
Working Software, Early
You see real screens in small, regular instalments instead of one large reveal at the end. Each instalment is tested on ordinary devices and slow connections before you are asked to review it.
- 03
After Release
Once it is live you receive the code, the account access and notes that explain how it fits together. We remain available for fixes and for whatever you decide to add next.
Ownership
What Do You Hold When the Build Is Finished?
A system your organisation depends on should not depend on us. Handover is planned from the outset, so another developer could take the work on without having to guess.
Handed to you with the software
- The full source code, in a version-controlled repository you can reach from the first commit
- A description of the data model: the tables, how they relate, and why they are shaped that way
- Notes for setting up the environment and deploying a new release
- A reference for any interface that other systems call
- A record of the decisions that mattered and the reasoning behind each
For software built for you, ownership stays with you unless a written agreement says otherwise. If you would like us to stay involved for corrections, small additions and the updates that keep it supportable, the scope of that is agreed in writing rather than taken for granted.
Registered activity
Why Is Business Software Our Main Line of Work?
The registered business activity of Aarvya Corporation is classified under NIC 58202: “Publishing of operating business and other applications”. Building business applications is therefore what the business is set up to do, and the other services listed on this site sit alongside it.
That is why this page goes into more detail than the others. It does not change our advice: if a product you can buy would serve you better, the questions above still apply and we will say so.
Technology
Which Tools Would Your System Use?
We pick the stack for each project from what the system has to do, where it will run, and who is likely to maintain it later. These are the groups a business application usually draws on.
- On the Server
- Node.js
- PHP
- Laravel
- REST APIs
- Where the Data Lives
- MySQL
- PostgreSQL
- Firebase
- In the Browser
- React
- Next.js
- TypeScript
- JavaScript
- HTML5
- CSS3
- Tailwind CSS
- Hosting and Releases
- AWS
- Google Cloud
- Firebase
- Change History
- Git
Your next move
Is a Process Outgrowing Its Spreadsheet?
Tell us how the work is done today and where it keeps going wrong. You will get a straight view on whether software is the right fix and, if it is, what building it would involve.