CASE STUDY
to chatbot, zero code
SiteChat & Estimate256: RAG bots and ML estimation in production
to chatbot, zero code
domain-tuned XGBoost models
Two production systems on one stack: SiteChat, which turns any URL into a grounded chatbot with no code, and Estimate256, which pairs three domain-tuned XGBoost models with a full catalogue, billing and auth layer for ML-grade estimation.
Two problems, one stack: businesses wanted chatbots that knew their websites, and estimators needed ML-grade quotes instead of spreadsheets.
SiteChat crawls a URL, indexes it into a vector store and serves a grounded chatbot — a full FastAPI + React platform enabling zero-code bot creation for any website.
Estimate256 pairs three domain-specific XGBoost models with a complete catalog, billing and auth layer — production ML estimation with managed schema migrations.
What made this hard
Ingestion has to survive real websites
Sites are inconsistent, half-structured and frequently broken. Crawl and extraction quality caps everything downstream, so it is where the work is.
Grounding, not fluency
A chatbot that answers confidently from nothing is worse than one that refuses. Retrieval had to be traceable to source content.
Estimation needs defensible outputs
A quote a user acts on has to be explainable, which rules out approaches that cannot show what drove the number.
Two products, one operational surface
Billing, auth, schema migrations and admin tooling are the same work whichever product is in front — building them once was the point.
How we built it
Crawl and index
A URL becomes a vector index without anyone writing code, which is the whole proposition of the product.
Grounded answering
Responses assembled from retrieved passages with refusal behaviour where the content does not support an answer.
Domain-tuned models
Three XGBoost models for estimation, each trained for a specific domain rather than one general model doing all three badly.
Platform layer
Catalogue, billing, auth and managed schema migrations — the operational surface both products depend on.
The stack
What should you take from this?
- Ingestion quality caps retrieval quality. Time spent on crawl and extraction pays back more than time spent on model selection.
- Refusal behaviour is a feature. A system that declines when the content does not support an answer is more useful than one that always produces something.
- The platform layer — billing, auth, migrations — is unglamorous and consistently underestimated, and it is what makes a prototype into a product.
Frequently asked questions
Can a chatbot be built from a website with no code?
Yes — crawl, index and serve is an automatable pipeline. What varies is ingestion quality, because real websites are inconsistent and that caps how good the answers can be.
Why three models instead of one?
Because a single general model does all three domains adequately and none well. Domain-tuned models are more accurate and easier to explain, which matters when a user acts on the number.
What stops it making things up?
Answers are assembled from retrieved passages, and the system refuses where the content does not support one. That is measurable and defensible; claiming it never happens is not.
Related service: RAG Chatbot Development
Build something at this level
Tell us what you are building. We reply within one business day.