Key takeaways
- The deciding question is how much of your permit process is genuinely local, not which option is cheaper to acquire.
- Walk twenty recent applications through and count the steps required by ordinance versus the steps that exist by habit.
- Fee computation is where local variation concentrates, so a configurable fee schedule matters more than flexibility anywhere else.
- Price the second year: a build carries no licence but needs a maintainer, and an unmaintained build is the most expensive option of the three.
- Adopting a system a neighbouring LGU already runs is under-used and frequently the strongest option available.
Executive summary
An LGU digitising business permits and licensing has three options: buy a packaged system, commission a build, or adopt a system a neighbouring LGU already runs. The choice is normally argued on price, which is the least informative of the criteria available.
The question that actually decides it is how much of your permit process is genuinely local. Fee schedules, routing between offices and the ordinances behind them do vary. The shape of an application, a renewal and a status check does not.
The problem
Packaged systems are cheaper to acquire and faster to stand up, and they carry the accumulated fixes of every deployment before yours. Their weakness sits at the edges: a fee formula the product cannot express, a routing step it does not model, an ordinance requiring a field it has no place for.
Commissioned builds fit exactly, and that is also the risk. A system built to today’s process encodes today’s process, including the parts that should have been simplified first. It also concentrates knowledge in whoever built it, which becomes a supportability problem the moment that relationship ends.
The third option — adopting what a neighbouring LGU already runs — is under-used and frequently the strongest. The process is genuinely similar, the fixes are already made, and there is an office nearby that can say what actually happened during their rollout.
Technical discussion
Test how local your process really is
Take twenty recent applications and walk them through. Count the steps that exist because of a local ordinance and the steps that exist because of habit. If most are habit, a packaged system plus process change is the better buy. If most are ordinance, configurability matters more than price does.
Separate the fee engine from everything else
Fee computation is where local variation concentrates, and it is what applicants and auditors complain about when it is wrong. A packaged system exposing a configurable fee schedule can absorb most local variation; one with fees compiled in cannot, and no amount of flexibility elsewhere compensates for it.
Ask what happens at renewal season
Permit systems are load-spiky, and January decides whether the system is judged a success. A packaged product with several LGUs behind it has met that load before. A new build has not, so load testing against a realistic renewal peak belongs in the acceptance criteria rather than in the first live January.
Price the second year, not the first
Licence renewal and support on a packaged system are predictable and recurring. A build carries no licence but needs a maintainer, and an unmaintained build is more expensive than either option — it fails at the least convenient moment, with nobody under contract to fix it.
Consider the middle path
A configurable core with locally built integrations is frequently the right shape: buy the application, renewal, payment and status flow, and build the specific integrations into the treasury, assessor and zoning systems the LGU already runs. That confines custom work to where the local variation actually lives.
Recommendations
Simplify before deciding. The build-versus-buy answer changes once the process is streamlined, and RA 11032 requires that streamlining regardless of which option is chosen.
Visit an LGU already running the option you are considering. One afternoon at a counter during a busy week is worth more than any vendor demonstration.
Whichever you choose, put migration, data export and fee-schedule configuration in the contract. Those three determine whether you can change your mind later at a reasonable cost.
Do not choose a build merely because a package is imperfect. A package fitting eighty per cent, plus process change for the remainder, usually beats a bespoke system that fits perfectly on the day it is delivered and drifts from then on.
Conclusion
Buy when the process is ordinary and the binding constraint is time. Build when the local variation is real, documented and worth preserving. Adopt a neighbour’s system when one exists and works. The expensive mistake is commissioning a build for a process that was never actually unusual.