Should you vibe-code your own customer service platform?
Published
Read time
9 minutes
Article summary
You can vibe-code a working customer service demo in a weekend, but under the surface sits things like blocking duplicate replies, contact states, routing, email deliverability and AI guardrails that nobody notices until they're missing. The difference shows up on the day you need something new: it's a setting on a real platform, not another build.
One prompt in Claude Code puts a chat widget in the corner of your site. Point it at a language model through the API, feed it your own web pages as content, and it answers customer questions surprisingly well. The same trick works for email. Weekend over, support is live. Or is it?
Getting that far is genuinely easy, so the question was never whether it works. The question is what happens six months from now, when you have eight people answering, a thousand contacts a month, and someone asks why one of them never got a reply.
The difference between that and a real platform comes down to one thing. On a platform, a new requirement is a setting you switch on, and it arrives already wired into everything else. In your own build, every new requirement is another project, and they keep coming.
"I'll only build the parts we need"
The reasoning sounds sensible. A full customer service platform has hundreds of features, you almost certainly don't need all of them, and the ones you do need you could probably build.
The assumption underneath is that those features are separate bricks you can pick from. Take the simplest example there is: a shared inbox. At first all you need is every email landing in one view. Then one day two people answer the same message and the customer gets two different replies, so you need a way to stop people working on the same thing (agent collision detection). Then messages start slipping because nobody owns them, so every contact needs a state and an owner. Then customers complain about slow replies, so you need response time tracking with business hours, holidays and time zones.
Three months in, "I just need an inbox" is a software project, and none of those three additions were on the list when the work started.
Read here what a good customer service platform actually does and how to choose one.
What sits under the surface
The interface is the part AI builds for you in minutes. The rest is invisible logic that nobody notices until it isn't there.
These show up within the first few months:
Stopping two people from replying to the same message at once
Contact states: open, pending, on hold, solved, and the rules between them
Ownership, so every contact has exactly one person responsible
Routing: who gets this one, and on what basis
Response time tracking with business hours, holidays and time zones
Field-level permissions: what the customer sees, what only one team sees
And these only once you actually need them:
An audit trail of who changed what and when, the only way to work out why an automation did what it did
Recognising the same person across three email addresses, a phone number and a chat session
GDPR deletion that anonymises the customer but keeps your statistics intact
Permanently redacting content after an agent pastes a card number into a ticket
Virus scanning and file type limits on attachments
A separate queue for spam and unknown senders
Webhook retries for when the receiving system is briefly down
Two of these are worth opening up, because they catch people out most often.
Email deliverability. Replies have to actually arrive, which means SPF, DKIM and DMARC records on your own domain plus handling for bounces. This is where the whole thing fails silently: if your replies land in the customer's spam folder, nothing in your system tells you. It simply stops working, and you find out because customers stop replying.
Routing. With one person answering, there is nothing to route. With eight people in different time zones who know different things, "who gets this" is no longer a single if statement. Splitting by workload, skill and customer priority is an algorithm of its own, and it has to be changeable without anyone writing code.
These are all internal to the system. The most visible gap is a different one, and it isn't a feature but a consequence: when your system isn't connected to your other systems, the agent becomes the connection. They keep your webshop and your billing tool open in separate tabs, look the same customer up in both, and copy the order number across by hand. None of this shows up in any metric until you look at handling times, and it eats exactly the time you set out to save.
A language model is a commodity
There is one thing worth saying out loud about the AI side. The model is a commodity. The same model is available to everyone through the same API, and it improves on its own regardless of anything you do. The actual system is everything built around it.
You notice this quickly. Retrieval takes an hour to stand up: the AI agent reads your documents, turns them into an answer, and handles the common questions. Then the widget goes public.
A language model will produce an answer that exists nowhere when it needs one: promising a return window you don't offer, or a warranty period that isn't real. At the same time, anyone can type instructions into the chat designed to override the model's own (prompt injection) and get it talking about something other than your service.
Preventing that is a discipline of its own. Guardrails in practice mean answers are constrained to certain topics, checked before they are sent, and anything anomalous ends up somewhere a human will see it. On a platform this layer already exists and is developed continuously. In a homegrown system it is one more project, and its absence surfaces only after a customer has been given the wrong answer and holds you to it.
The next layer is data. It arrives the moment a customer asks about something of their own. Where is my order, can I change the delivery address, I want to return this. None of that comes from documents. It comes from your webshop or your ERP, and some of it has to be written back: a return gets started, an address gets updated. Every one of those connections brings its own questions about how the customer is verified before their data is shown, and what happens when a call fails mid-conversation.
When the AI can't answer, it has to hand over cleanly. A homegrown setup typically fires off an email notification with the chat log attached. The agent opens it and sees nothing else: no earlier contacts, no record that this person called last week about the same thing, none of the order data the AI agent already retrieved. The customer explains everything again, which is precisely the experience the whole system was meant to prevent.
When the AI is a separate piece, reporting also stops at the handover. You can see how many conversations went to a human. You cannot see why, which means you don't know what to teach the AI agent next.
There is one more difference that shows up on the invoice. When your AI runs directly on a model provider's API, you pay per token: the bill follows traffic rather than resolved cases, and there is no ceiling on it. Spam, bots and failed conversations cost the same as successful ones. Pricing, rate limits and how long your chosen model stays available are not yours to decide either, and when a model is retired, the prompting and testing get done again. On a platform, those sit inside an agreed price.
Read here how AI agents are rolled out in Zendesk, step by step.
The difference shows on the day you need something new
Picture the situation six months in. Customers start asking the same things on WhatsApp. Sales wants support tickets visible in their own view. Someone wants to know which topics are eating the most agent time.
On a platform these are settings. You switch the channel on and it lands in the same view, the same routing, the same reporting and within reach of the same AI agent, because those were built on top of each other in the first place. It's an afternoon of work.
In your own system each of those is a project. WhatsApp means a new API, a new message format and new authentication, all of which have to be attached to your existing ticket model. And when Meta changes its terms or Google tightens sender authentication requirements, it breaks on a date you don't get to pick.
This is the cost that falls out of the original estimate. Building isn't a one-off cost, it's a permanent one. Someone at your company is continuously repairing it, and that someone is usually the same person who should be building your actual product.
When a homegrown system is enough
Sometimes it genuinely is. If the need is temporary, contacts arrive a few a day, one person handles them and customers aren't entering anything sensitive, your own widget or a simple email router is a perfectly reasonable answer. It takes a moment to build and you can throw it away when it stops being enough.
The limit arrives from three directions: when more than one person is answering, when customers start entering personal data, or when you need to know why something happened the way it did. Security is worth taking seriously before any of those. Security firm Escape.tech's study of 1,400 vibe-coded applications found 2,038 critical vulnerabilities, over 400 leaked secrets and 175 cases of exposed personal data, including medical records and bank account numbers, all of it in live production applications.
There are also situations where a homegrown system isn't a choice but a starting point. In healthcare, financial services and parts of the public sector, regulation or customer contracts can require that data stays in your own environment or within a specific jurisdiction. Some of that is solved by a platform's own data residency options, but where the requirement is that data never leaves your environment at all, a SaaS platform isn't on the table. In that case every piece of work described in this article has to be done anyway, and the point is simply to know what you're committing to.
When that limit does arrive, the question is no longer whether you can build the parts you need. It's whether you want to build them again every time something changes.
Wondering whether to build or buy?
The right answer depends on how much customer service you actually run, across which channels, and where your development capacity is best spent. Sometimes it's a lightweight homegrown tool, sometimes a platform, and often a combination where the platform handles the foundation and you build what's specific to you on top of it.
Zennius is a certified Zendesk partner, and our team members have been involved in more than a hundred Zendesk AI implementations.
Want to talk through which option fits your situation? Book a free consultation here and we'll go through it together.
