When custom software is justified
Custom software is expensive to build and expensive to keep alive, so the honest starting position is that most businesses should not commission it. If an off-the-shelf product covers eighty percent of what you need at a fraction of the cost, take it and adapt your process.
Custom becomes the right answer in three situations. When your process is genuinely unusual and bending it to fit a product would cost more than the software. When you are paying per-user fees at a scale where ownership is cheaper. And when the data or workflow is the business itself, so depending on someone else product is a strategic risk.
We assess this before quoting a build, and we have told clients to buy a subscription instead more than once. That conversation costs us a project and saves a working relationship.
Requirements before code
The most expensive software mistakes are made before anything is written. A feature built from an assumption costs three times as much to remove as it did to add, and by then people have started relying on it.
So we start by watching the actual process. Who does what, in what order, what they currently work around, where things get stuck, and what the exceptions are. Exceptions matter more than the happy path, because that is where every real system either bends or breaks.
The output is a written specification: screens, user roles, data structures, workflows, and explicitly what is out of scope for the first version. You approve that before development starts, and it becomes the thing we are both measured against.
What we typically build
Most of our software work falls into a small number of recognisable shapes, which is useful because it means the patterns are proven rather than invented for you.
Technology choices, and why boring is better
We choose widely used, well-documented technology rather than whatever is currently fashionable. The reason is practical: in three years you need to be able to hire someone who can work on this, and that is far easier with a mainstream stack.
The same logic applies to architecture. We avoid clever solutions to problems you do not have yet. A system that serves fifty users well and can be extended is better than one designed for a million users that is complicated to change.
Hosting, backups, and monitoring are decided at the start, not after launch. You should know where the system runs, what happens if it fails, and how far back a restore can go.
Getting your existing data in
Migration is routinely underestimated. Real business data is messy: duplicate customers, inconsistent phone formats, dates in three conventions, and fields used for something other than their label.
We treat it as its own piece of work. Extract, examine, clean, map to the new structure, import into a test environment, and have your team verify against records they know before anything goes live. Nothing is deleted from the old system until you have confirmed the new one is correct.
Where the old data is too poor to migrate wholesale, we say so and agree what is worth bringing across rather than importing years of unusable records into a clean system.
Security, roles, and access
Internal systems hold the data that would hurt most if it leaked: customer details, pricing, and commercial history. Security is built in rather than reviewed at the end.
That means role-based permissions so people see only what their job requires, hashed credentials and enforced password strength, encrypted connections, protection against the standard injection and scripting attacks, and an audit trail recording who changed what and when.
Audit trails are worth the small extra effort. Most of the time they answer an innocent question about who edited a record, and occasionally they answer a serious one.
Testing, launch, and training
We test with your people, not only with ourselves. Developers use software the way it was designed; staff use it the way the day demands, and that is where the real defects surface.
Launch is usually staged. A pilot group works in the new system for a period while the old process runs alongside, so nothing critical depends on a system nobody has used under pressure. Once the pilot is stable, the rest of the team moves across.
Training is delivered to the people who will use it, in their language, with the actual data they work with. We also record it, because the person who joins in six months will need it and will not have been in the room.
Cost, timeline, and phasing
Software cost is driven by scope, and scope is the one thing genuinely under your control. We quote a defined first version rather than an open-ended engagement, and we structure later phases as separate decisions you make once the first is delivering value.
A focused internal tool is typically four to eight weeks. A CRM or operations system with several roles and reporting is usually three to five months. Anything quoted much faster than that is either simpler than it sounds or is going to arrive incomplete.
Budget for ongoing costs from the start. Hosting, backups, updates, and small changes are real and continuing. Software that nobody maintains becomes a liability within about two years.
Ownership and not being locked in
You own the software, the source code, and the data, as set out in the agreement. That is not a favour, it is the only arrangement that makes commissioning custom software sensible.
Practically, that means the code lives in a repository you can access, hosting is in your account, and the documentation is written well enough for a different developer to pick it up. We would rather earn the ongoing work by being good at it than by being the only people who understand the system.