Custom Chatbot for Your Website: Build or Buy
Should you build a custom AI chatbot or buy one? Compare cost, time to launch and upkeep before you commit developer hours to your store.
Buying usually makes more sense than building a custom chatbot for your website when your store needs product advice and buying in chat. Build when you need a workflow that existing tools can’t handle and have engineers to maintain it after launch.
The first working chat window is only part of the project. Live stock, customer permissions and failed payments need their own handling. An inexpensive model doesn’t remove that work.
How to Create a Chatbot for Your Website
To create a chatbot for your website, connect a language model to your catalogue and policies, then give it a storefront widget and controlled store actions. A model generates text. Your application decides which data it can read and which actions it can take.
A practical build has these parts:
- Choose a hosted model or an open model you run yourself.
- Make catalogue search return current products, prices and availability. Retrieve the relevant shipping or refund policy for each question.
- Build the chat widget, conversation history and recovery when a request fails.
- Connect basket actions and checkout. Add customer authentication before exposing private order information.
- Record tool calls, errors and usage. Give staff a way to take over and engineers a way to disable a faulty action.
For planning, allow four to eight developer weeks for a first version with catalogue answers and a basic basket connection. This is an illustrative allowance for an experienced developer, documented store APIs and a limited scope. It isn’t a delivery promise. Payment, returns or several storefronts need separate estimates.
A no-code prototype can answer uploaded policy documents sooner. That prototype hasn’t yet solved changing stock or shopper identity. Define the first release by what a customer can complete, such as finding an available item and adding the right variant to their basket.
AI Agent Builders and AI Agent Platforms
An AI agent builder supplies tools for assembling the conversation, calling services and running the agent. An AI agent platform adds hosting and operational controls. Neither automatically understands your catalogue or your checkout rules.
A visual editor reduces the code needed to connect steps. A developer framework gives your team more control over state, permissions and unusual workflows. Both routes need store connections. A drag-and-drop box labelled “add to cart” still needs a real operation with a valid product variant and safe retries.
| Builder or platform | What it supplies | What your store must connect | How charges accumulate |
|---|---|---|---|
| OpenAI Agent Builder | A visual workflow canvas, preview runs and ChatKit embedding or exported code | Catalogue tools, customer identity and store actions | Model tokens and any billed tools or storage |
| Google’s Vertex AI Agent Builder, now Gemini Enterprise Agent Platform | Managed agent infrastructure and tools for developing and governing agents | Catalogue access, approved data sources and commerce actions | Model usage, runtime compute, memory and other selected services |
| Voiceflow | Hosted voice and chat agents, workflows and conversation monitoring | Store APIs, catalogue data and shopper permissions | Usage-based agency billing or a business quote |
| Botpress | Agent-building tools and customer conversations in a hosted workspace | Store-specific tools and authenticated actions | Conversation allowances, paid plans and extra conversation packs |
| n8n | Visual automation workflows with AI nodes, chat and service connections | A model, store credentials and workflows for each action | Cloud workflow executions, with model usage depending on the setup |
| Microsoft Copilot Studio | Agent authoring and connections through Microsoft’s platform | Store data, action permissions and a website channel | Copilot Credits through capacity or consumption billing |
OpenAI’s documentation places Agent Builder under legacy APIs. For a new custom build, its supported migration path belongs in the technical design. Google’s current platform name also matters when your team follows older Vertex AI tutorials.
Free AI chatbot makers are useful for learning and small prototypes. Botpress’s Free plan includes 100 conversations with no top-ups or overages. Its paid plans use conversation allowances and extra packs. A conversation can contain several messages, so a 100-conversation allowance isn’t a 100-message allowance.
n8n’s Cloud trial includes 1,000 workflow executions. In a chat workflow that runs for each customer message, several executions can belong to one conversation. Its self-hosted Community Edition removes the Cloud subscription, but your hosting and model use still have costs. Voiceflow’s agency entry has a free trial and usage billing. A trial is different from an ongoing free plan.
Once you run several agents, an AI agent management platform helps staff see which version answered a question. Retained versions, answer review and per-agent usage monitoring make a faulty change easier to find. Different brands also need separate catalogue access and credentials, even when they share a model.
Enterprise Chatbots on a Conversational AI Platform
An enterprise chatbot on a conversational AI platform suits a retailer managing several brands, strict internal data rules or an established AI team. The reason to choose it is central control over many deployments.
That route can add enterprise licences and an integration partner to the budget. Your staff still need to own catalogue connections, security decisions and answer quality. Regional deployment, access controls and support commitments become contract requirements instead of assumptions about the model.
A store-level agent is easier to justify when one team needs shopping assistance on one site. A large platform becomes useful when shared governance saves more work than its administration creates.
Building With an Open Source LLM
An open source large language model (LLM) can generate the chatbot’s replies while your application retrieves catalogue data and executes approved actions. Downloadable model weights give you deployment control. They don’t supply a retail search engine or an order system.
For a retail build, shortlist models by the memory you can provide and the actions customers need. These are practical candidates, with different roles:
| Open model | Retail use to evaluate | Deployment consequence |
|---|---|---|
| Mistral Small 4 | Catalogue-grounded conversation, document questions and text or image inputs | Its 119 billion total parameters require substantial memory despite fewer active parameters per token |
| Ministral 3 8B or 14B Instruct | A smaller catalogue assistant or local development prototype | Lower memory demand than large models, with task-specific answer and tool checks still needed |
| Llama 3.2 3B Instruct | Local experiments with retrieval and simple conversation | A compact starting point, not evidence that it can handle every shopping or checkout task |
Mistral publishes Small 4 under Apache 2.0 and describes Ministral 3 models for local and edge use. Meta’s Llama 3.2 model card includes tool-use support and English among its supported languages. The best open source LLM for a store is the smallest model that meets that store’s answer and action requirements at peak traffic.
A GPT chatbot using OpenAI’s hosted models transfers model serving to the provider. An open-model build lets you choose where inference runs and how you change the model. Answer quality depends on the selected model, catalogue retrieval and permitted tools in either route. Neither a hosted brand name nor open weights guarantees accurate refund answers.
Your team owns open-model upgrades and compatibility checks. It also owns the serving configuration and the response when a deployment stops answering. Why AI invents answers explains the model problem in more depth.
Self-Hosted AI: The Fullest Build Route
Self-hosted AI requires computers that can run the model and a team that keeps them available. Production infrastructure can mean GPU servers you own or dedicated cloud instances. Both need patches, monitoring and recovery procedures.
Keeping conversations on your own servers can justify this work when a documented requirement forbids external inference. The entire data path must meet that requirement. Calling a hosted model from your own web server still sends model input outside your infrastructure.
Ministral 3 3B or 8B and Llama 3.2 3B are sensible workstation candidates for testing. Actual memory needs depend on the weight format, context length and number of simultaneous requests. Quantisation reduces model memory by storing weights at lower precision. It can also change answer quality.
A developer workstation rarely makes a sound live service. It can sleep or lose connectivity, and shopper traffic competes with the developer’s own work. Production needs spare capacity and someone on call. Budget for a replacement machine or another instance before relying on one server.
Custom Chatbot Development Costs
Custom chatbot development costs include engineering before launch, model or server use and ongoing maintenance. Compare the whole operating cost with buying, rather than treating the API bill as the project budget.
Here is an illustrative AUD budget, excluding GST. It assumes a developer cost of $1,000 per day and 20 to 40 build days. These are planning inputs, not a quoted Australian market rate.
| Cost item | Calculation | Illustrative AUD cost excluding GST |
|---|---|---|
| First build | 20 to 40 days at $1,000 per day | $20,000 to $40,000 upfront |
| Maintenance allowance | Two developer days per month at $1,000 per day | $2,000 per month |
| GPT-6.1 Sol model use | 1,000 conversations under the token assumptions below | $45 per month |
| Same model at higher volume | 10,000 equivalent conversations | $450 per month |
| Same model at larger volume | 100,000 equivalent conversations | $4,500 per month |
Search storage, hosting and payment-provider charges sit outside this example. Incident work also sits outside the two-day maintenance allowance. A new store API version or a broken catalogue feed can require work without any increase in conversation volume.
At 1,000 conversations, the example’s model bill is much smaller than its maintenance allowance. At 100,000, model selection and repeated context have a larger effect. Compare bought tools through AI chatbot pricing and usage costs when you need subscription structures.
ChatGPT API Cost and Other LLM Costs
ChatGPT API cost is charged through the selected model’s input and output tokens. A token is a unit of text processed by the model. Catalogue snippets and repeated conversation history count as input, as well as the customer’s latest message.
OpenAI’s standard short-context pricing lists GPT-6.1 Sol at US$2 per million input tokens and US$10 per million output tokens. Anthropic lists Claude Sonnet 5.5 at the same base input and output rates. Their smaller options, GPT-6 Luna and Claude Haiku 5.5, list US$0.10 input and US$0.50 output for the applicable short prompts.
For this calculation, assume 10,000 input tokens and 1,000 output tokens across each complete shopper conversation. That makes 10 million input tokens and one million output tokens per 1,000 conversations. Use an illustrative conversion of US$1 to AUD$1.50, excluding GST and currency fees.
| Model | AUD input per million tokens | AUD output per million tokens | AUD per 1,000 example conversations |
|---|---|---|---|
| GPT-6.1 Sol | $3 | $15 | $45 |
| Claude Sonnet 5.5 | $3 | $15 | $45 |
| GPT-6 Luna | $0.15 | $0.75 | $2.25 |
| Claude Haiku 5.5 | $0.15 | $0.75 | $2.25 |
The smaller models’ lower price doesn’t establish equivalent shopping performance. These estimates exclude caching, reasoning beyond the stated output, tool charges and any regional processing surcharge. Claude Haiku’s lower input rate applies to prompts up to 100,000 tokens. OpenAI’s listed short-context rates cover input up to 272,000 tokens.
A rented GPU changes the calculation to instance hours, memory and traffic capacity. In an illustrative rental budget of AUD$2 per hour, 730 hours costs AUD$1,460 before storage or staff. That is AUD$1.46 per conversation at 1,000 conversations, or about AUD$0.15 at 10,000. Both calculations assume the instance can serve that workload. The hourly amount is a budget assumption, not a provider quote.
Owned hardware adds its purchase cost, electricity and replacement capacity. If hardware costs AUD$9,000 and you spread it over 36 months, the hardware allowance is AUD$250 per month. You still pay for operations. Open weights remove a per-token provider charge only when you run inference yourself.
What Buying Gets You
Buying a retail agent gives you an existing shopping workflow and someone else maintaining its software. Compare what customers can complete, along with the tools your staff use to manage it.
shoppa is an AI shopping agent added to your site with two lines of code. Your customers find and compare products, add them to their basket and pay in the chat. They can track orders and start returns there too. Answers use your live catalogue and your own policy documents.
shoppa’s conversational search carries earlier choices forward when a customer asks for a different colour or a lower price. Its workspace includes catalogue import and sync, a private test agent and retained versions. You can publish a change for the next message and roll it back with one click. Conversation traces and shopping analytics help your team inspect the result.
Those are separate jobs your team otherwise has to build. A general agent builder can give engineers control over their own widget and model choice. Buying means working within the supplier’s supported controls and integration contracts. A retailer that needs arbitrary changes to the model-serving layer has a stronger reason to build.
shoppa has per-session and per-token pricing and a free trial. Get a quote for your store’s volume and requirements.
Build vs Buy Software Decisions for Retailers
Build versus buy AI depends on whether your store has the people to own a live AI system. A developer who can produce a chat demo isn’t automatically a team that can maintain shopper permissions and checkout failures.
| Decision factor | Buy a retail agent when | Build when |
|---|---|---|
| Budget | You need to limit upfront engineering and keep staff on the store | You have a funded build plus continuing operations |
| In-house skills | Staff can maintain product data and policies but don’t run model infrastructure | Engineers own integrations, security and AI evaluation |
| Time to launch | A supplier already handles your required shopping flow | Your schedule allows implementation and failure-path testing |
| Unusual requirements | Supported settings and store connections meet the need | A required action or data boundary needs custom behaviour |
| Operational ownership | You want a supplier maintaining the agent software | Your team can recover incidents and support future changes |
Building makes sense for an unusual ordering process, a mandatory self-hosting requirement or a wider platform your AI team already operates. Name a technical owner and provide operations cover before committing to it. Security and retail staff must also own the permissions and policies engineers implement.
For a store needing catalogue discovery and buying in chat, shoppa already handles that workflow. A custom build earns its cost when it solves a requirement that the existing workflow cannot meet.
Risks Unique to a Home-Built Chatbot
A home-built chatbot puts responsibility for wrong answers and failed actions on your own team. Set prices and refund eligibility through trusted store systems. Don’t let a generated answer create a discount or promise a refund.
Treat shopper messages and retrieved documents as untrusted instructions. A customer asking the agent to ignore its rules must not gain access to another customer’s order. Store tools must enforce identity and permissions themselves, even when the model requests a plausible action.
Checkout retries need special handling. If a payment response times out, the agent must establish whether the payment succeeded before attempting it again. Record an action identifier so one customer request can’t create duplicate orders.
Give out-of-hours failures an owner, an alert and a safe fallback to staff or ordinary checkout. The person on call needs a way to stop purchases without taking the whole site down. Use the chatbot testing checklist before launch, with wrong-price questions and failed-action recovery in the same acceptance workflow.