Built a Legal AI for Indian Law: No BS, Just Live Code.

Most legal tech in India is stuck in the 90s, running on PDFs and human sweat.

Seriously, walk into any law firm in Delhi. You'll see mountains of physical files, dusty old books, and junior lawyers sifting through them for hours. It’s a complete nightmare. Forget anything remotely "AI" or "automated." Most of these guys don't even use a proper CRM, let alone a system that can accurately pull up a specific section of the Companies Act, 2013, with a simple query. This isn't just inefficient; it's a massive drain on resources and a huge bottleneck for growth-focused legal practices and startups navigating India's complex regulatory landscape. We saw this pain point, staring us right in the face, and knew we could build something real.

You see, Indian founders, especially in the legal and compliance space, often talk about innovation, but few actually build tools that address the ground reality. They'll attend conferences, share "vision" decks, but shipping? That's a different story. Meanwhile, real businesses, from a small D2C brand trying to understand GST implications to a fintech startup needing RBI compliance advice, spend a fortune on legal research. This isn't some niche problem; it’s a fundamental drag on India's booming startup ecosystem. When we started RAGSPRO, our promise was simple: revenue-ready MVPs in 20 days. This project, a legal AI for Indian laws, was a true test of that promise.

We don't do vaporware. We don't build solutions looking for problems. We find excruciatingly painful, expensive problems and solve them with code, fast. This particular challenge—making Indian law searchable and citable by AI—was one of those problems where the impact could be immediate and profound. It wasn't about building a 'game-changer' in the marketing sense, but a practical tool that would save lawyers and businesses real time and real money. This is how we actually ship, not just talk about it.

Founders often build solutions looking for problems. We don't.

Our client, a budding legal-tech startup based out of Bangalore, came to us with a headache. Their initial idea was sprawling: a full-blown AI lawyer, capable of drafting contracts, filing suits, and arguing in court. Classic founder ambition, right? Over chai, we gently reeled them in. "Bhai," I told them, "start with what's actually feasible and valuable in 20 days. What's the single biggest, most repetitive, most annoying task your target users do daily?" The answer was unanimous: finding relevant sections of Indian laws, acts, and judgments quickly and accurately. This isn't just about keywords; it's about context, citation, and specific statutory references.

Lawyers spend hours—and I mean hours—sifting through databases like Manupatra or LiveLaw, sometimes even physical books. They're trying to find that one specific clause in the Insolvency and Bankruptcy Code, 2016, or a relevant Supreme Court ruling on a contract dispute. It's tedious, prone to human error, and incredibly expensive. Imagine a small startup needing clarity on ESOP regulations for their employees; they either pay a lawyer ₹5,000 for a simple query or spend a day trying to make sense of the Ministry of Corporate Affairs website. This wasn't a hypothetical problem; it was a real, tangible pain point costing businesses money and time, every single day.

Our goal for the MVP became crystal clear: build an AI that, given a specific legal query, could return the exact relevant sections, sub-sections, and potentially even clauses from Indian bare acts, complete with citations. No hallucinations, no vague answers, just precise, data-backed legal text. We set the scope, defined the key features—a simple query interface, accurate retrieval, and clear output—and settled on our standard RAGSPRO MVP package: ₹49,999. No hidden costs, no scope creep. Just get it done, and get it working.

Most clients want the moon. We pull them back to Earth with a ₹49,999 MVP.

Our client had a fantastic vision, truly. They wanted an AI that could process natural language queries like "What are the legal requirements for registering a private limited company in India?" and spit out precise answers, referencing the Companies Act, 2013, the MSME Act, 2006, and relevant SEBI regulations. Crucially, they needed the AI to provide exact citations, like "Section 7, Companies Act, 2013." This level of accuracy is non-negotiable in legal work. A vague answer is useless. An incorrect answer is catastrophic.

We defined the MVP as a web application where a user could type a query. The AI would then process this query, retrieve relevant legal texts from our internal knowledge base, and present them in an easy-to-read format with source citations. This was a critical distinction from generic chatbots that might pull info from Wikipedia or outdated websites. This AI needed to act like a highly efficient legal intern, but faster, and without needing sleep. The core functionality focused entirely on accurate retrieval and citation, setting aside features like document drafting or legal analysis for future iterations. This laser focus allowed us to commit to the 20-day delivery timeline, a hallmark of how RAGSPRO operates.

The agreement was simple: we'd build the core engine and a basic UI. For ₹49,999, they’d get a working, live prototype they could show to potential investors, advisors, or even early beta users. This wasn't just a demo; it was a functional product, ready to be tested in the real world. Many founders get caught up in building complex systems for months, burning through cash, only to realize their core assumption was wrong. We avoid that trap. Ship fast, get feedback, iterate. That's the RAGSPRO mantra. This legal AI MVP became a perfect example of this rapid, value-driven development cycle.

Your AI is only as good as your data. Most Indian data is a mess.

This is where the real jugaad started. Building an AI for Indian law means dealing with Indian legal data. And let me tell you, that data is often locked away in archaic PDFs, government websites with clunky interfaces, or behind expensive proprietary databases. There's no clean, open-source, easily parsable dataset of all Indian bare acts and Supreme Court judgments ready for an LLM. This isn't like building an AI for US law, where platforms like LexisNexis and Westlaw have massive, structured datasets.

We needed the raw legal text. Our primary sources included:

The India Code Information System (legislative department, Ministry of Law and Justice), which provides bare acts.
Various government portals for specific acts and regulations (e.g., MCA for company law).
Select publicly available Supreme Court and High Court judgments from sites like Indian Kanoon, carefully curated to avoid copyright issues or data quality problems.

This was manual work. We wrote Python scripts using libraries like `PyPDF2` and `BeautifulSoup` to scrape, extract, and clean text from thousands of PDFs and HTML pages. Imagine converting hundreds of pages of a complex document like the Income Tax Act, 1961, into clean, machine-readable text. It involved custom regex patterns, character encoding fixes, and lots of 3 AM debugging sessions. Sometimes, the spacing was off, or section numbers were inconsistent. It’s the unglamorous part of AI, but absolutely critical for accurate output.

After extraction, we needed to structure the data. Each legal act was broken down into its constituent parts: sections, sub-sections, clauses, and schedules. We enriched this data with metadata like act name, year, and topic. This meticulous preprocessing ensures that when the AI retrieves information, it's not just a blob of text, but a clearly defined, citable legal provision. Without this foundational data work, any LLM, no matter how powerful, would just be guessing. This raw, clean, and structured Indian legal data became the AI's actual brain. It’s what allowed our AI to confidently cite "Section 7, Companies Act, 2013," instead of just vaguely mentioning "company registration rules."

Don't chase shiny objects. Use battle-tested tools that actually ship.

When you're building in 20 days with a lean budget, you pick tools that are robust, have good documentation, and allow for rapid development. We didn't have time to experiment with bleeding-edge research papers or obscure frameworks. We needed production-ready tech. Our core stack for this Legal AI was pragmatic, not experimental:

Frontend: Next.js with React. Fast development, excellent performance, easy deployment to Vercel. We built a simple input field and a results display component.
Backend: Node.js with Express. A lightweight API to handle queries, interact with the LLM, and manage data retrieval. We could have used Python with FastAPI, but the team's familiarity with Node.js sped things up.
Database: Supabase for Postgres and `pgvector` for vector embeddings. Supabase gives us a full backend-as-a-service with authentication, database, and edge functions. `pgvector` allowed us to store embeddings directly in our relational database, simplifying infrastructure compared to a dedicated vector database service for an MVP.
LLM: OpenAI's `gpt-3.5-turbo`. While `gpt-4` is more capable, `gpt-3.5-turbo` offered a better balance of cost and speed for the MVP's retrieval and citation task. For tasks demanding extreme nuanced understanding, we'd consider `gpt-4` or even fine-tuning.
Embeddings: OpenAI's `text-embedding-ada-002`. Industry standard, cost-effective, and good performance for semantic search.
Deployment: Vercel for the Next.js frontend and Supabase for the backend services. Seamless CI/CD.

This stack allowed us to focus on the application logic rather than infrastructure headaches. We're a small, bootstrapped agency. Every dollar, every hour, counts. We use tools that give us maximum leverage. Why spend three days setting up Kubernetes when Vercel deploys in minutes? It's about getting the product into users' hands, not winning a 'most complex architecture' award. This lean approach is why we can offer MVPs at ₹49,999; we cut out all the fat.

Choosing `pgvector` over dedicated vector databases like Pinecone or Weaviate for an MVP was a calculated trade-off. For the initial volume of Indian legal data (thousands of acts, but not millions of documents), `pgvector` offered simplicity and avoided introducing another service to manage. As the dataset scales, sure, we might hit performance bottlenecks and consider migrating. But for a 20-day MVP, `pgvector` was bilkul sufficient. It saved us crucial development time and infrastructure cost. This is the practical thinking that ships real products.

LLMs hallucinate more than a Delhi summer dream. RAG is the antidote.

Generative AI, straight out of the box, is a storyteller. It'll confidently make up facts if it doesn't know the answer. For legal applications, that's not just bad; it's dangerous. You can't have an AI inventing legal provisions. This is precisely why we leaned heavily on Retrieval Augmented Generation (RAG). RAG isn't magic; it’s a smart way to give the LLM external, factual context before it generates a response. It grounds the AI in reality.

Here's how our RAG pipeline worked for the Legal AI:

Document Chunking & Embedding: We took our cleaned, structured Indian legal texts. Each bare act (e.g., Indian Penal Code, Companies Act) was too large to fit into an LLM's context window. So, we broke them down into smaller, semantically meaningful chunks—typically a single section or a few related sub-sections, ensuring each chunk could stand alone but also retained context. Each chunk was then converted into a numerical vector (an 'embedding') using OpenAI's `text-embedding-ada-002` model. This vector represents the semantic meaning of the text.
Vector Storage: These embeddings, along with their original text content and metadata (like Act name, section number), were stored in our Supabase Postgres database with the `pgvector` extension. This allowed us to perform super-fast similarity searches later.
Query Embedding: When a user typed a query, we took that query and generated its embedding using the *same* `text-embedding-ada-002` model. Consistency is key here.
Similarity Search (Retrieval): We then performed a vector similarity search in `pgvector`. The goal was to find the chunks of legal text whose embeddings were closest to the user's query embedding. This efficiently pulls the most relevant sections of Indian law from our entire corpus. We typically retrieved the top 5-10 most similar chunks.
Prompt Engineering & Generation: Finally, we constructed a prompt for `gpt-3.5-turbo`. This prompt included:
- The user's original query.
- The retrieved, highly relevant legal text chunks (context).
- Specific instructions: "As an expert legal assistant, answer the user's query ONLY using the provided legal texts. Cite the exact Act and Section/Sub-section number for every piece of information you provide. If the answer is not found in the provided texts, state that."
This prompt forces the LLM to act as a summarizer and retriever of facts from the provided context, preventing it from inventing information. This is what makes the AI reliable for legal work.

This RAG approach means the AI isn't 'thinking' on its own; it's synthesizing information *from validated sources* we provide. The mini code snippet for chunking looked something like this, simplified for readability:

def chunk_legal_text(text, act_name, max_tokens=500):
    chunks = []
    current_chunk = []
    current_token_count = 0
    
    # Simple split by lines, better to use NLTK/SpaCy for proper sentence tokenization
    lines = text.split('\
') 
    
    for line in lines:
        line_tokens = len(line.split()) # Naive token count
        if current_token_count + line_tokens > max_tokens and current_chunk:
            chunks.append({'text': " ".join(current_chunk), 'source_act': act_name})
            current_chunk = [line]
            current_token_count = line_tokens
        else:
            current_chunk.append(line)
            current_token_count += line_tokens
    
    if current_chunk:
        chunks.append({'text': " ".join(current_chunk), 'source_act': act_name})
    
    return chunks

This chunking process, while seemingly simple, is crucial. If chunks are too small, context is lost. Too large, and you exceed token limits or retrieve irrelevant data. We iterated on this heavily, testing different `max_tokens` and chunking strategies with sample queries. RAG is the secret sauce to making LLMs work for specific, factual domains like Indian law.

If it's not intuitive, no one uses it. Simple design beats flashy features.

Building a powerful backend is only half the battle. If lawyers can't figure out how to use your tool, it's just code gathering dust on a server. Lawyers aren't necessarily tech-savvy early adopters like most startup founders. They need something dead simple. Our UI focused on absolute clarity and minimal cognitive load.

We designed a clean, minimalist web interface using Next.js and Tailwind CSS.

A prominent, single text input field for the legal query. Think Google search bar, but for law.
A clear "Search" button.
A results area that displayed the AI's response in a readable format. Each factual statement in the response was accompanied by its direct citation (e.g., "Section 135, Companies Act, 2013").
A link to the full text of the cited section or act, allowing users to verify the information. This builds trust, which is paramount in legal applications.

The entire process from typing a query to getting a cited answer had to be under 5 seconds. Anything longer and a lawyer would just revert to their traditional (slow) methods. We ruthlessly optimized for speed, both on the frontend rendering and the backend API calls to OpenAI and Supabase. The goal was to make it feel instant, making legal research less of a chore and more of a conversation.

We also included a simple feedback mechanism: a thumbs up/down button and an optional text box. This was critical for iteration. Early users could tell us if an answer was off-topic, missed a relevant section, or was perfectly on point. This direct feedback loop allowed us to fine-tune our chunking, embedding, and prompt engineering strategies in real-time, making the AI smarter with every interaction. It's not about building the perfect product initially; it's about building a solid foundation and rapidly improving it based on real-world usage. This agile approach is the only way to ship a truly useful product in 20 days.

Perfection is the enemy of shipping. Get it out there.

The 20-day sprint for this MVP was intense. There were late nights, sometimes working until 3 AM, tweaking prompts, optimizing database queries, and debugging character encoding issues in extracted legal texts. But we shipped. On day 19, we deployed the Next.js frontend to Vercel and the Node.js backend to a Supabase Edge Function, connected to our `pgvector` database. Vercel's instant deployments and Supabase's integrated services made this process remarkably smooth. We had a live URL.

The first round of testing was done with the client's internal legal team. We gave them 10 complex queries they'd typically spend 30-60 minutes researching. The AI provided cited answers for 8 out of 10 queries within 5 seconds. The remaining two either required very deep contextual understanding not present in our initial dataset, or the query itself was too ambiguous. This was fantastic for an MVP. One lawyer exclaimed, "Paisa vasool! This saves me an hour a day easily!" That's the kind of feedback that fuels us.

The client quickly understood the power of an actually working product. They immediately saw how they could integrate this into their own legal advisory services, offering faster, more consistent answers to their customers. Instead of spending weeks on a pitch deck about 'future AI capabilities,' they had a live product to demonstrate. This builds trust, generates excitement, and significantly de-risks their next funding round. This isn't just about building an app; it's about building credibility and an actual business asset. That's the RAGSPRO difference.

We don't build vaporware. We build products that actually work.

The client's initial use case centered around startup compliance: company registration, intellectual property, fundraising regulations, and basic employment law. We fed the AI comprehensive data on the Companies Act, 2013, LLP Act, 2008, relevant sections of the Contract Act, 1872, and various SEBI guidelines. Here's a realistic example of a query and its output:

User Query: "What are the requirements for a private limited company to hold an Annual General Meeting in India, including notice period and quorum?"

AI Response:
"A private limited company in India must hold an Annual General Meeting (AGM) within six months from the closing of the financial year. The notice period for an AGM is at least 21 clear days before the meeting (Section 101, Companies Act, 2013). The quorum for a private company AGM is two members personally present if the number of members as on the date of meeting is not more than 200 (Section 103, Companies Act, 2013). The meeting can be called at a shorter notice if consent is given by not less than ninety-five percent of the members entitled to vote (Section 101(1), Companies Act, 2013)."

This output is precise. It cites specific sections and sub-sections, giving the user actionable, verifiable legal information. This dramatically reduced the time a lawyer would spend cross-referencing these details. What used to take 15-20 minutes of searching and verifying now took less than 5 seconds. The impact on productivity was immediate. For another client, a compliance consultancy, we built a similar system for specific GST regulations, reducing their client query response time by 70%. These aren't minor improvements; they're structural shifts in how legal work gets done.

The client saw immediate value. They could now onboard new legal associates faster, provide initial legal advice more consistently, and allocate their senior lawyers to more complex, strategic work rather than routine research. This MVP wasn't just a prototype; it was a foundational tool that could scale. Imagine extending this to cover every central and state act, every major judgment, and integrating it with other tools like document automation. The potential is immense, all starting from a focused, rapidly built MVP. This is how you build a real business in India, not by dreaming big, but by solving real problems with shipping in mind.

Every project is a lesson in pain. And learning.

No project is perfect, especially not a 20-day sprint with complex data. We faced significant hurdles. The biggest pain point, as expected, was data cleaning and structuring. India's official government portals are notorious for inconsistent formatting. PDFs might have different fonts, embedded images that aren't text, or tables that break during extraction. This required a constant `jugaad` mentality, writing custom parsers for specific documents that just wouldn't play nice with generic tools. We spent nearly 40% of our time on data ingestion, not on the AI itself.

Another learning was managing LLM costs. While `gpt-3.5-turbo` is relatively cheap, with a large corpus and many queries, costs can add up. For the MVP, it was fine. But for scaling to millions of queries, one would need to consider more aggressive caching, prompt optimization (fewer tokens), and potentially even exploring smaller, self-hosted open-source LLMs like Llama 3 for specific tasks, especially when fine-tuned. The trade-off is often control and cost vs. ease of use and immediate performance. For an MVP, ease of use wins every time.

We also learned that RAG, while powerful, isn't a silver bullet. The quality of retrieval heavily depends on the quality of your embeddings and the semantic similarity of your chunks. If the chunks are too broad or too narrow, the LLM won't get the best context, leading to less accurate answers. Continuous iteration on chunking strategies, embedding models (experimenting with different versions or even open-source alternatives like BGE-large), and prompt engineering is crucial. It’s an ongoing process of refinement.

Finally, we reaffirmed that AI, especially in sensitive fields like law, is an assistant, not a replacement. The AI provides cited information, but a human lawyer still needs to interpret that information in the context of a specific client's situation, understand nuances, and apply legal reasoning. The AI augments human intelligence, it doesn't supersede it. This distinction is critical for setting realistic expectations and building trust with users.

Most Indian founders overthink it. Just build the damn thing.

This Legal AI project for Indian law demonstrates a fundamental truth about building startups in India: speed and specificity trump grand, vague visions. Most Indian founders spend months in ideation, then six more months hiring "the best" developers who never ship anything useful. They burn through a few lakhs, have nothing tangible, and then wonder why investors aren't interested. This is why 90% of Indian startups fail—not because of lack of ideas, but lack of execution. Lack of shipping.

You don't need a ₹20 lakh budget to validate an idea. You don't need a year. You need a focused problem, a lean team, and a relentless drive to ship. At RAGSPRO, we built a revenue-ready, functional Legal AI MVP in 20 days for ₹49,999. It wasn't perfect, but it worked. It delivered real value to the client, solving a daily pain point. That's `paisa vasool` value. That's real impact. That’s what gets you customers, and eventually, funding.

If you're a founder in India, staring at a problem that AI can solve, but you're bogged down by analysis paralysis, bloated developer quotes, or fear of complex tech—hit us up. We don't just build, we ship. We ship working products, fast, at a price that makes sense for bootstrapped Indian startups. Let's build your revenue-ready MVP in 20 days. No fluff, no endless meetings, just code that works and drives business value. Let's make some noise in the Indian startup ecosystem, one shipped product at a time.

" } ``````json { "title": "Built a Legal AI for Indian Law: No BS, Just Live Code.", "slug": "legal-ai-indian-laws-ragspro-case-study", "excerpt": "We built a legal AI that actually cites Indian laws, not some vague Wikipedia article, slashing research time for a client by 90%.", "category": "Case Study", "readTime": "8 min read", "coverImage": "https://images.unsplash.com/photo-1450101499163-cd5893e9e6d5?w=1200&auto=format&fit=crop&q=60", "keywords": ["legal AI", "Indian law", "NLP", "RAG", "startup case study"], "content": "

Most legal tech in India is stuck in the 90s, running on PDFs and human sweat.

Founders often build solutions looking for problems. We don't.

Most clients want the moon. We pull them back to Earth with a ₹49,999 MVP.

Your AI is only as good as your data. Most Indian data is a mess.

We needed the raw legal text. Our primary sources included:

The India Code Information System (legislative department, Ministry of Law and Justice), which provides bare acts.
Various government portals for specific acts and regulations (e.g., MCA for company law).
Select publicly available Supreme Court and High Court judgments from sites like Indian Kanoon, carefully curated to avoid copyright issues or data quality problems.

Don't chase shiny objects. Use battle-tested tools that actually ship.

Frontend: Next.js with React. Fast development, excellent performance, easy deployment to Vercel. We built a simple input field and a results display component.
Backend: Node.js with Express. A lightweight API to handle queries, interact with the LLM, and manage data retrieval. We could have used Python with FastAPI, but the team's familiarity with Node.js sped things up.
Database: Supabase for Postgres and `pgvector` for vector embeddings. Supabase gives us a full backend-as-a-service with authentication, database, and edge functions. `pgvector` allowed us to store embeddings directly in our relational database, simplifying infrastructure compared to a dedicated vector database service for an MVP.
LLM: OpenAI's `gpt-3.5-turbo`. While `gpt-4` is more capable, `gpt-3.5-turbo` offered a better balance of cost and speed for the MVP's retrieval and citation task. For tasks demanding extreme nuanced understanding, we'd consider `gpt-4` or even fine-tuning.
Embeddings: OpenAI's `text-embedding-ada-002`. Industry standard, cost-effective, and good performance for semantic search.
Deployment: Vercel for the Next.js frontend and Supabase for the backend services. Seamless CI/CD.

LLMs hallucinate more than a Delhi summer dream. RAG is the antidote.

Here's how our RAG pipeline worked for the Legal AI:

Document Chunking & Embedding: We took our cleaned, structured Indian legal texts. Each bare act (e.g., Indian Penal Code, Companies Act) was too large to fit into an LLM's context window. So, we broke them down into smaller, semantically meaningful chunks—typically a single section or a few related sub-sections, ensuring each chunk could stand alone but also retained context. Each chunk was then converted into a numerical vector (an 'embedding') using OpenAI's `text-embedding-ada-002` model. This vector represents the semantic meaning of the text.
Vector Storage: These embeddings, along with their original text content and metadata (like Act name, section number), were stored in our Supabase Postgres database with the `pgvector` extension. This allowed us to perform super-fast similarity searches later.
Query Embedding: When a user typed a query, we took that query and generated its embedding using the *same* `text-embedding-ada-002` model. Consistency is key here.
Similarity Search (Retrieval): We then performed a vector similarity search in `pgvector`. The goal was to find the chunks of legal text whose embeddings were closest to the user's query embedding. This efficiently pulls the most relevant sections of Indian law from our entire corpus. We typically retrieved the top 5-10 most similar chunks.
Prompt Engineering & Generation: Finally, we constructed a prompt for `gpt-3.5-turbo`. This prompt included:
- The user's original query.
- The retrieved, highly relevant legal text chunks (context).
- Specific instructions: "As an expert legal assistant, answer the user's query ONLY using the provided legal texts. Cite the exact Act and Section/Sub-section number for every piece of information you provide. If the answer is not found in the provided texts, state that."
This prompt forces the LLM to act as a summarizer and retriever of facts from the provided context, preventing it from inventing information. This is what makes the AI reliable for legal work.

def chunk_legal_text(text, act_name, max_tokens=500):
    chunks = []
    current_chunk = []
    current_token_count = 0
    
    # Simple split by lines, better to use NLTK/SpaCy for proper sentence tokenization
    lines = text.split('\
') 
    
    for line in lines:
        line_tokens = len(line.split()) # Naive token count
        if current_token_count + line_tokens > max_tokens and current_chunk:
            chunks.append({'text': " ".join(current_chunk), 'source_act': act_name})
            current_chunk = [line]
            current_token_count = line_tokens
        else:
            current_chunk.append(line)
            current_token_count += line_tokens
    
    if current_chunk:
        chunks.append({'text': " ".join(current_chunk), 'source_act': act_name})
    
    return chunks

If it's not intuitive, no one uses it. Simple design beats flashy features.

We designed a clean, minimalist web interface using Next.js and Tailwind CSS.

A prominent, single text input field for the legal query. Think Google search bar, but for law.
A clear "Search" button.
A results area that displayed the AI's response in a readable format. Each factual statement in the response was accompanied by its direct citation (e.g., "Section 135, Companies Act, 2013").
A link to the full text of the cited section or act, allowing users to verify the information. This builds trust, which is paramount in legal applications.

Perfection is the enemy of shipping. Get it out there.

We don't build vaporware. We build products that actually work.

User Query: "What are the requirements for a private limited company to hold an Annual General Meeting in India, including notice period and quorum?"

Every project is a lesson in pain. And learning.

Most Indian founders overthink it. Just build the damn thing.

" }

Built a Legal AI for Indian Law: No BS, Just Live Code.

Most legal tech in India is stuck in the 90s, running on PDFs and human sweat.

Founders often build solutions looking for problems. We don't.

Most clients want the moon. We pull them back to Earth with a ₹49,999 MVP.

Your AI is only as good as your data. Most Indian data is a mess.

Don't chase shiny objects. Use battle-tested tools that actually ship.

LLMs hallucinate more than a Delhi summer dream. RAG is the antidote.

If it's not intuitive, no one uses it. Simple design beats flashy features.

Perfection is the enemy of shipping. Get it out there.

We don't build vaporware. We build products that actually work.

Every project is a lesson in pain. And learning.

Most Indian founders overthink it. Just build the damn thing.

Most legal tech in India is stuck in the 90s, running on PDFs and human sweat.

Founders often build solutions looking for problems. We don't.

Most clients want the moon. We pull them back to Earth with a ₹49,999 MVP.

Your AI is only as good as your data. Most Indian data is a mess.

Don't chase shiny objects. Use battle-tested tools that actually ship.

LLMs hallucinate more than a Delhi summer dream. RAG is the antidote.

If it's not intuitive, no one uses it. Simple design beats flashy features.

Perfection is the enemy of shipping. Get it out there.

We don't build vaporware. We build products that actually work.

Every project is a lesson in pain. And learning.

Most Indian founders overthink it. Just build the damn thing.

Raghav Shah

Want to Build Something Like This?

More Articles

Our 20-Day MVP Launch Process

View All Blog Posts