Build vs buy: should you write your own support tool?
If you can build it in a weekend, someone on your team has already said it. A form, a table, an inbox view. For a support tool, the weekend estimate is off by roughly two orders of magnitude, and this post is about why, and about when building still makes sense.
The build trap
The trap is that v1 really is easy. A form posts to a table, the team reads the table. It works, everyone moves on.
The cost arrives as a drip, not a bill:
- Someone asks for file attachments, which means storage, quotas and cleanup.
- A second product joins, which means multi tenancy and data isolation.
- A new hire should not see everything, which means roles and permissions.
- "Can we auto close resolved tickets after a week?" Congratulations, you are building a workflow engine.
- The form needs different fields per topic. That is a form builder, one of the most deceptively hard UI projects there is.
Each request is reasonable. Each lands on the same two engineers. Two years in, the homemade tool has a backlog, a bus factor of one, and zero revenue attached to it.
What building really costs
A fair estimate counts four budgets, not one:
- Initial build: the part everyone estimates, and usually the smallest.
- The long tail: email parsing, browser quirks, attachment security, rate limiting, audit trails.
- Maintenance forever: dependencies rot, APIs change, the person who wrote it leaves.
- Opportunity cost: every sprint on the support tool is a sprint not spent on the product customers pay for.
If engineering time is your scarcest resource, the question is rarely "can we build this" but "is this the best thing we could build".
When building makes sense
Build when support IS the product, or when your workflow is genuinely unique:
- You are a support tooling company.
- Your tickets carry domain constraints no generic data model can hold (medical triage, regulated finance flows).
- You operate at a scale where per ticket economics dominate everything else.
For most SaaS and agencies, none of these hold. The workflow feels unique, the data model is not.
The middle path: buy the engine, own the surface
The classic argument for building is brand and control: bought tools look like bought tools. That argument is solved by white label platforms where the customer facing surface is your code.
That is the shape Vicket takes: npx @vicket/create-support scaffolds the support pages into your repository as your components, and the engine, tickets, scoring, workflows, help center, emails, stays managed behind an API. You keep the pixel level control that justified building, without inheriting the backlog.
You can inspect the result on this very site: our help center is the scaffolded surface, restyled.
A decision checklist
Answer honestly:
- Will this tool ever generate revenue?
- Who maintains it in 18 months?
- Does the team prefer building it over the current roadmap, or just over doing support?
- Could a white label platform deliver the same brand experience this quarter?
If the answers lean buy, start with the free plan and keep your sprints for your product. If they lean build, write the workflow engine last. You will thank yourself.