How HomeoAI Was Built: Architecture of a Domain-Specific AI Assistant Used by 1,400+ Doctors
Every week, a founder or a domain expert asks us some version of the same question: "Can we build a ChatGPT for our field?" A dental group wants one for treatment protocols. A tax firm wants one for circulars and case law. An Ayurveda practitioner wants one for classical texts.
The honest answer is yes, but not by uploading PDFs to a chatbot. A useful domain AI assistant has to understand specialised vocabulary, find the right passage among thousands of near-identical ones, show where its answer came from, and earn the trust of professionals who will not tolerate a confident wrong answer.
On the Codersarts Podcast, I spoke with Tejesh Vaish, who built HomeoAI on his own. It is an AI assistant for homeopathic practitioners, now used by more than 1,400 doctors across India, Pakistan, Bangladesh, the US, the UK, Canada, Italy and Australia. A homeopathic hospital in Kerala has more than 40 doctors using it every day.
This post breaks down how it was built: the architecture, the retrieval pipeline, the evaluation loop, the hosting cost and the decisions he kept away from AI agents. The domain is homeopathy, but the pattern applies to any profession that runs on reference books, rules and expert judgement.
Watch the full episode
Note: HomeoAI is a reference and decision-support tool. Clinical decisions stay with the practitioner. This article is about the software engineering, not about the efficacy of any treatment system.
Key takeaways
Reuse an open-source chat framework and spend engineering time on domain retrieval.
Use hybrid search: vector search plus BM25 keyword search, with query expansion and re-ranking.
Let domain experts choose the embedding model and chunk size through real-query testing.
Show citations and reasoning in every answer so professionals can verify it.
Run a lean stack: HomeoAI serves 1,400+ users for under ₹10,000 (about US$100–120) a month.
Keep humans in the loop for database migrations and other irreversible changes.
1. The problem: experts searching 15 books and 25-year-old software
The idea came from a personal experience that led Tejesh to sit with homeopathic practitioners in Lucknow and watch how they work.
A homeopathic consultation can run an hour. The practitioner records dozens of symptoms, physical and emotional, and then has to match that profile to a remedy. The core reference is the repertory, which works like a dictionary from symptoms to medicines. The catch is that one symptom can map to a hundred medicines. Narrowing down means cross-referencing the repertory with the materia medica (in-depth profiles of each medicine) and with specific rubrics (precise symptom entries).
The tools practitioners used were desktop applications built 20 to 25 years ago, plus 10 to 15 physical or PDF books. Every case meant manual lookups across all of them.
Tejesh asked the doctors three questions:
Which data sources do you refer to?
What logic do you follow to get from symptoms to a remedy?
What does a good answer look like to you?
Those answers became the product specification.
What it means for your product: Before writing code, sit with the end users and document their manual workflow: the sources, the reasoning steps, and how they judge a good answer. In a domain AI product, that workflow is the system prompt, the retrieval design and the evaluation criteria.
2. Build vs reuse: forking Open WebUI instead of building a chat app
A chat-based AI product needs much more than a model call:
Chat interface with history and search
Voice input and dictation
File attachments
User sign-up, login, Google sign-in
Role-based access control (RBAC) and user groups
Model and persona selection
Persistent memory
Building that from scratch takes months, and none of it solves the doctor's actual problem.
Tejesh forked Open WebUI, an open-source ChatGPT-style interface built with Svelte, FastAPI and Python. Out of the box it gave him chat, voice mode, attachments, workspaces, authentication, RBAC and memory. He customised it into HomeoAI and spent his engineering time on one thing: the custom retrieval tool that finds the right medicines.
He also created multiple personas, one per school of practice (Kent, Boger, Murphy, Hering, a dreams-focused approach, a miasmatic approach, differential diagnosis, a case copilot). Different practitioners follow different methods, so one generic assistant would satisfy nobody.
Check the license before you fork. Since version 0.6.6 (April 2025), Open WebUI deployments with more than 50 users in a 30-day period must keep the Open WebUI name and logo. Removing the branding or white-labeling it for a SaaS product requires an enterprise license. Read the full terms at https://docs.openwebui.com/license/ before you launch.
What it means for your product: Reuse the commodity layer (chat UI, auth, RBAC) and put your budget into the part that makes the product valuable, which is the domain knowledge and retrieval. For most domain AI MVPs, a mature open-source framework saves weeks of engineering.
3. The knowledge pipeline: chunking, embeddings and a vector store
The heart of HomeoAI is a retrieval-augmented generation (RAG) system built on the reference books.
Data collection. Many classical homeopathy texts are publicly available. Tejesh scraped and cleaned them using scripts and AI coding agents. He was prepared to go further: if a source existed only on paper, he planned to scan it and run OCR. The full corpus was a few gigabytes of text.
Chunking. Each book was split into chunks that carry both context and provenance (which book, which section). He experimented with chunk size:
Too small: medicines were missed because related information was split across chunks.
Too large: irrelevant medicines leaked into results.
Final choice: chunks of roughly 4,000, the framework default, worked best for this corpus.
Embedding model: chosen by doctors, not benchmarks
OpenAI small embedding model: Cheap, but doctors said it missed relevant medicines
OpenAI large embedding model: Doctors were happy, but it was expensive
Google Gemini embedding model: Doctors were happy and the cost was acceptable, so this became the final choice
The embeddings are stored in Chroma, an open-source vector database, split across multiple collections.
What it means for your product: Chunk size and embedding model are not set-once decisions. Test them against real expert judgement on real queries. The cheapest embedding model often looks fine in a demo and fails quietly in production.
4. Retrieval: query expansion, hybrid search and re-ranking
When a doctor enters a symptom list (for example: fatigue, weight gain, cold intolerance, dry skin, hair loss, constipation, puffy face, low mood, slow heart rate, muscle pain), HomeoAI does not run a single search. The retrieval service, a separate Python Flask API called as a tool by the model, works in five steps:
Query expansion. The symptom list is rewritten into five or six alternative queries, so different phrasings and interpretations are all covered.
Parallel vector search. Each expanded query is embedded and searched across the Chroma collections in parallel.
Keyword search with BM25. Medical vocabulary is precise. A semantic search can miss an exact term, so a BM25 keyword search runs alongside it.
Merge and de-duplicate. The top five results from vector search and the top five from BM25 are combined and duplicates are removed.
Re-rank. The LLM (GPT-4.1 in production) re-ranks the passages and writes the final answer from them.
Users who complained about speed got a second option: a fast endpoint for quick answers and a deep endpoint for detailed analysis.
HomeoAI architecture at a glance
Browser → Nginx reverse proxy → HomeoAI web app (Open WebUI fork: Svelte + FastAPI + Python)
Web app: persona instructions + attached tools
SQLite: users, chats, notes, models, history
Postgres: doctors' own case practice data
Tool call → Retrieval API (Flask): query expansion (5–6 variants) → Gemini embeddings → parallel search across Chroma collections → BM25 keyword search → merge + de-duplicate → passages + source metadata → LLM (GPT-4.1) → answer
What it means for your product: Plain vector search is rarely enough for professional domains full of exact terms, codes and names. Hybrid search (semantic plus keyword), query expansion and re-ranking are what separate a working domain assistant from a demo.
Have books, SOPs or case data in your field? We'll check whether your data can power a reliable AI assistant, and show you the retrieval quality on your own queries. Talk to us: https://www.codersarts.com/contact
5. Explainable output: show the reasoning, not just the answer
Professionals do not trust a black box. HomeoAI's answer is structured so a doctor can check every step:
Symptom summary card: confirms the assistant understood the case correctly before anything else.
Clinical decision guide: a branching flow. If chills and cold intolerance are prominent, consider these remedies. If not, check for puffy face and weight gain, and so on.
Remedy table: categories, keynote indications, modalities, potencies and a relevance score.
Rubric citations: the exact rows from the reference books that support each suggestion.
Medicine profiles: keynotes, plus what makes symptoms worse or better.
Every answer links back to its source passages, so the doctor can open the tool call and see exactly what was retrieved.
The assistant also improves with use. Through Open WebUI's persistent memory, a doctor can say "for this medicine, weigh these rubrics more" and the assistant applies that rule in future sessions.
What it means for your product: In any expert domain, citations and visible reasoning are a requirement, not a feature. Design the output format with your users so they can verify an answer in seconds. That is what turns a skeptical expert into a daily user.
6. Evaluation: 34 doctors as the golden dataset
Accuracy is the product. A wrong suggestion damages trust immediately, so Tejesh built evaluation into the workflow from the start.
He demoed the tool in person at 10 clinics in Lucknow and gave it away free in exchange for feedback.
34 doctors rated responses with thumbs up or thumbs down during real use.
Those ratings became a golden dataset: real queries with expert judgements attached.
Every change to the core architecture (chunk size, embedding model, retrieval logic, prompt) was run against that dataset.
If the score dropped, the change was reverted. If it improved, it shipped.
This is how the embedding model decision in section 3 was made: not from a leaderboard but from what practitioners accepted.
What it means for your product: Set up your evaluation set before you optimise anything. Even 30 to 50 expert-rated queries give you a regression test for every prompt, model or retrieval change. Without one, every "improvement" is a guess.
7. Production: Docker on EC2 for under ₹10,000 a month
HomeoAI does not run on complex infrastructure.
Hosting: One AWS EC2 instance
Deployment: Docker Compose: front end, back end, databases and Nginx in containers, deployed with one command
App state: SQLite
Case practice data: Postgres
Reference search: Chroma
LLM: GPT-4.1 via API
Monthly cost: About ₹5,000–6,000 for EC2 plus about ₹1,000 in LLM credits, under ₹10,000 total (roughly US$100–120)
A single VM comfortably serves 1,400+ registered users. Scaling can wait until usage requires it.
Security and abuse controls
Trial abuse: spammers created multiple accounts to get repeated free trials. Tejesh added phone number and profile fields and tracked repeat sign-ups from the same IP or number.
LLM spend kill switch: set a hard spending cap on your LLM API account close to your real usage. If a key leaks, through your own code or through a vulnerable dependency, the cap limits the damage. A US$100 cap is safer than a US$10,000 one.
Tenant isolation: one doctor can never access another doctor's patients. Patient data is encrypted before it is stored.
Penetration testing and code audits: especially important as AI-generated code becomes common.
Decisions he never handed to an AI agent
Tejesh uses AI coding agents heavily, but database migrations stay human-in-the-loop. When he added the new user fields, the agent drafted the migration, he reviewed exactly what would change, and only then applied it. A bad migration on live user data is hard or impossible to undo.
What it means for your product: An AI MVP can launch on a lean stack. Cut costs on infrastructure, not on security. Spend caps, tenant isolation, encrypted storage and human review of irreversible changes should all be in place before launch.
Already have an AI assistant that hallucinates, runs slow or costs too much? Codersarts audits RAG apps in production and fixes retrieval, evaluation, security and hosting. Talk to us: https://www.codersarts.com/contact
8. Growth: an AI agent that writes the SEO content
Tejesh does no paid marketing. HomeoAI still gets four to five new doctors every day, including a practitioner in Australia who recently bought a yearly plan.
The landing page was first built with Lovable, then refined with Claude Code and Codex.
A weekly agent workflow compares Google Search Console and SEO tool data against existing content to find keywords that users search for but HomeoAI does not cover yet.
The agent drafts a blog post for each gap, sends it to Tejesh on WhatsApp for review, and publishes it after his approval.
Comparison pages (HomeoAI vs ChatGPT, Gemini, Claude, Perplexity and other tools) capture high-intent searches.
The result: HomeoAI ranks first for its brand searches, ahead of around ten copycat products that appeared after it launched.
What it means for your product: A niche AI product can grow organically when its SEO runs as a system, not a one-off effort. Automate keyword-gap discovery and drafting, but keep a human approval step before publishing.
9. Lessons: the technology wasn't the hard part
Asked what he would tell other builders, Tejesh said the technology was the easier part. The hard parts were:
What to build and for whom. He found a niche most engineers ignore and practitioners who were badly served by their tools.
Winning trust. He demoed in person, gave the product away free and improved it from doctors' feedback.
Evaluation. Proving quality to professionals who will not accept a confident mistake.
Distribution and payments. SEO, pricing and getting doctors to pay.
Patience. The HomeoAI of today is very different from the first version two years ago. In his words, it is a marathon.
He also made a point for anyone tempted by the "just upload your PDFs to ChatGPT" shortcut: try it with your domain's books, and the gap between a general chatbot and an indexed, evaluated, cited domain assistant becomes obvious within a few queries.
How to build a domain-specific AI assistant: step by step
Based on how HomeoAI was built, this is the order we recommend for any profession:
Map the expert workflow. Interview practitioners and write down their sources, reasoning steps and what a good answer looks like.
Collect and clean the knowledge. Gather the books, manuals or case data you have rights to use, and run OCR on anything that exists only on paper.
Reuse the interface. Start from an open-source chat framework for the UI, login and access control instead of building them.
Build the retrieval pipeline. Chunk the data with provenance, test embedding models, and combine vector search with BM25 keyword search.
Design explainable answers. Show a case summary, the reasoning and citations to the exact source passages.
Create a golden dataset. Have experts rate real answers, and test every change against those ratings.
Launch lean and secure. Deploy with Docker on a single server, cap LLM spending, isolate each user's data and encrypt sensitive records.
Grow with content. Publish pages for the keywords your users search for, and keep a human review step before anything goes live.
Domain AI assistant readiness checklist
Problem: Have you documented how experts solve this manually today? Good answer: Sources, reasoning steps and quality criteria written down
Data: Do you have legal access to the reference material? Good answer: Licensed, public-domain or your own data, with a cleaning and OCR plan
Interface: Are you building chat, auth and RBAC from scratch? Good answer: Reusing an open-source framework such as Open WebUI
Chunking: Was chunk size tested on real queries? Good answer: Several sizes compared, the best one chosen with experts
Embeddings: Was the embedding model judged by domain experts? Good answer: Compared on recall and cost against an expert-rated set
Retrieval: Is it vector-only? Good answer: Hybrid vector + BM25, query expansion, re-ranking
Explainability: Can a user verify an answer in seconds? Good answer: Citations, source passages and visible reasoning in every answer
Evaluation: Do you have a golden dataset? Good answer: Expert-rated queries run on every change, with regressions reverted
Security: What happens if your LLM API key leaks? Good answer: Hard spend cap, tenant isolation, encrypted data, pen testing
Operations: Who reviews irreversible changes? Good answer: Human-in-the-loop for migrations and data deletion
Cost: Do you know your monthly run cost per user? Good answer: A lean single-VM start with a clear scaling trigger
Tejesh's advice for founders who aren't engineers was to bring an experienced team in from the start. Security gaps and wrong architecture decisions cost far more to fix after launch than to get right early, and he recommended the Codersarts team for that work.
Build your domain AI assistant with Codersarts
HomeoAI shows that a focused team, or even one builder, can ship a domain AI assistant that professionals rely on daily. The same architecture works for legal research, tax and compliance, dental and veterinary protocols, Ayurveda and traditional medicine texts, engineering standards, insurance policies and internal company SOPs.
Our team has built RAG systems such as a clinical SOP assistant for hospital teams and a self-correcting RAG pipeline with LangGraph, so we know where these projects break and how to fix them.
If you have the domain knowledge (books, manuals, case data, SOPs), Codersarts can help you turn it into a product:
Paid discovery and POC: we map your experts' workflow, review your data and prove retrieval quality on your real queries before a full build.
Domain RAG development: data cleaning and OCR, chunking, embedding selection, hybrid search, re-ranking and cited answers.
Evaluation setup: expert-rated golden datasets and regression testing for every model or prompt change.
Production and security: Docker deployment, tenant isolation, encryption, LLM spend controls and security audits.
Rescue and audit of existing AI apps: if your assistant hallucinates or misses obvious answers, we find out why and fix it.
Talk to us: https://www.codersarts.com/contact
Explore our AI services: https://ai.codersarts.com
About the author
Jitendra Singh is the founder and CEO of Codersarts, which builds AI products, RAG systems and software for startups and enterprises worldwide. He hosts the Codersarts Podcast, where builders share how they ship real products.
Connect on LinkedIn: https://www.linkedin.com/in/jitendra-singh-sofstack/
Connect with Tejesh Vaish
Tejesh Vaish is an IIT Kanpur Computer Science graduate who leads AI engineering at an AI startup in Dubai, where he builds AI agents.
HomeoAI: https://www.homeo-ai.com/
LinkedIn: https://www.linkedin.com/in/tejeshvaish/
Website: https://www.tejeshvaish.com/
FAQ
What is a domain-specific AI assistant?
It is an AI assistant built on a specific profession's knowledge, such as reference books, standards, case records or SOPs, rather than general internet data. It uses retrieval-augmented generation (RAG) to find relevant passages and answers with citations, so experts can verify every answer.
Why not just upload my documents to ChatGPT?
General chatbots are not tuned to your domain's vocabulary, do not use hybrid search across large reference sets, and are not evaluated against your experts' judgement. They often miss exact terms or mix up near-identical entries. A purpose-built assistant indexes the data properly, cites sources and is tested on real queries.
How much data do you need to build a domain AI assistant?
Less than most people expect. RAG does not require training a model. HomeoAI's corpus was a few gigabytes of text from about 10 to 15 reference books. What matters is clean data, good chunking and a strong retrieval pipeline.
How do you reduce hallucinations in a RAG application?
Use hybrid search (vector plus keyword), query expansion and re-ranking. Instruct the model to answer only from retrieved passages and to cite them. Then measure the results against an expert-rated golden dataset and revert any change that lowers the score.
How much does it cost to run a domain AI assistant?
A lean setup can be very affordable. HomeoAI serves 1,400+ registered users on a single AWS EC2 instance for under ₹10,000 a month (roughly US$100–120), including LLM API usage. Costs grow with query volume, model choice and data size.
Should I use RAG or fine-tuning for a domain AI assistant?
For most professional knowledge bases, start with RAG. It answers from your documents with citations, updates when you add new material, and needs no model training. HomeoAI uses RAG over its reference books. Fine-tuning suits teaching a model a style or output format better than keeping facts current and citable.
What is hybrid search in RAG?
Hybrid search runs semantic vector search and keyword search (such as BM25) on the same query and merges the results. Vector search finds passages with similar meaning, while keyword search catches exact terms, names and codes that semantic search can miss. HomeoAI combines the top five results from each before re-ranking.
Can I use Open WebUI for a commercial AI product?
You can build on it, but check the license first. Since version 0.6.6 (April 2025), deployments with more than 50 users in a 30-day period must keep the Open WebUI name and logo, and removing them or white-labeling for SaaS requires an enterprise license. Read the full license at https://docs.openwebui.com/license/.
Which embedding model is best for a domain-specific RAG app?
There is no single best model, so test candidates on your own queries with domain experts. For HomeoAI, OpenAI's small embedding model missed relevant results, the large model worked but cost more, and Google's Gemini embedding model gave doctors the quality they wanted at an acceptable cost.
What is a golden dataset in AI evaluation?
It is a set of real queries paired with expert judgements of good and bad answers. You run every prompt, model or retrieval change against it to see whether quality went up or down. HomeoAI built its golden dataset from thumbs-up and thumbs-down ratings by 34 doctors.
Which industries can use a domain-specific AI assistant?
Any field that relies on large reference material and expert judgement: healthcare and traditional medicine, legal research, tax and compliance, insurance, engineering standards, education, and internal company SOPs and support knowledge bases.
Can Codersarts build a domain AI assistant for my profession or company?
Yes. Codersarts builds domain RAG assistants end to end: data preparation, retrieval design, evaluation, security and deployment. We usually start with a paid discovery or POC on your real data. Contact us at https://www.codersarts.com/contact.
Watch the full conversation with Tejesh on the Codersarts Podcast
Want to be a guest on the Codersarts Podcast? Email jitendra@codersarts.com with your name, role and the topic you'd like to talk about.
Comments