Using custom development well
By Redaktion techport.ai, IT-Beratung · Last updated on
Custom software has a poor reputation in the mid-market, and often unfairly. It is the reason why some companies master a process their competitors cannot reproduce. It is also the reason why in other companies a central system depends on exactly one person who documented nothing.
The difference lies not in the decision for or against building yourself, but in what it is used for and under which conditions. For a process that differentiates your business it can be the right choice. For tasks a thousand other companies have in exactly the same form it is almost always the more expensive one.
How you notice it
- A business critical application is maintained by a single person.
- There is no test environment, changes are made in the live system.
- The source code sits with the provider and the contract says nothing about it.
- Nobody knows which libraries are used and whether they are still maintained.
Why this happens
Custom development starts small and for good reason: a standard product does not fit, a small tool solves the problem in two weeks. That tool proves useful, grows, and after a few years is business critical without ever having been given the status of a system. There is no handover, no documentation, no tests and no budget for maintenance, because formally it was never a project. The effort only becomes visible when something stops working or the person leaves.
How we go about it
- Justify the decision. Before any custom development we examine three alternatives: standard software, adapting an existing system, or changing the process. Building yourself is chosen when the process is genuinely differentiating or when no market exists for the requirement, and the reasoning is recorded.
- Define the conditions. We settle in advance what belongs to the result: source code, documentation, automated tests, environments for development and testing, usage and modification rights, handover to third parties, and arrangements for maintenance and further development.
- Limit the dependencies. We ensure that at least two people, or a provider plus one person in house, understand the system, that common technology is used rather than niche solutions, and that the components used are maintained and checked for licence terms.
- Plan for operation. From the outset we budget ongoing effort for updates, security fixes and adjustments, typically a noticeable share of the original development cost per year. Without that item, every custom development is priced too cheaply.
What you gain
- Custom development where it delivers an advantage, rather than everywhere something was missing.
- Systems that can still be developed after a change of personnel.
- Clear rights to the result that hold even in a dispute with the provider.
From our projects
The question of source code is surprisingly often unregulated in existing contracts, or regulated in the provider's favour. As long as the relationship works well that makes no difference. Once it ends, that point decides whether you can keep running the system or have to rebuild it. With existing custom applications we therefore review the contractual position first and the technology second. The second recurring finding concerns open source components: they are almost always in use, rarely inventoried and occasionally years without an update, which is both a security and a licence issue.
Häufige Fragen
Should we hire our own developers or commission a provider?
For a single application a provider usually makes more sense, because one person alone has neither a deputy nor peers. Building your own team pays off when software is part of your product or when you permanently run several applications. In that case you need at least two people, otherwise you have simply moved the dependency problem in house.
How do we ensure a custom application stays maintainable?
Through three things that are written into the contract and checked: automated tests for the central workflows, documentation that enables a third party to continue the work, and regular updates of the components used. Maintainability does not come from good intentions but from commitments that can be verified.
Let us talk about Using custom development well
In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it.
Further reading
Back to the field Build and Buy