Custom feature development is a different exercise from building a system. You are not choosing the architecture — you inherited it. Most of the cost and nearly all of the risk comes from that constraint rather than from the feature itself.
Establish the extension point before estimating
The first question is not how hard the feature is. It is whether the system you are extending has a supported way to extend it.
Three broad situations, with very different costs:
- A documented extension mechanism — plugin, webhook, app framework, public API. Cheapest and safest, because upgrades are designed not to break it.
- A surrounding build — leave the system untouched and add a service alongside it that reads and writes through its API. Slightly more work, and it survives vendor updates.
- Modifying the core — editing the product itself. Cheapest to start, most expensive to own, because every future upgrade becomes a merge.
The third option is the one to interrogate hardest. A fork is not a one-off cost; it is a permanent tax on every version bump, paid by whoever is unlucky enough to be there when the vendor ships a breaking change.
The feature is rarely where the work is
Ask what has to be true for the feature to function, and the list is usually longer than the feature:
- Does the data it needs already exist, in the shape it needs?
- Who is allowed to use it, and does the existing permission model express that?
- What happens to records created before it existed?
- Does it need to appear in exports, reports and the audit trail?
- What breaks if it is switched off later?
The backfill question is the one that most often turns a two-week feature into a six-week one. A new required field is trivial going forward and a migration problem for the two hundred thousand rows that predate it.
Match the feature to the system’s assumptions
Every system encodes a model of how the work should be done. A feature that agrees with that model is cheap. A feature that contradicts it is expensive regardless of how simple it sounds.
If the product assumes one owner per record and you need three, you are not adding a field — you are arguing with the schema, and every downstream report, permission check and export will need to be reconsidered.
When you hit this, it is worth stopping to ask whether the requirement is genuinely necessary or whether it is a habit inherited from an older system.
Keep the seam visible
Whatever you add should be identifiable as an addition. Separate namespace, separate configuration, its own tests.
The reason is practical: in two years somebody will need to upgrade the platform, and the first question will be what is custom. If the answer requires archaeology, the upgrade gets deferred, and deferred upgrades are how systems end up stranded on unsupported versions.
Decide who owns it before it ships
A feature added to a vendor product sits in an ownership gap. The vendor did not write it and will not support it. Whoever built it may not be around. Settle in advance who patches it when a dependency has a vulnerability, and where the documentation lives.
When not to build it
Three signals that the feature is the wrong answer:
It exists on the vendor roadmap. Waiting two quarters is usually cheaper than building and then maintaining a parallel implementation you will want to retire.
One person needs it. An export and a spreadsheet may genuinely be the right answer, and it costs nothing to maintain.
It encodes a disagreement. If the feature exists so two teams can keep doing something differently, you are about to make a process problem permanent. Settle it first.
We build features into existing systems as often as we build new ones — and will say when waiting or buying is better. See our custom software development work, or read buy, build, or automate and custom developed software vs off-the-shelf.
Common questions
Can you add features to software we already have?
Usually yes, and the method matters more than the feature. A documented extension point is cheapest and safest, a surrounding service that reads and writes through the API is next, and modifying the product core is cheapest to start and most expensive to own.
Why do small features cost more than expected?
Because the feature is rarely where the work is. Backfilling existing records, fitting the permission model, appearing correctly in exports and audit trails, and agreeing what happens if it is switched off usually exceed the feature itself.
When should we not build a custom feature?
When it is already on the vendor roadmap, when only one person needs it and an export would do, or when it exists so two teams can keep doing something differently. That last one makes a process disagreement permanent.
