Every IGA program manager has considered it: rather than buying a purpose-built onboarding solution, build the process internally. Use the ICAM engineers you already have. Develop playbooks and templates. Maybe write some scripts to automate the most repetitive parts.
It sounds reasonable. It usually isn’t — but the reasons why take time to surface, which is part of why organizations keep making the same choice.
Cost 1 · Time
The Time Cost Is Underestimated
Building a repeatable internal onboarding process takes longer than most programs expect. Developing templates requires understanding the full range of application types you’ll encounter. Writing playbooks requires encoding expert knowledge in a way that non-experts can follow. Building automation requires engineering time that competes with other program priorities.
Most programs start with good intentions and a reasonable timeline. Six months later, they have a partial playbook, some templates of inconsistent quality, and an onboarding queue that’s still backed up. The process design work never fully finishes because new applications reveal edge cases the original templates didn’t cover.
Meanwhile, the compliance clock is ticking.
Cost 2 · Talent
The Talent Cost Is Hidden
DIY onboarding processes are built on people — the ICAM engineers who develop the playbooks, run the discovery sessions, build the configurations, and validate the outputs. When these people leave — and in today’s market, they leave — the institutional knowledge walks out with them.
The new engineer hired to replace them doesn’t inherit the process. They inherit a collection of documents that don’t fully capture the reasoning behind the decisions. They make do. They develop their own workarounds. Over time, the “process” becomes a loosely coupled collection of individual practices that delivers inconsistent results.
This talent dependency isn’t a people problem. It’s a design problem. Processes that live primarily in people’s heads aren’t sustainable.
Cost 3 · Technical Debt
The Technical Debt Accumulates Silently
Every manually configured SailPoint connector is a configuration that will eventually need to be revisited. When the application changes — when it’s modernized, when a new version ships, when the entitlement model is restructured — someone has to understand the original configuration well enough to update it correctly.
If that configuration was built through an ad hoc process and documented informally, the update is a discovery effort as much as a technical task. The engineer has to reconstruct context that should have been captured the first time. This is technical debt — not in the code sense, but in the process sense. It compounds over time and becomes increasingly expensive to service.
What “Build It Internally” Actually Buys You
After the time investment, the talent dependency, and the technical debt are accounted for, what does DIY actually produce? A process that works inconsistently, degrades over time, can’t scale without proportional headcount increases, and doesn’t generate the documentation federal programs need.
Onboard.id doesn’t have these costs — not because it’s cheaper to build than to buy, but because it’s purpose-built for the problem. The time cost is eliminated by a workflow that works from day one. The talent dependency is broken by a platform that encodes the expertise. The technical debt is contained by structured, documented configurations that are designed to be maintained.
DIY looks free at the start. It rarely is by the end.
Understand the Full Cost Picture
Before you build it internally, see what purpose-built costs
See how Onboard.id avoids the time, talent, and technical-debt costs of DIY — in a 3-minute walkthrough.
Watch the 3-minute demo Request a demo