Hey Wranglers,
It has never been easier to build a basic version of your own ticketing system, and that's not a compliment.
A capable engineer, an afternoon, and the right prompts and you have a form, a routing rule, and a spreadsheet that actually works. It looks like a solution. For a while, it is one.
The part that comes next is the part nobody talks about when they're pitching the idea to leadership.
Key Takeaways
Building a basic ticketing workflow has never been faster or cheaper. That makes the decision to build feel more obvious than it actually is.
The prototype almost always works. What breaks is everything that comes after: maintenance, documentation, handoffs, and the moment the person who built it moves on.
The companies that try to build first and come to us after are some of our best customers. They arrive knowing exactly what they need because they already defined it themselves.
The question is never whether you can build it. It's whether you can support it indefinitely, hand it off cleanly, and scale it without rebuilding it from scratch.
Real Talk
I've been watching this play out more frequently over the last year or so, and I think it's worth naming directly.
Someone on the team, usually an engineer or a technically-minded ops person, pitches building an internal ticketing solution. The pitch is reasonable:
"We just need intake, basic routing, and a place to track status. We can have something running by end of sprint. AI can help us build it faster. Why are we paying for a tool that does exactly this?"
And they're right, technically. You can build that. It will work.
However, you still need someone to maintain it.
The technology lowered the floor for getting started. It didn't lower the ceiling for what it takes to keep something running.
There was a story going around a while back about a CEO who was vibe coding his way through a project and accidentally deleted his own production database. That's a dramatic version of a quieter thing I see all the time: someone builds a solution that works perfectly for the conditions that existed when they built it, and then the conditions change.
Suddenly, the thing that was working has no owner, no documentation, and a support backlog that's visible to nobody.
What I'm Noticing
The companies that come to us after trying to build their own are some of the most ready customers we work with. They don't need to be convinced the problem is real. They've already proved it themselves.
The things that almost always broke, across every version of this I've seen:
Reporting. The spreadsheet showed what was submitted. It couldn't show what was overdue, what was being handled slowest, or whether workload was distributed evenly across the team. The moment a manager asked those questions, the system didn't have answers.
Accountability. Basic intake is easy to build. Ownership and escalation are not. When a ticket sat for three days with no response, the homegrown system had no way to surface that or route it to someone else automatically.
Handoffs. The engineer who built it understood it completely. Nobody else did. Documentation existed in some form but was usually a Notion page that hadn't been updated in two months.
That last one is the one that ends things most often. It's not a catastrophic failure - just a slow erosion of confidence after the person who knew how it worked wasn't around to fix it anymore.
The Playbook: Build vs. Buy
If you're in a conversation right now about whether to build something internally or use a tool, here are the questions worth asking before you commit:
Can you support this indefinitely without the person who built it? Not in theory. Concretely. If that person left next month, who picks it up? Is the system documented well enough that a new hire could maintain it within their first 60 days? If the honest answer is no, you're not evaluating a solution - you're evaluating a person.
Does it need to work at twice the current volume? Prototypes are built for the conditions that exist when they're built. If your team handles 50 requests a week today and grows to 100, does the system still hold up? Routing rules that work at small scale often break in ways that aren't obvious until they're breaking under real pressure.
What happens when someone asks a question the system can't answer? Basic intake is solvable. Reporting, SLA tracking, escalation logic, and AI deflection are not. If leadership will eventually want to know how long requests are taking and which teams are handling the most volume, plan for that now. It's much harder to add after the fact.
What's the real cost of maintaining it? Not the sprint to build it. The ongoing cost: updates when processes change, debugging when something breaks, training new team members on how it works. Homegrown tools don't have a support team. They have whoever built them.
If you've worked through those questions and building still makes sense, build. There are genuinely scenarios where a simple, custom intake flow is the right answer.
The only mistake is treating "we can build this" as equivalent to "we should build this."
If you've been through this cycle, or you're in the middle of it right now, I'm genuinely curious what the moment was when it became clear the homegrown approach wasn't going to hold.
Reply and let me know.
Thanks for reading.
Adam Smith
CEO & Founder, Wrangle
PS - What's the one thing your team built in-house that you wish you'd just bought?