The SME build-vs-buy decision that actually matters: authentication and authorization
Published · Updated
Most SMEs treat auth as a solved problem you just outsource. Here is why building custom access control cost us 40 hours upfront but saved 200 hours of integration hell later.
Every SME custom software project hits the same fork: buy an off-the-shelf auth provider or write it yourself. The default advice is to buy. Vendors sell convenience, and developers fear the security risks of rolling their own identity layer. But the real cost of buying is rarely just the monthly subscription fee.
The vendor lock-in tax
Off-the-shelf identity providers charge per active user. For a 500-user internal platform, a standard provider quotes around 2400 euros annually. That seems trivial until you need custom role hierarchies. One client required department-level scoping with cross-functional overrides. The vendor supported groups, but not conditional inheritance.
We spent 60 hours writing middleware to translate the vendor's flat group structure into the hierarchical permissions the application actually needed. Every new feature required updating this translation layer. The subscription saved implementation time initially, but the integration tax compounded with every release.
Where custom auth wins
We rebuilt that platform's authorization from scratch using a basic attribute-based access control model on top of standard libraries. Initial implementation took 40 hours, including session management, password resets, and rate limiting. We used established server-rendered frameworks with built-in CSRF protection rather than innovating on cryptography.
The payoff came during operations. When the client needed a new partner role with read-only access to three specific document types, the change was a 15-line configuration update. No middleware translation, no vendor API limits, no waiting for support tickets. The total operational saving over 18 months was roughly 200 engineering hours.
The security hardening reality
Building auth means owning the security hardening. We allocate a fixed 16 hours per quarter for dependency updates, penetration testing fixes, and access log audits. This is non-negotiable. If your team cannot commit to this operational cadence, do not build custom authentication. The liability of unpatched identity infrastructure outweighs any integration convenience.
Monitoring is equally strict. We track failed login attempts, unusual session durations, and privilege escalation attempts through standard server logs. Alerting thresholds are calibrated from baseline traffic over the first month. A sudden spike in 403 responses triggers an immediate investigation, not a ticket queue.
The decision framework
If your permission model is strictly flat, buy. If you need standard organizational units, buy. But if your business logic requires conditional access rules that differ per resource type, the vendor translation layer will eat your runway. Calculate the cost of that translation layer before comparing subscription fees to build estimates.
For SMEs evaluating this path, map your access control requirements to the vendor's actual data model, not the marketing page. Request a proof of concept for your most complex permission edge case. If it takes more than two days to implement that single rule against the vendor API, the build route is the pragmatic choice.
Build custom authorization when your access rules are domain-specific and change frequently. Buy when your structure is static and conventional. Own the quarterly security maintenance either way. The real cost is never the licence fee; it is the engineering hours spent forcing a generic system to respect your specific constraints.
Working on a project where these methods apply?