A basic chatbot demo can be ready as soon as its source material is available. A public launch takes longer because somebody must check the answers, the handoff, the website placement and any required approvals. A custom build adds engineering and deployment work. There is no reliable number of days for either route without a defined scope.
To estimate your date, list each piece of work, its owner, the hours that owner can actually give it, what must finish first and the evidence that marks it done. Add waiting time for reviews and integrations. The last required task to finish determines the launch date. Copy this planning record for each work item:
Work item: Owner: Estimated effort and available hours per day: Cannot start until: External wait or approval: Done when:
The question to ask first is what you mean by "built." A chatbot that answers a sample question in a dashboard is a useful prototype. It is not yet a checked service for visitors.
Pick the milestone you need
| Milestone | Evidence of completion | Work still outside it |
|---|---|---|
| Prototype | A small set of approved sources produces test answers | Public traffic, full question coverage, operations |
| Website pilot | The widget works on the intended pages and a limited audience can reach the right human route | Full rollout and longer-term monitoring |
| Public launch | Owners have accepted the answers, failure cases, handoff, website behavior and response plan | Ongoing review as policies and content change |
A hosted platform can shorten software setup because it supplies the chat interface, source indexing and hosting. It cannot approve your refund policy, clean up conflicting pages or test an external booking system for you. A custom system may be the right choice when your team needs control over the retrieval pipeline, data location or product interface. Put those requirements in the estimate before choosing a route.
Estimate the work, not the platform label
Start with the chatbot requirements checklist. Define one job, what the bot may answer, what it must decline and where a visitor goes when it cannot help. Then estimate these work items for that job:
- Prepare sources. Identify current pages and documents, settle conflicting facts, and assign an owner to each policy. Count the review work, not just upload time.
- Configure or build. On a hosted platform, add sources, instructions and the website widget. On a custom build, include the interface, retrieval, access controls, logging, hosting and deployment work your team must own.
- Connect actions. A link to an existing booking page is a different project from checking live availability and creating a confirmed reservation. Name the exact action and the system that will verify it.
- Test outcomes. Use representative questions, missing-source cases, unsafe requests, handoff requests and mobile website checks. Agree on who can accept a failure or block launch.
- Get approval and publish. Add security, legal, brand or content review when your organization requires them. Record the next available review slot and who can deploy the website change.
Write the first pass with your team rather than borrowing a range from another company's project. The longest dependency chain matters more than the sum of all hours. A content editor can prepare Q&A pairs while a developer adds the widget, but the final answer test must wait for approved content and the deployed configuration.
A worked estimate
This is an illustration, not Agentkit customer data or a typical build time. A support team has one content owner available for three project hours per working day. They estimate six hours to approve source pages, four hours to write missing Q&A answers and five hours to check a fixed question set. Those sequential tasks take 15 working hours, or five working days at that capacity. The website owner can place and check the widget during those days, so that task does not extend the chain. A separate two-working-day approval starts after the answer check. The earliest planned public launch is therefore the end of working day seven, assuming no failed tests or review queue.
If the team says "15 hours is two days," ask whose uninterrupted hours they mean. Capacity and waiting time turn an effort estimate into a calendar estimate. If the answer check finds a wrong policy, add a correction and repeat test before moving the date. Do not quietly treat the first failed run as acceptance.
What a hosted setup can finish quickly
With Agentkit, the current JavaScript widget instructions tell you to open your chatbot's Channels tab, select Chat Widget, copy the generated snippet, place it on your site before the closing body tag and test a message on the live page. The snippet contains your chatbot ID and current script URL. Use the one shown in your dashboard.
That sequence can make a prototype visible quickly when your source content is ready and you can edit the website. Before inviting visitors, ask questions that should be answered, questions that should be refused and questions that should reach a person. Check the actual page on a phone and confirm the next step works. A visible chat bubble alone does not establish that the launch is complete.
If the website is managed by an agency, the deployment date also depends on its change window. If the bot must use a CRM or booking API, ask the integration owner for a tested path and a failure response. Do not promise a real appointment or completed support action merely because the chatbot collected a lead.
What a custom build adds
A custom chatbot needs a work breakdown for the pieces the hosted route already supplies. Include source ingestion, retrieval and answer behavior, the chat interface, authentication where needed, deployment, observability and a way to change or roll back the system. Add each outside system as its own task with test access and an owner. The schedule should state whether the team is building a prototype, an internal pilot or a maintained public service.
Ask a supplier to show deliverables and acceptance tests alongside its dates. "Build an AI chatbot in six weeks" is hard to assess. "Demonstrate answers against 30 approved questions, show the handoff receipt and pass the website checks" is reviewable. The implementation cost guide explains how to budget the labor and ongoing work behind that schedule.
Decide when to launch
Before calling the project done, have an owner confirm these results:
- The chatbot answers a fixed set of real questions from approved sources and identifies questions it cannot answer.
- A person can receive a handoff or lead with the context the process requires.
- The widget works on the intended desktop and mobile pages, with the right chatbot and domain settings.
- Someone owns conversation review, source changes and incident response after launch.
- A reviewer has accepted the open failures or sent them back for repair.
If you need a quick trial, start with one narrow website job and the sources you already trust. Create an Agentkit chatbot, then follow the current widget setup to test it on your site. Set the public launch date only after the answer and handoff checks pass.
