Build vs. buy: in-house appeal queue
Last updated 19 September 2026
Building an in-house appeal system gives you total control. Scritch gets you to working recovery faster, with less surface area to maintain. This page is for engineering and product teams deciding whether to build internal tooling for blocked-user recovery or adopt an external solution. The choice depends on how much custom workflow you need, how fast you want it live, and what you want to own long-term.
| Dimension | Build in-house | Buy (Scritch) |
|---|---|---|
| Time to first recovery | Months (design, build, test, deploy) | Days (integrate SDK, wire hooks) |
| Control over workflow | Total — you own every step | Structured — customize within the recovery pattern |
| Maintenance burden | Yours — every model upgrade, policy change, integration | Ours — updates ship without your team lifting code |
| Cost structure | Engineering time, hosting, model API spend | Usage-based per recovery (as of Sep 2026) |
| Best fit | Highly custom workflows, large eng teams, multi-year horizon | Standard recovery patterns, ship-fast teams, limited eng capacity |
When building in-house wins
- Your workflow is deeply custom. Off-the-shelf recovery doesn’t fit because your appeals involve multiple internal systems, manual review gates, or compliance steps unique to your domain.
- You have the engineering capacity. A dedicated team can design, build, and maintain an appeal system without pulling resources from product work.
- You want total ownership. No external dependency, no usage-based pricing, and full control over every model call and data flow.
- You’re in it for the long term. The internal system will be maintained, improved, and adapted as your product evolves over years.
When buying (Scritch) wins
- You need recovery live this quarter. Building takes months; integrating Scritch takes days. If blocked users are filing tickets now, buying gets you to working recovery faster.
- Your workflow fits the recovery pattern. Rejected imports, expired sessions, refused invoices, failed uploads — if your failures match common B2B support patterns, Scritch handles them out of the box.
- You want to minimize surface area. An external recovery agent means one less internal system to maintain, monitor, and upgrade when models or APIs change.
- Engineering capacity is tight. Your team is shipping product features, not building internal tooling. Offloading recovery lets them stay focused on what only they can build.
Hybrid: start with Scritch, build later if needed
Some teams adopt Scritch to get recovery live fast, then evaluate whether to build in-house once they understand what their appeal workflow actually needs. Starting with Scritch means:
- Blocked users get unstuck now, not after months of internal build time.
- You learn what your recovery workflow actually looks like from real incidents before committing to a custom build.
- If your workflow proves too custom for Scritch, you switch to in-house with a clear picture of what to build. If it fits, you skip the build entirely.
What building in-house actually costs
Beyond the initial build, an internal appeal system needs ongoing work that Scritch handles for you:
- Model upgrades: testing, migrating, and tuning as AI capabilities improve.
- Integration maintenance: keeping connectors to your monitoring, auth, and ticketing systems working.
- Policy updates: adding new tools, adjusting approval rules, refining recovery logic.
- Operator tooling: building the console, evidence trail, and analytics views your support team needs to trust the system.
These aren’t one-time costs. They’re ongoing engineering work that compounds with every new failure type you support. Scritch absorbs that maintenance so your team doesn’t have to.
Next step
If you’re leaning toward buying, start at scritch.xyz and see if your failures fit the pattern. If you’re still evaluating, read how Scritch works to understand what you’d be building versus what you’d get out of the box. For more context, see what user-facing error recovery is.