# Custom software in the mid-market: when it makes sense and how it stays maintainable > When building yourself beats the standard, how to avoid dependence on individuals, secure quality, protect source code and rights, and carry the operation long term. URL: https://techport.ai/en/it-beratung/entwickeln-und-beschaffen/individualentwicklung --- 1. [IT Consulting](/en/it-beratung)/ 2. [Build and Buy](/en/it-beratung/entwickeln-und-beschaffen)/ 3. Using custom development well [Build and Buy](/en/it-beratung/entwickeln-und-beschaffen) # Using custom development well By Redaktion techport.ai, IT-Beratung · Last updated on 21 August 2026 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 1. **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. 2. **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. 3. **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. 4. **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. [Arrange an initial call](/en/kontakt)[Our software](/en/loesungen) ## Further reading [Build and BuyGathering requirements properlyHow wish lists become solid requirements: processes as the starting point, prioritisation into must and should, acceptance criteria and a way to handle changes during the project.](/en/it-beratung/entwickeln-und-beschaffen/anforderungsmanagement)[Build and BuyAutomating processes with low-codeWhere automation pays off, how to use low-code sensibly, which rules stop it becoming the next unmaintainable landscape, and how to measure the benefit.](/en/it-beratung/entwickeln-und-beschaffen/low-code-und-automatisierung)[IT Governance and ComplianceLicences and IT contractsCount licences correctly, review contracts on the points that count, prepare for vendor audits, cap price increases and agree an orderly exit.](/en/it-beratung/it-governance-und-recht/lizenzen-und-vertraege)[KnowledgeIT glossaryTerms from IT, software and security, briefly explained.](/en/it-beratung/glossar)[KnowledgeIT metricsDefinitions and formulas read the same way across the company.](/en/it-beratung/kennzahlen) Back to the field [Build and Buy](/en/it-beratung/entwickeln-und-beschaffen) Rt Written by [Redaktion techport.ai](/ueber-uns), IT-Beratung Mehr als 15 Jahre Erfahrung in IT-Projekten des Mittelstands, Auswahl und Einführung von Unternehmenssoftware, Aufbau von IT-Betrieb und Informationssicherheit in wachsenden Organisationen. [More about us](/en/ueber-uns) More from techport.ai [ Software Custom process software for mid-sized companies. ](/en/loesungen)[ HR consulting People processes and the systems behind them. ](/en/hr-beratung)[ IT maturity check Ten minutes to a clear position. ](/en/it-beratung/reifegrad-check)[ HR maturity check 24 statements, a result per field. ](/en/hr-beratung/reifegrad-check)[ Funding BAFA grant plus more than 50 programmes for delivery. ](/en/foerderung)[ Process in practice How workflows become reliable software. ](/en/sop-praxis)[ Data and AI Analysis, forecasts and assistance systems. ](/en/daten-ki)[ About us The people behind techport.ai. ](/en/ueber-uns)