Custom application development is usually chosen when off-the-shelf software almost fits, but not quite. That is a sound reason, and also the one that most often produces a system nobody dares touch five years later. The difference lies in what you choose to build yourself and what you let somebody else maintain.
The main points
- Build only what makes you different. Buy or configure everything else.
- An internal application lives for ten years. Choose technology by who you can staff with in five.
- Expect half the work to be integrations with systems you do not own.
- Permissions and roles are harder than they look. Settle them before the data model is fixed.
- Without documentation and tests, the application becomes expensive to change long before it is old.
- Start with the process that hurts most today, not with the most complete solution.
When custom makes sense
Three situations justify building. The process is your competitive advantage and standard software forces you to work like everybody else. Or you are paying licences for fifteen users while using three per cent of the system. Or no vendor covers your combination of requirements and you would end up gluing three systems together anyway.
Conversely: payroll, accounting, email and document management are not things to build. Good products exist, and your version will never be better, only yours.
Build the core only
The most durable architecture we see in practice is a small custom core surrounded by bought parts. The application holds the logic that is genuinely yours and pulls everything else from systems that already exist: identity from your directory, finance from ERP, files from a document store.
That keeps the codebase small enough to be understood, which means a new developer can get productive in days rather than months.
Technology choice is a staffing question
An internal system usually outlives the developers who built it. So the deciding question is not what is best today, but who you can hire or contract in five years, and whether that technology still receives security updates.
Choose ordinary frameworks and avoid exotic dependencies. Boring technology is cheaper to own.
Permissions, roles and audit
Almost every internal application eventually has to answer: who may see what, who changed that record, and why. That is far easier to build into the data model at the start than to add later.
Settle three things before coding: the roles and what each may do, whether anyone needs to see data across departments, and whether you must be able to reconstruct a record’s history. Where the data layer has to carry that, it falls under database development.
How to start without committing
Pick the single process that costs most time today and build only that. Put it in front of the people who do the work, and measure whether it is actually faster. Then expand.
That is the point of MVP development: working out what the application should be while changing your mind is still cheap. If it needs to run on the desktop rather than in a browser, we look at desktop development instead.
How we work
We build business applications as part of our application development services, usually with a dedicated development team so knowledge of the system stays with the same people. Our software development services cover the surrounding areas.
Frequently asked questions
A scoped application covering one process with two integrations typically runs to three to five months of development. Cost is driven by the number of integrations and how many special-case rules the process contains.
Web, unless the application must work offline, talk to local hardware, or handle very large files locally. Then desktop is right.
It depends entirely on what was written down. Require setup instructions, architecture notes and tests from the start. That costs less than buying the knowledge back later.
For forms and workflows, often yes. For an application with its own logic, many users and a long life, you usually hit the platform’s limits, and migrating off is dearer than having built it properly.
So what should you do?
Build only what makes you different, buy the rest, and choose technology by who you can staff with in five years. Start with one process, measure the effect, and expand from there.
Want us to look at your process? Get in touch.
