Insights / Guide / Custom Application Development
GuideCustom application development: the complete guide
Custom software pays off when your process is a source of advantage. How to decide, start small, build security in, integrate cleanly and choose the right channel.
Packaged software covers most of what organisations need: accounting, payroll, email, customer records. But there is usually a part of the business where off-the-shelf products do not fit, because the process is unusual, because it is what sets the company apart, or because stitching several products together has become harder than building one thing that works.
That is where custom applications earn their keep. They also carry real responsibilities: someone must own the roadmap, maintain the code, keep it secure and pay for it for years. This guide brings together our briefings on custom development into one path, from the decision to build through the first release, security, integration, channel choice and long-term care.
Decide whether to build at all
The build-or-buy decision deserves more rigour than it usually gets. Teams often decide on instinct: technical people lean towards building, finance people towards buying. A short, structured comparison produces a better answer and a decision that is easier to defend later.
- Compare fit. Check how much of your need a packaged product meets out of the box. If it covers most of what you need and the rest can wait or be handled by changing the process, buying is usually right.
- Count the lifetime cost. Include maintenance, hosting, security updates and future change, not just the initial build. A custom application is a product you own, with all the upkeep that implies.
- Consider control. Think about who owns the roadmap and the data. With a packaged product, the vendor decides what comes next; with custom software, you do, but you also pay for it.
- Ask whether the process is a source of advantage. Building makes most sense where doing the work your own way is part of why customers choose you.
The middle path
Many good solutions are neither pure build nor pure buy. A packaged core with a small custom application on top, connected through APIs, often gives the best of both: standard features where they suffice and tailored tools where they matter.
Start with a modest first release
The most reliable way to reduce risk in custom development is to release something small, early. A working version used by real people teaches more than months of specification. It shows which features matter, which assumptions were wrong and how people actually use the tool, rather than how they said they would.
- Pick one workflow. Solve a complete job for a small group, such as field engineers recording site visits or a sales team preparing quotes, rather than a little of everything for everyone.
- Release quickly. Aim for weeks, not months, to the first version in real use.
- Measure use. Watch which screens people use, where they get stuck and what they ask for.
- Iterate. Add features based on real use, in short cycles, and resist the long wish list compiled before anyone touched the product.
A modest first release can feel disappointing to stakeholders who expected the full vision. Be clear from the start that the first version is meant to be small and that the roadmap will be shaped by what it teaches. A one-page plan showing the first release and two or three likely next steps helps set that expectation.
Build security in from the start
Security is cheaper to design in than to add later. Retrofitting access controls or encryption into a live application means reworking code, retesting and sometimes migrating data, all while users depend on the system. A few basics, applied from the first line of code, prevent most common problems.
- Authenticate every user, preferably through your existing identity provider with multi-factor sign-in.
- Give each role only the permissions it needs, and check permissions on the server, not just in the interface.
- Encrypt sensitive data in transit and at rest.
- Log access to sensitive records and keep the logs where they cannot be altered.
- Validate every input from users and other systems.
- Keep libraries and frameworks updated and check them for known vulnerabilities.
- Store secrets such as passwords and keys in a managed vault, never in the code.
- Test security before each significant release.
Dependencies deserve particular attention. Modern applications rely on many open-source libraries, each of which may contain vulnerabilities discovered after you adopt it. Automated scanning that flags outdated or vulnerable packages, combined with a routine to update them, removes a large share of risk at little cost.
Design the integration layer
Custom applications rarely stand alone. They read customer data from one system, post transactions to another and feed reports elsewhere. Well-designed APIs let these systems work together without the fragile, point-to-point links that break whenever one system changes.
Design for clarity. Use consistent naming, predictable structures and clear documentation, so that another team, or a partner, can use the interface without asking the original developers. Version carefully: when you change an API, keep the old version running until its users have moved, rather than breaking them overnight. And monitor use, tracking errors, response times and who calls what, so problems are spotted before users report them.
There is a trade-off between speed and structure. A quick direct database connection between two systems may solve today’s problem in a day, but it ties both systems together and is easy to break. A proper API takes longer to build and pays back the first time either system changes.
Choose web, mobile or both
The right channel depends on where and how users work. Getting this wrong is expensive: building a native mobile app for office staff who sit at desks, or a web app for field workers who often have no signal.
Web
A web application reaches all devices with one codebase, updates instantly for everyone and suits office work. Responsive design lets it work reasonably on phones and tablets too. For most internal business applications, web is the sensible default.
Mobile
A native mobile app is best when people need to work offline, use device features such as the camera, barcode scanner or location, or need a fast, focused interface on the move. Field service, warehouse and inspection work often fall into this group.
Both
Where different users work in different settings, share one back end and tailor each interface: a full web application for office staff and a focused mobile app for the field. The shared back end keeps the data and rules consistent, while each interface does its own job well.
Plan for the long life of the software
Custom software is never finished. Business needs change, platforms update and security issues emerge. Budget for ongoing care from the start, typically a team or partner who can fix issues, apply updates and deliver small improvements every month. Document the architecture, the data model and the deployment process so the application does not depend on one developer’s memory.
We treated the first version as the project and the support as an afterthought. The second year taught us that the application is a product, and products need owners.
Head of operations, services client
Done well, custom development gives you software that fits the work, a roadmap you control, and systems that connect cleanly with the rest of your estate. If you are weighing a custom build, a practical first step is to write down the single workflow that would deliver most value if it were solved well, and test it against the four build-or-buy questions above before anyone writes a specification.
Source: Intelliversal analysis, drawing on the briefings in this series.
