# Aethvora Labs: full site content > Aethvora Labs is an AI-native engineering partner in Bengaluru, India. We build AI agents, SaaS products, MVPs and cloud infrastructure for startups and enterprise teams worldwide. Contact: hello@aethvora.com. Website: https://aethvora.com/. Last updated: 2026-11-08. # Who we help ## Startup founders (https://aethvora.com/for/founders) Your MVP, built by senior engineers, live in weeks. You have the idea, the customers to talk to and a deadline. We turn it into a product people can sign up for and pay for, with code you won’t have to rewrite after you raise. Common problems: - No technical co-founder: You need senior engineering judgment now, not after months of hiring. - Quotes that don’t add up: Agencies quote features, not outcomes, and the scope creeps from week one. - A prototype you’ll throw away: Fast builds that fall over when real users arrive, or when investors ask for a tech review. - Fundraising on a clock: You need real usage to show investors, not just a deck and a Figma file. How Aethvora helps: - Scope the smallest product that proves the business - Design and build the core flows, with auth, payments and analytics - Add the AI feature that makes it worth paying for - Support launch, iteration and your first engineering hire Starting offer: MVP Scoping Sprint. A clear plan, a fixed price and a launch date. Two weeks to turn your idea into a buildable plan, before you commit to the full build. Includes: - User flows and feature scope - Clickable designs for the key screens - Architecture and data model - Fixed-price build plan with a launch date ### How much does an MVP cost? It depends on scope. Projects range from under $10k for a focused first release to $75k+ for a full product. After the scoping sprint you get a fixed price and a launch date before the build starts. ### I’m not technical. Is that a problem? No. We explain trade-offs in plain language, make the technical decisions with you, and document everything so a future CTO or engineering hire can pick it up. ### Will the code pass an investor’s technical review? We build on mainstream, well-supported technology with tests, CI/CD and documentation, which is exactly what technical due diligence looks for. ### What happens after launch? Most founders keep us on to iterate on user feedback. Others hand the code to their own team, and we help with documentation and hiring. ## SaaS companies (https://aethvora.com/for/saas) Ship the AI features your roadmap keeps promising. Your team is busy keeping the core product running. We add a senior pod that ships AI features, agents and infrastructure work alongside them, in your repos and your process. Common problems: - AI on the roadmap, every quarter: Customers and the board ask for it, and your team has no time to research, evaluate and ship it. - Demos that never reach production: Prototypes work on the happy path, then accuracy, latency and cost stall the launch. - Infrastructure slowing releases: Manual deploys, noisy alerts and a rising cloud bill eat engineering time. - Hiring takes months: Senior AI and platform engineers are hard to find and slow to onboard. How Aethvora helps: - AI features, copilots and agents inside your product - RAG over your customers’ data, with permissions respected - Evaluation, guardrails and cost monitoring in production - CI/CD, Kubernetes and cloud cost work to speed up releases Starting offer: AI Feature Pilot. One AI feature in production, with numbers to prove it. We pick one high-value workflow, build it against real cases and ship it with monitoring, typically in two to three weeks. Includes: - Use case and success metric agreed up front - Evaluation set built from your real data - Production release behind a feature flag - Accuracy and cost dashboard ### Can you work in our codebase and process? Yes. We work in your repositories, follow your review process and join your rituals, as an embedded pod or on a specific workstream. ### How do you handle our customers’ data? We can use enterprise model endpoints that don’t train on your data, keep data in your own cloud, apply role-based access to retrieved content and log every action for audit. ### What if the AI feature isn’t accurate enough? We agree an accuracy threshold before launch and measure against an evaluation set from day one, so you know early whether the feature is ready, needs work, or isn’t worth shipping. ### How do engagements usually start? With a one- to two-week discovery to pick the workflow and the metric, followed by the pilot. Many teams then keep a pod on for the next features. ## Enterprise teams (https://aethvora.com/for/enterprise) AI and modernization, without the risk. We help enterprise teams move from AI pilots and ageing systems to production software that security, compliance and operations teams can sign off on. Common problems: - Pilots that never scale: Proofs of concept that impress in a demo but can’t pass security review or handle real volume. - Legacy systems holding teams back: Critical workflows run on tools nobody wants to touch. - Security and compliance gates: Every new system needs access controls, audit trails and data-residency answers. - Vendor sprawl: Several vendors, and nobody owns the outcome end to end. How Aethvora helps: - Ranked AI use cases, each with a business case - Production agents and copilots in your own cloud accounts - Legacy modernization and cloud migration in planned stages - Access control, audit logs and compliance evidence Starting offer: AI & Cloud Readiness Assessment. A clear, costed roadmap before you commit budget. A fixed-scope assessment that tells you where AI and modernization will pay off first, and what it will take. Includes: - Workshops with business and IT owners - Ranked use cases with effort and impact - Data, security and architecture review - 90-day roadmap with budget ranges ### Can you work within our procurement and security process? Yes. We can work under your NDA, complete security questionnaires and follow your vendor onboarding process. ### Where is our data processed? In your own cloud accounts wherever possible, using enterprise model endpoints that do not train on your data, with access scoped to each user’s permissions. ### Do you help with compliance? We build the access controls, encryption, audit logging and documentation you need for SOC 2, ISO 27001, HIPAA or GDPR reviews. Certification itself stays with your auditor. ### Can you work across our time zones? Yes. We are based in Bengaluru and work with teams in India, the US, the UK and Europe, with overlap in your working hours. # Services ## AI Agents & Automation (https://aethvora.com/services/ai-agents) AI agents that do real work, safely We design, build and run AI agents, copilots and knowledge systems that plug into the tools your team already uses. Every agent ships with evaluation, guardrails and cost monitoring, because a demo is easy and production is not. Capabilities: - Custom AI agents and multi-agent workflows - RAG over docs, tickets, CRM and databases - Customer-facing copilots and chat interfaces - Voice agents for support and scheduling - LLM integrations: OpenAI, Claude, Gemini, open-source models - Evaluation suites, guardrails and human review steps Where agents pay off first: - Internal knowledge assistant: Answers questions from your docs, wikis, Slack and tickets, with citations, so people stop hunting for information. Measured by: Time to answer, adoption, answer accuracy. - Support automation: Resolves routine tickets, drafts replies for agents and routes complex cases to the right person with full context. Measured by: Deflection rate, first-response time, CSAT. - Sales and lead qualification: Researches inbound leads, scores fit, books meetings and drafts personalized follow-ups for your reps to approve. Measured by: Qualified leads per rep, response time. - Document processing: Extracts, classifies and checks contracts, invoices and forms, flagging exceptions for human review. Measured by: Processing time per document, error rate. Process: 1. Discovery and scoping: We map the workflow, collect real examples and agree on the metric the agent has to move. 2. Architecture and model choice: We choose models, retrieval and tool design based on accuracy, latency, cost and data privacy needs. 3. Build with an evaluation set: We build against a test set of real cases from day one, so every change is measured, not guessed. 4. Guardrails and review: Input and output checks, permissions, audit logs and human approval for high-stakes actions. 5. Launch and monitor: Production rollout with tracing, cost dashboards and a feedback loop that keeps accuracy improving. Models and tools we work with: OpenAI, Claude, Gemini, Llama, LangChain, LlamaIndex, CrewAI, Pinecone, Weaviate, pgvector, Ollama, LangSmith. ### How long does it take to build an AI agent? A focused, single-purpose agent usually reaches production in two to three weeks. Multi-agent systems with several integrations typically take six to eight weeks from discovery to launch. ### What does it cost to run an agent? Running costs are mostly model API usage and vector database hosting, and depend heavily on volume. We estimate them during discovery, set budget alerts and optimize prompts, caching and model choice to keep them predictable. ### Can the agent connect to our existing tools? Yes. We regularly integrate with Slack, Microsoft Teams, Salesforce, HubSpot, Zendesk, Notion, Confluence, Google Workspace, internal databases and custom APIs. ### How do you make sure the answers are accurate? We ground answers in your data with retrieval and citations, test every change against an evaluation set of real cases, and add human review for decisions that carry risk. ### Is our data safe? We can run on enterprise model endpoints that do not train on your data, keep data in your own cloud account, apply role-based access to retrieved content and log every agent action for audit. ## MVP & Product Engineering (https://aethvora.com/services/mvp) From idea to a product people pay for, in weeks We take your idea from whiteboard to production, focused on the few features that prove the business. The code is built to keep, not to throw away: clean architecture, real infrastructure and the analytics to learn what to build next. Capabilities: - SaaS platforms and B2B dashboards - AI-native products and copilots - Marketplaces and mobile apps - Internal tools and admin panels - Billing, subscriptions and global payments - Analytics, feature flags and feedback loops How we build MVPs that last: - Build the core value first: We find the one thing that makes your product worth using and ship that before anything else. Measured by: Time to first real user. - Production-ready from day one: Typed code, tests on the critical paths, CI/CD and proper error handling. No rewrite after you raise. Measured by: Defects after launch. - Polish where it matters: Real design effort on the flows users touch most. The rest is clean and functional. Measured by: Activation rate. - Built to learn: Analytics, feature flags and feedback capture are part of the MVP, so every release teaches you something. Measured by: Weekly active usage. Process: 1. Scope the smallest valuable product: We cut the feature list down to what proves the business and agree on a launch date. 2. Design the critical flows: Clickable designs for the screens that matter, validated with you before we build. 3. Build in weekly increments: A live staging URL from week one, with a demo every week. 4. Launch with instrumentation: Analytics, error tracking and feature flags in place before real users arrive. 5. Iterate or hand over: We keep building with you, or hand over documented code to your own team. Our default stack: React, Next.js, TanStack, TypeScript, Node.js, PostgreSQL, Supabase, Prisma, Tailwind CSS, React Native, Stripe, Razorpay. ### How long does an MVP take? Most MVPs launch in about eight weeks: two weeks of discovery and design, four weeks of core build and two weeks of polish and launch. Smaller products can ship faster. ### What does an MVP cost? It depends on scope and integrations. After a discovery call we send a fixed-scope proposal, so you know the price and the launch date before we start. ### Will we have to rebuild it later? No. We use mainstream, well-supported technology and production practices from the start, so the MVP becomes the foundation of the product rather than a throwaway prototype. ### Can you help after launch? Yes. Most clients keep us on as a product pod to iterate on user feedback. Others hand the code to an in-house team, and we help with documentation and hiring. ### Do you handle design too? Yes. We design the user flows and key screens as part of the MVP, using a design system so the product stays consistent as it grows. ## Cloud & DevOps (https://aethvora.com/services/cloud) Infrastructure that scales quietly and costs less We design, migrate and run cloud infrastructure on AWS, Google Cloud and Azure. Everything is defined as code, deployed through pipelines and monitored, so releases are routine and surprises are rare. Capabilities: - Cloud migration and landing-zone setup - Kubernetes and container platforms - Infrastructure as code with Terraform - CI/CD pipelines and GitOps - Monitoring, logging and alerting - Security hardening, backup and disaster recovery Common starting points: - Cloud cost optimization: Right-sizing, autoscaling, commitment planning and cleanup of idle resources, without hurting performance. Measured by: Monthly spend, cost per customer. - Legacy migration: Move applications to managed or container-based services in planned stages, with rollback at every step. Measured by: Downtime during cutover, deploy time. - Security and compliance readiness: Access controls, encryption, audit logging and the evidence you need for SOC 2, ISO 27001, HIPAA or GDPR reviews. Measured by: Open findings, audit readiness. - Reliability and performance: Caching, load balancing, database tuning and alerting that tells you about problems before customers do. Measured by: Latency, error rate, recovery time. Process: 1. Audit: We review architecture, spend, security posture and deployment workflow, and write up the gaps. 2. Plan: A prioritized roadmap with effort, risk and expected savings for each change. 3. Codify: Infrastructure moved into Terraform and pipelines, reviewed like any other code. 4. Migrate and harden: Changes rolled out in stages, with monitoring and rollback ready at each one. 5. Operate and hand over: Runbooks, dashboards and on-call setup, run by us or handed to your team. Platforms and tools: AWS, Google Cloud, Azure, Cloudflare, Docker, Kubernetes, Terraform, ArgoCD, GitHub Actions, GitLab CI, Prometheus, Grafana. ### Do you offer an infrastructure audit? Yes. We start most cloud engagements with an audit of architecture, cost, security and deployment workflow, and deliver a prioritized list of fixes with estimated effort and impact. ### Which cloud providers do you work with? AWS, Google Cloud and Azure, plus Cloudflare for edge and CDN. We are vendor-neutral and recommend what fits your workload, team and existing contracts. ### Can you migrate without downtime? In most cases, yes. We migrate in stages with parallel environments, data replication and tested rollback plans, and schedule any unavoidable cutover for your quietest hours. ### Do we need Kubernetes? Not always. For many teams, managed services or serverless are simpler and cheaper. We recommend Kubernetes when the number of services, scaling needs or portability requirements justify it. ### Can you support our infrastructure after the project? Yes. We offer ongoing DevOps support on a retainer, or we hand over with documentation, runbooks and training for your team. # Selected work ## OG Sports: A cricket store that helps every player find their bat D2C e-commerce. Live at https://ogsportsx.com/. A direct-to-consumer store for OG Sports’ premium cricket bats, with a guided bat finder and a game that brings players back every month. ## Kaching: A marketplace where creators pay with their influence Creator marketplace. Live at https://letskaching.com/. A two-sided platform where Instagram creators book experiences at cafés, restaurants and bars, and repay them with content instead of money. # Frequently asked questions ### What does Aethvora Labs do? Aethvora Labs is an AI-native engineering partner. We design, build and run AI agents, SaaS products and MVPs, cloud infrastructure and DevOps, and growth systems such as CRM, billing and analytics. ### How quickly can you start, and how fast do you ship? Most projects start with a one- to two-week discovery and design phase. A focused AI agent typically reaches production in two to six weeks, and an MVP in about eight weeks. You get a working demo every week. ### How much does a project cost? It depends on scope. Projects range from under $10k for a focused automation to $75k+ for a full product build. After a discovery call we send a written scope with a fixed price or a monthly pod rate. ### Who owns the code and IP? You do. Code lives in your repositories and cloud accounts from day one, and intellectual property is assigned to you under the project agreement. ### Where are you based, and do you work with international clients? We are based in Bengaluru, India, and work remotely with teams in India, the United States, the United Kingdom, Europe and elsewhere, with overlap in your working hours. ### Can you work alongside our existing engineering team? Yes. Many clients use us as an embedded pod or for a specific workstream such as AI features or infrastructure. We work in your repositories, tools and review process. # Articles ## Building AI Agents for Enterprise: A Practical Guide URL: https://aethvora.com/blog/ai-agents-enterprise Published: 2026-05-20; updated 2026-11-08 Short answer: Start with one high-volume, low-risk workflow, ground the agent in your own data, and measure it against 50 to 200 real examples before giving it more autonomy. Most production agents are a single agent with a few well-described tools and a human approval step. AI agents are different from traditional automation. A rule-based workflow follows the steps you wrote down. An agent reads context, decides which tool to use, and takes an action toward a goal. That flexibility is the value, and it is also the risk. This guide covers what we have learned getting agents from demo to production. ## Start with the right workflow The best first agent is not the most impressive one. It is the one with high volume, clear inputs, a measurable outcome and a safe failure mode. Good candidates: - Answering internal questions from documentation, wikis and past tickets - Drafting replies to routine support tickets for a human to approve - Researching and qualifying inbound leads - Extracting fields from invoices, contracts or forms Avoid starting with workflows where a wrong action is expensive and hard to undo, such as issuing refunds or changing production systems, until you have evaluation and approvals in place. ## Choose the simplest architecture that works ### Single agent with tools One model, a clear system prompt and a small set of well-described tools. This covers most business workflows and is far easier to test and debug. ### Multi-agent orchestration Several specialized agents coordinated by a planner. Useful when a task genuinely needs different skills or contexts, such as research, drafting and review. It adds latency, cost and failure points, so use it only when one agent clearly is not enough. ### Human in the loop The agent prepares, a person approves. This is the right default for anything customer-facing or financial, and you can relax it as accuracy data builds up. ## Ground the agent in your data Most "hallucination" problems are retrieval problems. If the agent cannot find the right document, it will guess. Invest in clean source data, sensible chunking, metadata filters and citations in every answer. Our [RAG pipeline guide](/blog/rag-pipelines-guide) goes deeper on this. ## Build an evaluation set before you build the agent Collect 50 to 200 real examples of the task with the correct outcome. Run every prompt, model or retrieval change against that set. Without it, you are tuning by feel, and improvements in one place quietly break another. Track at least: - Task accuracy against the expected outcome - How often the agent escalates or refuses - Latency per request - Cost per request ## Design for security from day one 1. **Least privilege.** Give each tool the narrowest permissions it needs, and scope retrieval to what the current user is allowed to see. 2. **Validate inputs and outputs.** Treat model output as untrusted input to the next system, and watch for prompt injection in retrieved content. 3. **Log every action.** Keep an audit trail of prompts, tool calls and results for debugging and compliance. 4. **Set budgets.** Rate limits and spend alerts stop a loop or a spike from turning into a large bill. ## Plan the production checklist - End-to-end tests on real scenarios, including edge cases and bad input - Monitoring with traces for every request - Cost dashboards and budget alerts - Graceful fallbacks when the model or a tool is unavailable - A feedback button so users can flag bad answers - Runbooks for the team that will operate it ## The short version Building an agent is mostly engineering, not research. Pick a narrow, valuable workflow, ground it in good data, measure it against real examples, and add autonomy only as fast as the evaluation numbers allow. If you have a workflow in mind, [book a discovery call](/services/ai-agents) and we will help you decide whether an agent is the right tool. ### What is an AI agent? An AI agent is software that uses a language model to read context, decide which tool to use and take actions toward a goal, instead of following fixed steps like traditional automation. ### What is the best first use case for an enterprise AI agent? A high-volume workflow with clear inputs, a measurable outcome and a safe failure mode, such as answering internal questions from documentation or drafting support replies for a person to approve. ### How do you keep an AI agent secure? Give each tool the narrowest permissions, scope retrieval to what the user may see, treat model output as untrusted input, log every action, and set rate limits and spend alerts. --- ## Cloud Migration: From Planning to Production in 90 Days URL: https://aethvora.com/blog/cloud-migration-strategy Published: 2026-05-15; updated 2026-11-08 Short answer: A 90-day cloud migration runs in four phases: assess and inventory (days 1 to 15), build the landing zone as code (15 to 30), migrate in waves with parallel runs (30 to 75), then right-size costs and hand over (75 to 90). Cloud migrations fail for predictable reasons: unclear scope, big-bang cutovers, and nobody owning cost after the move. A 90-day plan is realistic for a small-to-mid-sized estate if you split the work into phases and migrate in waves. ## Days 1–15: Assess Before moving anything, build an inventory. - Every application, database, scheduled job and integration - Who owns each one and how critical it is - Current performance, peak load and data volumes - Compliance requirements and where data is allowed to live - What the current setup actually costs, including licenses and people time Then decide a strategy per workload. The common options are **rehost** (move as-is), **replatform** (move with small changes, such as switching to a managed database), **refactor** (rebuild for cloud-native services), **replace** with SaaS, or **retire**. Most estates end up with a mix, and retiring things is the cheapest migration there is. ## Days 15–30: Design the landing zone The landing zone is the foundation everything else sits on. Define it as code from the start, usually with Terraform. - Account or project structure for production, staging and development - Networking: VPCs, subnets, private connectivity and DNS - Identity: single sign-on, roles and least-privilege access - Logging, monitoring and alerting - Backup policies and encryption defaults - Budgets and cost allocation tags Getting this right first means every migrated workload inherits good security and visibility automatically. ## Days 30–75: Migrate in waves Group workloads into waves of increasing risk. Start with something low-stakes, such as an internal tool, to prove the process. For each workload: 1. Build the target environment from code 2. Set up data replication from the old system 3. Run both environments in parallel and compare results 4. Cut over during a quiet period with a tested rollback plan 5. Watch closely for a few days before decommissioning the old system Databases deserve the most care. Use replication or change-data-capture so the final cutover is a short sync, not a long copy. ## Days 75–90: Optimize and hand over Right after migration is when cost and performance are easiest to fix. - Right-size instances based on real usage, not on the old hardware - Turn on autoscaling where load varies - Use commitment discounts for steady baseline load - Remove idle resources, unattached disks and old snapshots - Document runbooks and hand on-call ownership to a named team ## Common mistakes - **Lift-and-shift everything.** Moving inefficient systems unchanged often costs more than before. - **No owner for cost.** Without budgets and tags, spend drifts upward quietly. - **Skipping the parallel run.** It feels slow, but it is what makes zero-downtime cutovers possible. - **Treating security as a later phase.** Retrofitting access controls is much harder than building them into the landing zone. ## Next step A short assessment usually shows which workloads to move first and roughly what the target will cost. If you want a second pair of eyes, [book an infrastructure review](/services/cloud). ### How long does a cloud migration take? For a small to mid-sized estate, about 90 days is realistic when the work is phased and workloads move in waves. Larger or regulated estates take longer. ### What is a cloud landing zone? The foundation every workload sits on: account structure, networking, identity, logging, backups and budgets, defined as code before any application moves. ### How do you migrate to the cloud without downtime? Replicate data from the old system, run both environments in parallel and compare results, then cut over during a quiet period with a tested rollback plan. --- ## MVP Development: Ship Fast Without Cutting Corners URL: https://aethvora.com/blog/mvp-development-best-practices Published: 2026-05-10; updated 2026-11-08 Short answer: Scope the MVP to the one outcome a user must get, build it on a mainstream stack, and ship every week. Cut features, not quality: get the data model, authentication, deployment pipeline and error tracking right from day one. An MVP has one job: prove that people want the thing enough to use it, and ideally pay for it. The tension is that you need to move fast, but anything that works becomes the foundation of your company. Here is how we balance the two. ## Scope ruthlessly Write down the one outcome a user should get from the product. Then list every feature and ask, for each one, whether a user could get that outcome without it. If yes, it waits. A typical MVP scope looks like: - Sign-up, login and basic roles - Three to five core features that deliver the main outcome - A simple admin view for your team - Payments, if you are testing willingness to pay - Transactional emails - Analytics on the key steps Features like advanced settings, integrations, team management and custom reporting almost always wait until real users ask for them. ## Cut scope, not quality Speed should come from building less, not from building badly. The corners that are expensive to cut: - **Data model.** A messy schema spreads into every feature. Spend real time on it in week one. - **Authentication and permissions.** Use a proven provider. Never roll your own. - **Deploy pipeline.** Automated deploys from day one make every later week faster. - **Error tracking.** You need to know when things break before users tell you. The corners that are fine to cut early: pixel-perfect design on secondary screens, admin tooling polish, and scale optimizations you do not need yet. ## Choose a boring, well-supported stack The best MVP stack is one with a large hiring pool, mature libraries and good hosting options. For most web products that means TypeScript, React or Next.js, a Node.js backend and PostgreSQL. Managed services for auth, email and payments save weeks. Novel technology is worth it only when it is the core of what you are selling. ## Work in weekly increments We aim for a live staging URL in the first week and a demo every week after that. Weekly demos keep scope honest: it is very clear when something is taking longer than planned, and you can make trade-offs while they are still cheap. A common eight-week shape: 1. **Weeks 1–2:** user flows, architecture, design for key screens, data model 2. **Weeks 3–6:** core features, integrations, weekly demos 3. **Weeks 7–8:** polish, QA, performance and security checks, launch ## Instrument before you launch The point of an MVP is learning, so make sure you can actually learn from it: - Product analytics on sign-up, activation and the core action - Feature flags so you can test changes safely - An easy way for users to send feedback - A short list of the questions you want the first month of data to answer ## After launch The first few weeks of real usage will change your roadmap. Plan for that: keep a small team in place to respond quickly, and resist the urge to add the next big feature before you understand how people use the first ones. If you are planning an MVP, [talk to us about scope](/services/mvp). We will give you a realistic plan and a launch date. ### How long does it take to build an MVP? Most MVPs take about eight weeks: two weeks of scoping and design, four weeks of core build, and two weeks of polish and launch. ### What should an MVP include? Sign-up and login, three to five core features that deliver the main outcome, a simple admin view, payments if you are testing willingness to pay, transactional email and analytics. ### What is the best tech stack for an MVP? A mainstream, well-supported one with a large hiring pool. For most web products that means TypeScript, React or Next.js, a Node.js backend and PostgreSQL, with managed services for auth, email and payments. --- ## Building RAG Pipelines: From Zero to Production URL: https://aethvora.com/blog/rag-pipelines-guide Published: 2026-05-05; updated 2026-11-08 Short answer: A production RAG pipeline has seven stages: ingestion, chunking, embeddings, hybrid retrieval with reranking, grounded generation with citations, evaluation, and production monitoring. Most accuracy problems turn out to be retrieval problems, not model problems. Retrieval-augmented generation (RAG) lets a language model answer questions using your own documents instead of only its training data. The idea is simple: find the most relevant passages, put them in the prompt, and ask the model to answer from them. Making it reliable takes more work. Here is the pipeline, stage by stage. ## 1. Ingestion Start by getting clean text out of your sources: PDFs, wikis, help centers, tickets, databases. This step decides your ceiling. If tables are mangled or headings are lost, no model will recover them. - Extract structure, not just text: headings, lists and tables - Keep metadata such as source, URL, author, date and access permissions - Remove boilerplate like navigation menus and footers - Re-ingest on a schedule, or on change, so answers stay current ## 2. Chunking Documents are split into chunks small enough to retrieve precisely but large enough to carry meaning. A few hundred tokens with some overlap is a reasonable starting point. Better still, split along the document's own structure, such as sections or FAQ entries, and include the section title in each chunk so it makes sense on its own. ## 3. Embeddings and storage Each chunk is converted into an embedding vector and stored in a vector database such as pgvector, Pinecone or Weaviate. If you already run PostgreSQL, pgvector is often enough and keeps your stack simple. Store the metadata alongside the vector so you can filter by permissions, product or date. ## 4. Retrieval Pure vector search misses exact terms like product codes and error messages. Most production systems use **hybrid search**: combine keyword search with vector similarity, then merge the results. Then add a **reranking** step. Retrieve a broad set, perhaps 20 to 50 candidates, and use a reranker model to pick the best handful for the prompt. This is one of the highest-impact improvements you can make. Always apply **permission filters** at retrieval time, so users never see content they should not. ## 5. Generation Give the model clear instructions: answer only from the provided context, cite the source for each claim, and say when the context does not contain the answer. Showing citations to users builds trust and makes errors easy to spot. ## 6. Evaluation Build a test set of real questions with known good answers and the documents that contain them. Measure two things separately: - **Retrieval quality:** did the right passages make it into the context? - **Answer quality:** was the answer correct, complete and faithful to the sources? Separating them tells you where to fix things. Most problems turn out to be retrieval. ## 7. Production concerns - **Freshness:** update the index when source documents change - **Latency:** cache frequent queries and keep the prompt lean - **Cost:** track tokens per request, and use smaller models where they are good enough - **Observability:** log the query, retrieved chunks and answer for every request - **Feedback:** let users flag wrong answers and feed them back into the test set ## Common pitfalls - Chunks with no context, such as a paragraph that says "see above" - Relying on vector search alone for technical or product content - No "I don't know" path, so the model fills gaps with guesses - Indexing everything, including outdated and duplicate documents RAG is the foundation of most useful business agents. If you are building one, [we can help you design it](/services/ai-agents), or read our [guide to enterprise AI agents](/blog/ai-agents-enterprise). ### What is RAG? Retrieval-augmented generation finds the most relevant passages in your own documents and puts them in the prompt, so a language model answers from your data instead of only its training data. ### Which vector database should I use for RAG? If you already run PostgreSQL, pgvector is often enough. Managed options such as Pinecone or Weaviate suit very large indexes or teams that don't want to operate a database. ### How do you evaluate a RAG system? Build a test set of real questions with known answers and source documents, then measure retrieval quality and answer quality separately, so you know which stage to fix. --- ## Kubernetes Cost Optimization: 10 Strategies That Work URL: https://aethvora.com/blog/kubernetes-cost-optimization Published: 2026-04-28; updated 2026-11-08 Short answer: Most Kubernetes waste comes from resource requests set far above real usage and from nodes that never scale down. Start with three steps: make costs visible, right-size requests to actual usage, and make sure node autoscaling really removes nodes. Kubernetes makes it easy to run a lot of software, and just as easy to pay for capacity nobody uses. Most clusters we review have significant waste, usually from over-provisioned resource requests and nodes that never scale down. These ten strategies are where we start. ## 1. Make costs visible first You cannot optimize what you cannot see. Install a cost allocation tool such as OpenCost or Kubecost, and label workloads by team, service and environment. Share the numbers with the teams that own the workloads. ## 2. Right-size resource requests Requests decide how much capacity the scheduler reserves. Teams often set them high "to be safe", which leaves nodes half empty. Compare requests with actual usage over a few weeks and bring them closer together. Tools like the Vertical Pod Autoscaler in recommendation mode make this easier. ## 3. Set sensible limits Memory limits protect nodes from runaway pods. CPU limits are more nuanced, since they can cause throttling. Set memory requests and limits deliberately, and think carefully before applying strict CPU limits to latency-sensitive services. ## 4. Autoscale pods Use the Horizontal Pod Autoscaler so services scale with load instead of running at peak capacity all day. For event-driven workloads, KEDA can scale on queue length and even down to zero. ## 5. Autoscale nodes Pod autoscaling only saves money if nodes scale down too. Use Cluster Autoscaler or Karpenter, and check that nothing blocks scale-down, such as pods without disruption budgets or with local storage. ## 6. Use spot or preemptible capacity Spot instances cost much less than on-demand capacity. They suit stateless services, batch jobs and CI runners that can handle interruption. Run a mix of spot and on-demand nodes, and spread replicas so a single reclaim does not take a service down. ## 7. Choose the right instance types Pick node families that match your workload's CPU-to-memory ratio. Newer generations and ARM-based instances often give better price-performance. Fewer, larger nodes can also reduce per-node overhead. ## 8. Commit to your baseline For capacity you run all the time, savings plans or committed-use discounts are significantly cheaper than on-demand pricing. Commit only to the steady baseline, and let autoscaling and spot cover the peaks. ## 9. Shut down what is not in use Development and staging environments rarely need to run overnight or on weekends. Schedule them to scale down outside working hours, and use short-lived preview environments that are deleted when a pull request closes. ## 10. Clean up regularly Orphaned load balancers, unattached volumes, old snapshots and forgotten namespaces add up. Run a monthly cleanup, and automate it where you can. ## Where to start If you only do three things: make costs visible, right-size requests, and make sure nodes actually scale down. Those usually deliver most of the savings with little risk. Want a clear view of where your cluster spend goes? [Book an infrastructure review](/services/cloud). ### Why is my Kubernetes bill so high? Usually because resource requests are much higher than real usage, leaving nodes half empty, and because idle environments and nodes never scale down. ### Are spot instances safe for Kubernetes? For stateless services, batch jobs and CI runners, yes, provided you mix spot with on-demand nodes and spread replicas so one reclaim doesn't take a service down. ### Which tools show Kubernetes costs? OpenCost and Kubecost allocate cluster costs by namespace, team or label, which is the first step to reducing them. --- ## Building a Real-Time SaaS Metrics Dashboard URL: https://aethvora.com/blog/saas-metrics-dashboard Published: 2026-04-20; updated 2026-11-08 Short answer: Agree metric definitions first, take revenue from your billing system as an append-only event log, and build the pipeline in three layers: raw events, cleaned data and daily metric snapshots. Most teams need hourly or daily refreshes, not true real time. Every SaaS team wants one place to see how the business is doing. The hard part is not the charts. It is agreeing on definitions and building a pipeline that produces numbers people trust. Here is how we approach it. ## Define the metrics before you build Write a one-line definition for each metric and get finance, product and leadership to agree. The usual core set: - **MRR (monthly recurring revenue):** the normalized monthly value of all active subscriptions - **MRR movements:** new, expansion, contraction, churned and reactivated MRR - **Customer churn:** customers lost in a period divided by customers at the start - **Net revenue retention:** revenue from a cohort now versus a year ago, including expansion - **Activation:** the share of new sign-ups who reach the first meaningful action - **Active usage:** daily, weekly or monthly active accounts Small definition choices, such as how annual plans, discounts and trials are counted, change the numbers a lot. Document them where people can see them. ## Use billing as the source of truth for revenue Revenue metrics should come from your billing system, such as Stripe, Chargebee or Razorpay, not from your product database. Ingest subscription and invoice events through webhooks, and store them as an append-only event log. From that log you can rebuild any metric for any date, which makes corrections and audits easy. ## Model usage as events For product metrics, track events with a consistent schema: who did what, when, and in which account. Keep the list of tracked events short and intentional. A few well-defined events beat hundreds of vague ones. ## Build the pipeline in layers 1. **Raw:** events exactly as received 2. **Cleaned:** deduplicated, typed and joined to accounts 3. **Metrics:** daily snapshots of each metric per account and plan A warehouse such as BigQuery, Snowflake or plain PostgreSQL handles this well at most SaaS scales. Tools like dbt keep transformations versioned and tested. ## Decide what "real time" really means Truly real-time revenue metrics are rarely needed. Most teams are well served by hourly or daily refreshes, which are simpler and cheaper. Reserve streaming for operational views like sign-ups today or failed payments, where minutes matter. ## Design the dashboard for decisions - Put the few numbers leadership checks every week at the top - Show trends over time, not just the current value - Let people drill from a total into the accounts behind it - Show the definition of each metric on hover - Flag data freshness so nobody acts on stale numbers ## Test the numbers Reconcile dashboard revenue with your billing system every month. Add automated checks for gaps, duplicates and sudden jumps. Trust is hard to win back once a board meeting catches a wrong number. ## Build or buy? Off-the-shelf tools work well for standard Stripe-based subscription metrics. A custom dashboard makes sense when you have usage-based pricing, multiple billing systems, or need product and revenue data in one view. If you need a metrics dashboard built into your product or for your team, [talk to us](/services/mvp). ### What metrics should a SaaS dashboard show? MRR and its movements (new, expansion, contraction and churn), customer churn, net revenue retention, activation and active usage. ### Where should SaaS revenue metrics come from? From your billing system, such as Stripe, Chargebee or Razorpay, ingested through webhooks, not from your product database. ### Should I build or buy a SaaS metrics dashboard? Buy one for standard Stripe subscriptions. Build one when you have usage-based pricing, several billing systems, or need product and revenue data in one view.