When is custom software the right call?
When a packaged product falls short, the gap is rarely a missing feature. Rules, records, and authority are not held inside the operation.
· TankDev Mühendislik
Packaged software is designed to fit a common job into a standard shape. If the operation fits that shape, it is the right choice. If it does not, every extra customization makes the product more brittle.
Custom software is built from the opposite direction: the rules, records, and boundaries of the work are defined first. Code comes after that definition. That is why custom software systems are treated as the written form of the operation, not as a product catalogue.
Where a packaged product stops
Custom software becomes relevant when a product cannot carry three things. First, the business rule: approval, exception, permission, and state changes stay with a person or a spreadsheet. Second, the record: the same fact lives in more than one place and the authoritative copy is unclear. Third, the boundary: the system cannot say who may change what, or where data is allowed to go.
- If the rule lives in the screen or with a person, the software is only a form.
- If the same record has two ‘correct’ versions, reports will not reconcile.
- If the exception path is undefined, the process falls back to personal follow-up.
What custom software actually carries
A well-built custom system is distinguished by a clear record model and enforceable rules, not by a feature list. State transitions are held in the service layer. Permission is a system decision, not a hidden button. A change can later be reconstructed by who made it and when.
That definition starts in the same place as the note on business rules remaining with people. If the rule is not in the system, neither automation nor integration can be built on top of it.
When to wait
If the problem cannot yet be stated as a sentence, software is early. ‘We need a panel’ is not a scope. Architecture is not chosen until the authoritative record, the exception rules, and the connection points to existing systems are clear.
Moving a scattered or legacy structure is a separate piece of work. That sits under operational system modernization: records and rules are brought into a central structure while the current operation is kept running.
Custom software is not forcing an operation into more features. It is defining the operation as a system.
To draw that boundary, contact is enough. A short account of how the work runs, where records live, and where it breaks is sufficient to set the technical scope.