Build your own support@ bot (n8n, Zapier or Make plus ChatGPT) or buy one: what it costs in hours, and the four things it still won't do

A home-built support@ bot is cheap to start and expensive to keep. The best-known public build report: one founder on Hacker News (June 2026) wrote, "I built an AI support agent in one week," for about "$100 in tokens," with "an hour of maintenance work per week"¹. One hour a week is 52 hours a year. At $150 an hour, that is $7,800. A per-outcome tool at small volume costs about the same: three Intercom seats plus 500 Fin outcomes come to $582 a month at list price⁵⁶. The deciding cost is neither. It is four jobs a DIY bot skips by default.

What does it cost to build your own AI support bot?#

The headline build cost for a DIY support bot is $100. The usable number is the upkeep. The $100 figure comes from one self-report, n=1, by a builder who chose to post about a success¹. That is selection bias in its plainest form: builders whose bots failed rarely post the bill.

The same June 2026 Hacker News thread holds the counter-reports. Another builder called it "months of work." A third replied to the one-week claim: "Have fun sinking 100s of hours into improving and maintaing that"¹. A commenter in a different thread described a whole category of paid email drafters, priced at "$30-50/month," as "prompt engineering + Gmail API + a thin wrapper + embedding for context"³.

Read together, the build-side sample is four comments. The range runs from one week to "100s of hours." No survey of founder-built support bots with a stated denominator exists that we could find. Treat every number in this section as a single observation, not a median.

Why is the model the cheap part?#

The language model is the cheapest line in a support@ bot because the expensive work sits around it. A builder in the June 2026 thread who built in-house listed the hard parts: "(1) coming up with the tools for agents to use, like searching for data, making updates, etc. (2) reviewing the logs of actual usage and adjusting prompts, docs, tools based on the real feedback. (3) tuning human escalation procedures"¹.

The one-week builder said the same thing from the other side: "The hardest part was the knowledge of how to help the customer, which Fin can't do for me anyway"¹. A former support lead in that thread warned that a bot "will fail the second it needs to take action or deliver personalized information based on client's account data"¹.

An October 2025 comment on a vendor launch made the build case: "if you're smart enough to figure out an agent that connects the OpenAI API to the Zendesk API… at what point do you just set it up yourself"². That logic holds for the connection. It does not cover the three hard parts, which are the same whether you build or buy.

The DIY support bot build sheet#

The build sheet below lists the parts of a support@ bot made with Zapier, Make or n8n plus a model API. The middle column records what public reports say. The right-hand columns are blank on purpose: fill them with your own estimate, then check them after 90 days.

Components, public evidence and your own hours (fill in the last two columns)

Component	What it does	Public evidence	Build hours (yours)	Weekly upkeep (yours)
Inbox trigger	Watches support@ and passes each new email on	Standard in no-code workflow tools
Model call and prompt	Drafts or sends a reply	"$100 in tokens" to build, n=11
Knowledge source	Docs, prices, policies the model reads from	"The hardest part was the knowledge"1
Account lookup and actions	Reads plan, invoice, order; makes changes	"coming up with the tools for agents to use"1
Refusal rule	Stops on prices, refunds, policies not in the source	Not in typical tutorials; see below
Handoff with a reply-by time	Sends the thread to a person and tells the customer when	"tuning human escalation procedures"1
Inquiry state and follow-up	Knows which threads are open and nudges them	Not in typical tutorials
Reply log and review	Records what was asked, what source was used, what was sent	"reviewing the logs of actual usage"1
Liability	Who answers for a wrong promise	The business, build or buy (see below)	Write the name of the person who will

Upkeep cost per year = weekly hours × 52 × your hourly rate. At 1, 2 and 4 hours a week and $150 an hour: $7,800, $15,600 and $31,200.

How does the build cost compare with buying, by volume?#

Build cost and buy cost scale on different axes. A per-outcome tool scales with volume. A home-built bot scales with upkeep hours, which depend on how often prices, plans and policies change. The table puts them side by side for a three-seat team.

Buy: Fin "$0.99 per outcome," 50-outcome monthly minimum; Intercom helpdesk seats from $29⁵⁶. Build: upkeep hours are assumptions; token costs at volume were not reported and are excluded. Monthly upkeep = weekly hours × 52 ÷ 12 × $150.

Two findings. First, the crossover depends on upkeep hours, not on volume alone. At one hour a week, building wins above roughly 570 outcomes a month. At four hours, buying wins below about 2,500. Second, the build column hides a tail. The weekly median may be one hour. The expensive week is the one where the bot said something wrong.

What are the four things a DIY support bot still won't do?#

A DIY support bot built from tutorials answers the email in front of it. Four jobs sit outside that loop. Most purchased tools do not do all four either, so use this as a test for both.

1. Refuse what is not in your facts#

A refusal rule stops the bot from stating a price, refund or policy that is not written down. Cursor's support bot showed the failure in April 2025: it told a user the product was "designed to work with one device per subscription as a core security feature." No such policy existed. Users posted cancellations before the company called it "an incorrect response from a front-line AI support bot"⁸. A thread in r/AI_Agents titled "Stop building autonomous email agents" (40+ comments, mid-2026) put the stakes in one line: "one hallucinated refund or commitment at 2am costs you the customer."

2. Hand off with a reply-by time someone owns#

A handoff that only forwards the email is half a handoff. In Gorgias platform data (accounts with 200+ AI-touched tickets, October 2025 to April 2026), 55% of AI-touched tickets went to a human, and about one in three of those never got a human reply⁷. That cohort is e-commerce brands on a paid helpdesk. A Slack ping from a home-built workflow has no owner and no clock unless you add both.

3. Keep state and follow up#

Inquiry state means knowing which threads are open, answered, waiting on the customer or closed. Without it there is no follow-up. Pied Piper's 2026 study of 3,211 home-services inquiries found 72% got no follow-up at all¹⁰. That is a different industry and a human baseline, but it shows where unattended threads end up. A November 2024 Show HN post for an email tool stated its rule as "AI should draft responses but not submit them" (as summarised from the post)⁴. A draft does not follow up either.

4. Keep a record of every reply#

A reply record lists what was asked, which source the answer used, what was sent and from which address. Without it, "reviewing the logs of actual usage" means reading the sent folder¹. With it, a wrong answer can be traced to a stale price line in minutes.

Who is liable when a home-built bot gets it wrong?#

Liability for a bot's answer sits with the business that deployed it, built or bought. In Moffatt v. Air Canada (2024 BCCRT 149), a British Columbia tribunal rejected Air Canada's argument that its chatbot was a separate legal entity and ordered it to pay CAD $812.02⁹. Intercom's AI terms, as quoted by a commenter in the June 2026 thread, say Intercom "makes no representations or warranties and provides no indemnities with respect to Output"¹. We have not read the terms page directly. Not legal advice; check with counsel.

The practical point: buying does not move the risk off your desk by default. What buying can give you is a refusal rule, a handoff and a record you did not have to build. Ask any vendor for those three in writing.

Method, denominators and limits#

The build-vs-buy evidence here rests on a small, self-selected sample. Build-side evidence is four Hacker News comments (one June 2026 thread, plus one each from October 2025 and March 2026)¹²³. Buy-side prices are list prices read on 1 October 2026⁵⁶. Handoff and follow-up rates come from e-commerce and home-services cohorts, not SaaS⁷¹⁰.

Three confounding variables matter most. Builder skill: an engineer who owns the product moves faster than an agency. Inbox mix: a support@ that is mostly how-do-I questions needs fewer tools than one full of billing. Change rate: the more often prices and policies change, the more upkeep hours. What would falsify the main claim: a published sample of home-built support bots, with a stated n, showing median upkeep well under an hour a week after the first year. We have not seen one.

For the billing definitions behind the buy column, see what counts as an AI resolution. For the four controls in more depth, see an AI agent that answers vs one that finishes the job.

Where Valet fits#

Valet is a third option between building and moving to a helpdesk. You forward support@ to a private Valet address; nothing to migrate, and replies go out from your own address once the domain is verified. Valet answers only from your own facts and never invents a price, discount or policy; anything not on the list waits for you. Money, complaints and contracts go to you with one-tap replies, and the customer is told when you will reply. Every inquiry has a state and a next step, follow-ups stop at two by default, and every reply has a Valet receipt with the rule and sources used. To size the problem first, try the free lead check: forward 10 to 20 recent inquiries and see what went unanswered or stopped after one reply.