Custom software development for SMEs

Custom software earns its place when the process is genuinely yours, when no product supports a rule you are not allowed to drop, or when the workarounds have quietly grown more expensive than owning the tool would be. Those cases are real and more common than software vendors like to admit. They are also not every case.

So before quoting a build, we compare it with the cheaper answers: configuring something that already exists, connecting two tools you are both already paying for, or changing the process itself. If one of those wins, we will say so. A project neither of us would be proud of costs us more than a smaller invoice does.

When a build does win, the first version covers one job from beginning to end: the screens, the permissions, and what happens when somebody does the wrong thing. Not a platform for the company you might become.

The requirements are rarely in a document. They are in a spreadsheet with three tabs nobody else opens, an email template, a check somebody performs from memory every Friday, and the reason a colleague always sorts the list a particular way. We work from real cases, especially the awkward ones, because the awkward ones are where the rules live.

Anything uncertain gets prototyped while changing it is still cheap. Scope, what has been deferred and how we will know it worked stay written down where everyone can see them. People respond far better to a screen that resembles their work than to a diagram of it, and that response arrives while there is still time to act on it. What we ask for at the start is mostly evidence:

The application is organised around data you would recognise and rules you could explain out loud. Authentication, authorisation, validation and an audit trail go where the risk sits. Spreading them everywhere by reflex buys nothing. Integrations assume the network fails and that the other side will change without telling you. Backups and restores are designed alongside the deployment, not after the system holds something you cannot afford to lose.

We use technology that is boring on purpose (TypeScript, Node.js, React, PostgreSQL) and leave out infrastructure the project has no use for. A small architecture is easier to test, secure, operate and hand over. Performance work goes into the actions people repeat all day and the volumes you can realistically reach, not the ones on a slide. The real test of the result is whether a competent developer who has never met us can pick it up.

An estimate is a probability, not a promise, and the honest version comes with its assumptions attached. What makes software late is rarely the code. It is a data migration that turns out to be far worse than described, an integration whose documentation is fiction, or a decision that needs three people who are never free in the same week.

So the risky parts get looked at first, while there is still room to change the plan, and scope gets cut before quality does. If something is going to slip, you hear it when we know rather than at the deadline. A smaller first release that actually ships is worth more than a complete one that keeps moving.

New software usually replaces something that cannot pause for a launch. Migration, access, training and rollout are planned as one piece of work. Historical data is cleaned and imported into a rehearsal first, then reconciled against the old source: totals, counts and a sample of records people will recognise. Where the risk is higher, a pilot group runs on both systems for a while.

Deployments are repeatable and carry their own configuration for each environment. Automated checks cover the behaviour that matters, and logging makes a production problem diagnosable instead of reproducible only if you are lucky. People get short instructions for the tasks they actually perform, not a manual. For anything critical there is an agreed way back, so that an ordinary release stays an ordinary release.

Once it is in use, behaviour tells you which assumptions were right. Where people abandon a form, what they ask about, which step is slow, where they have gone back to the spreadsheet anyway. That is a better roadmap than a wish list. An option nobody opens can be removed. One shortcut on a task performed forty times a day is worth more than a feature.

The work that keeps it alive gets planned: dependencies, security updates, backups, and the integrations that change underneath you. Documentation covers how the system runs and the decisions you could not infer from the code.

The source code, the data and the infrastructure accounts are yours, arranged that way from the beginning, so there is nothing to negotiate at the end. Anything provider-specific is named while it is still a choice, so the cost of moving is a number you know instead of one you discover.

If another team takes this over one day, what they need is the repository, the deployment process and documentation that explains the decisions. Those exist. Custom software should give you more control over an important process, not trade one lock-in for another.