In-House vs Outsourcing Software Development: Cost & Trade-offs
TL;DR
In-house vs outsourcing software development is really a question of stage, not preference. Outsource to validate: it's faster and 40–70% cheaper, with a partner starting in weeks vs months to hire. Build in-house to scale, when software is your core product and daily control matters. Most companies run a hybrid — core in-house, capacity outsourced.
In-House vs Outsourcing Software Development: Cost & Trade-offs
The in-house vs outsourcing software development decision usually comes down to one thing, and it is not preference. It is stage. Before you have proven your product, outsourcing is faster and cheaper. After you have proven it, in-house control starts to matter more. Most successful companies do not pick one and stop. They outsource to validate, hire to scale, and run a hybrid in between.
Here is the honest version most guides skip, because outsourcing agencies write most guides on this topic with an agenda. We build software for clients, so we have that bias too, and we are going to be upfront about when in-house is the better call anyway. The real numbers, the real trade-offs, and the uncomfortable truths on both sides are below, so you can make the decision that fits where your business actually is.
This guide covers what each model really costs in 2026, the trade-offs beyond cost, the hybrid model most companies actually use, and a simple way to decide.
The quick answer: which model fits your stage
If you want the decision fast, use this.
Outsource if you need to launch in weeks not months, you are validating an idea, you need a specialist skill you do not have in-house (AI, cloud, security), or you cannot justify a permanent engineering payroll yet.
Build in-house if software is your core product, you need long-term control over IP and quality, your team must collaborate closely across the business every day, and you have the budget and time to hire.
Go hybrid if you want the best of both: keep the critical, differentiating work in-house and flex capacity through a partner for everything else. This is what most companies actually do by 2026.
The honest rule: outsource to validate, hire to scale. Match your build strategy to the stage you are at now, not the scale you hope to reach later.
What in-house and outsourcing actually mean
Two quick definitions, because the trade-offs flow from them.
In-house software development means you hire, employ, and manage your own engineering team. They are your staff, on your payroll, in your culture. You get maximum control, continuity, and institutional knowledge, at the cost of high fixed spend and slow hiring.
Outsourcing software development means you hire an external company or team to build for you, as your staff for the project's duration. You get speed, flexibility, and access to skills you do not have, at the cost of less day-to-day control and the need to manage the relationship well.
A third path, the hybrid model, keeps a small core team in-house and extends it with an outsourced partner. It has quietly become the default for growing companies, for reasons the cost math makes obvious.
The real cost comparison in 2026
Cost is where the two models differ most, and the gap is larger than most founders expect once you count everything.
The true cost of in-house. It is not just salary. A mid-level to senior software engineer in the US or UK runs $180,000 to $230,000 per year fully loaded, once you add benefits, workspace, equipment, and training. On top of that: recruitment costs of 15% to 25% of first-year salary, a 45 to 62 day average time-to-hire before a single line of code ships, and three months of reduced output while a new hire ramps up. A three-person in-house team can cost $500,000 to $800,000 a year before a single user signs up.
The cost of outsourcing. You pay a rate, not a payroll. A developer who costs $100 to $150 an hour in the US runs $25 to $50 an hour in India for the same skill level. Outsourcing firms report total savings of 40% to 70% versus an equivalent in-house team, largely from that regional rate difference, plus you avoid recruitment, benefits, and idle time. A specialist agency can start building in one to two weeks, against three to six months to hire even one senior engineer.
The AI shift that changed the math. In 2026, a small team with a mature AI toolchain can approach the output once associated with a team two to three times larger. This makes an experienced outsourcing partner that builds with AI in the loop more cost-effective than ever, and it is why the cost gap has widened, not narrowed. For the full picture on what a build itself costs, see our guide to custom software development cost.
The trade-offs beyond cost
Cost is not the whole decision. Four other factors matter, and they cut both ways.
Control and visibility. In-house wins here. Your team is in your building, in your standups, available all day. With outsourcing you have less day-to-day visibility, which is why choosing a partner with strong project management and communication matters so much. The gap narrows with the right partner, but it is real.
Speed. Outsourcing wins. A partner can start in weeks; hiring takes months. If time-to-market matters, this is decisive.
Institutional knowledge. In-house wins over the long term. The people who know why every decision was made stay with you, and that knowledge compounds. A rotating cast of external collaborators cannot replicate it as easily, which is exactly why core product work often belongs in-house.
IP and security. In-house keeps everything inside your walls by default. Outsourcing is perfectly safe with the right protections, NDAs, role-based access, and clear security practices, but you must vet the partner, especially for regulated or sensitive work.
The hybrid model most companies actually use
Here is the pattern that the versus framing misses, and that most growing companies land on.
Keep the core in-house, flex the rest through a partner. You employ a small team for the work that differentiates you and needs deep, daily context, and you use an outsourcing partner for peak workloads, specialist skills, and self-contained projects. The most common version: an agency builds version one fast, then an in-house team iterates from there once the product is proven.
This gives you the institutional knowledge of an in-house team and the speed and flexibility of outsourcing, without the full cost burden of either extreme. Roughly half of companies run a mixed setup rather than a pure one, and most do not pick a model once, they shift as they grow. The same logic behind any build-versus-buy call applies to staffing: keep what differentiates you close, and source the commodity work flexibly.
When you should build in-house (even though we do outsourcing)
We build software for clients, so honesty requires naming when in-house is genuinely the better call. Build in-house when software is your core, defensible product and your competitive edge lives in the code itself. Build in-house when you need a team collaborating with the rest of your business every single day, on fast-changing priorities. And build in-house when you are past product-market fit, scaling, and the deep context and daily availability of a dedicated internal team has become the bottleneck that outsourcing cannot solve.
If you are in one of those situations, hire, even though it costs more and takes longer. The extra cost buys control and continuity you genuinely need. Anyone who tells you to always outsource is selling, not advising.
When outsourcing is the smarter call
For most companies before scale, outsourcing wins on the factors that matter most early. Outsource when you need to move fast and cannot wait months to hire. Outsource when you are validating an idea and cannot justify permanent payroll on an unproven bet, since running out of runway, not outsourcing too early, is what kills most startups. And outsource when you need a specialist skill, AI, cloud architecture, security, that you do not have and cannot hire quickly.
The trap to avoid is hiring in-house too early because it "feels more serious." Match your build strategy to your current stage, not your hoped-for future. Outsource to validate. Hire to scale. Most founders who get into trouble reversed that order.
Ready to figure out the right model for you?
The right choice between in-house and outsourcing depends on your stage, your budget, whether software is your core product, and how fast you need to move. There is no universal answer, only the right one for where your business is now.
The Craxinno team works as an outsourced and hybrid extension of client teams, and because we would rather match you to the right model than oversell one, we will tell you honestly when hiring in-house is the better move. See recent work in the Craxinno portfolio, view how we work on the work process page, or email sales@craxinno.com.
Frequently Asked Questions
Is it cheaper to outsource or build software in-house?+
Outsourcing is usually cheaper, often by 40% to 70%. A mid-level engineer in the US or UK costs $180,000 to $230,000 per year fully loaded, while the same skill outsourced to India runs $25 to $50 an hour. Outsourcing also avoids recruitment, benefits, and idle time, and a partner can start in weeks versus the three to six months it takes to hire in-house.
When should I build an in-house software team instead of outsourcing?+
Build in-house when software is your core, defensible product, when your team must collaborate closely with the rest of your business every day, or when you are past product-market fit and scaling, where the deep context and daily availability of an internal team becomes essential. In those cases, the higher cost and slower hiring buy control and continuity you genuinely need.
What is a hybrid software development model?+
A hybrid model keeps a small core team in-house for the work that differentiates you, and uses an outsourcing partner for peak workloads, specialist skills, and self-contained projects. A common version has an agency build version one quickly, then an in-house team iterate from there. It combines the institutional knowledge of in-house with the speed and flexibility of outsourcing.
Is outsourcing software development risky for IP and security?+
It is safe with the right protections. Reputable partners use NDAs, role-based access controls, and clear security practices to protect your IP. The key is vetting the partner's security policies and compliance experience before you start, especially for regulated or sensitive projects. In-house keeps everything inside your walls by default, which is why some highly sensitive work stays internal.
Should a startup outsource or hire developers?+
Most startups should outsource early. Before product-market fit, hiring a permanent team is an expensive way to take on risk, since running out of runway is what kills most startups, not outsourcing too early. Outsource to validate the product, then bring engineering in-house as you scale and need deeper daily context. Match your build strategy to your current stage.
Need this built properly?
Custom software from scoping to deployment — production code from week one, bi-weekly demos.
Start a projectKeep ReadingMore case studies like this
Engineering retros, product launches, and brand systems from our studio — updated monthly.
All case studiesTechnology Used
.svg){kind=logo}
Node.js
TypeScript
Next.js
AWS
React
VercelTags & Keywords
Continue with Blogs.
View all blogs
AI AgentsAI Agent Pricing: What Should You Actually Pay in 2026?
AI Agent Pricing: What Should You Actually Pay in 2026? AI agent pricing in 2026 runs from about $0.10 per interaction for off-the-shelf support bots to $200,000+ for enterprise custom builds. Most businesses should expect to pay $0.99 to $2.00 per resolved conversation on a SaaS agent, or a one-time build fee plus $500 to $3,000 a month in model and infrastructure costs for a custom agent. That range is useless on its own, so this guide breaks it apart. You'll see what the big vendors actually charge, how custom-build quotes are put together, the token math most quotes leave out, and the point where building your own agent becomes cheaper than renting one. We build AI agents for clients at Craxinno, and the most common question we get isn't "can you build this?" It's "why did the last agency quote me $90,000 for this?" Let's answer that properly. AI Agent Pricing at a Glance (2026) Option Typical 2026 price Best for No-code agent platforms $29 to $200 per month to start Internal automations, small teams testing ideas Off-the-shelf support agents $0.10 per session to $2.00 per conversation or resolution Customer support on an existing helpdesk Enterprise agent platforms $125+ per user per month, or $30,000 to $300,000+ per year Large orgs already on Salesforce, Zendesk and similar Custom-built agent (agency quotes) $20,000 to $200,000+ one-time Agents tied to your own data, tools and workflows Running costs for a custom agent Model tokens plus roughly $500 to $3,000+ per month in infrastructure Anyone who owns the agent The no-code figure comes from Toolradar's survey of 319 agent tools, where the median cheapest paid plan was $29 a month. The custom-build range matches what agencies such as Cleveroad publish. Vendor prices below are list prices as reported in late 2026, so check the vendor's page before you sign. The 5 AI Agent Pricing Models You'll Run Into Vendors stopped agreeing on how to charge for agents somewhere around 2024. Salesforce alone now sells Agentforce three different ways at the same time. Here's how the models break down. 1. Per conversation You pay every time the agent talks to someone, whether it solves the problem or not. Salesforce launched Agentforce at $2 per conversation in October 2024. Ada reportedly lands between $1.00 and $3.50 per interaction. Simple to understand, but you pay for the failures too. 2. Per resolution (outcome-based) You pay only when the agent closes the ticket without a human. Intercom's Fin charges $0.99 per outcome. Zendesk charges $1.50 per automated resolution on committed volume and $2.00 pay-as-you-go. Gorgias sits around $0.60 to $1.27 depending on plan. This sounds like the fairest deal, and often it is. The catch: the vendor defines "resolved." If a customer gives up and leaves, some systems count that as a win. Read the definition in the contract, not the landing page. 3. Credits or per action Salesforce's Flex Credits (May 2025) bill $0.10 per action, sold in packs of 100,000 credits for $500. Microsoft Copilot Studio sells 25,000 credits for $200 a month. Lindy starts at $29.99 per user per month with 3,000 credits. Credits are flexible, but forecasting them is hard until you've watched real usage for a month or two. 4. Per seat The old SaaS model, bolted onto agents. Agentforce per-user licenses start at $125 per user per month. Microsoft 365 Copilot is $30 per user per month. Fine for copilots that help employees. Strange for an agent that's supposed to replace the work of seats. 5. Platform fee plus usage Common at the enterprise end. Decagon reportedly charges around $50,000 a year as a platform fee, then adds per-conversation or per-resolution fees on top. Sierra quotes custom enterprise pricing only. What Off-the-Shelf AI Agents Cost in 2026 If you want a support agent and already use one of these helpdesks, here's the real comparison. Vendor Pricing model Reported price Intercom Fin Per outcome $0.99 per outcome (helpdesk seats from $29/month) Zendesk AI Per resolution $1.50 committed, $2.00 pay-as-you-go Salesforce Agentforce Conversation, credits or seat $2/conversation, $0.10/action, or $125/user/month Freshdesk Freddy AI Per session $0.10 per session ($100 per 1,000) Gorgias Per resolution About $0.60 to $1.27 Ada Custom About $30,000+ yearly minimum (reported) Decagon Platform fee plus usage About $50,000/year plus usage (reported) Don't stop at the per-resolution number. Agentforce implementations reportedly run $50,000 to $150,000, with ongoing consulting at $10,000 to $25,000 a month. A cheap unit price on a platform that needs a six-figure rollout isn't cheap. How Much Does It Cost to Build a Custom AI Agent? Published agency ranges look like this, using Cleveroad's 2026 breakdown: Reactive agent (answers questions, no memory): $20,000 to $35,000+ Contextual agent (remembers the conversation, uses your data): $40,000 to $70,000+ Autonomous agent (plans steps, calls tools, takes actions): $80,000 to $120,000+ Domain-specific enterprise agent (compliance, deep integrations): $100,000 to $200,000+ Those numbers are real quotes from real agencies. But they mostly reflect agency rates, not the difficulty of the work. Every custom quote comes down to one formula: Build cost = hours × hourly rate A US or UK agency billing $120 to $200 an hour gets to $80,000 fast. The same scope at a $25 an hour studio (our standard rate at Craxinno) costs a fraction of that. So the first question to ask about any quote is simple: how many hours is this, and what's the breakdown? Where do the hours actually go? In the agents we've shipped, the LLM call itself is the easy part. The time disappears into four places: Integrations. Connecting the agent to your CRM, helpdesk, database or payment gateway. Every API has its own auth, rate limits and weird edge cases. Knowledge setup. Cleaning your docs, chunking them and building retrieval (RAG) so the agent answers from your data instead of guessing. We wrote a full walkthrough in our guide to building a RAG chatbot with the OpenAI API . Guardrails and fallbacks. What happens when the agent isn't sure? When a tool call fails? When a user tries to make it say something it shouldn't? Testing against real conversations. This is the step that's skipped in cheap builds and the reason many agents look great in a demo and fall apart in week two. If a quote doesn't show hours against these items, you can't compare it with anything. If you're weighing offshore options, our post on how to hire AI developers in India covers what to check before you sign. The Token Math Most AI Agent Quotes Leave Out Here's the cost that keeps running after the build invoice is paid. Every time your agent thinks, it spends tokens. Cost per task = (input tokens × input price) + (output tokens × output price) Take a simple inbox-triage agent that reads 20,000 tokens and writes 2,000 per task. On a mid-tier model priced at $2 per million input tokens and $10 per million output tokens (OpenAI list pricing as of October 2026, per Dupple's breakdown): Input: 20,000 × $2 ÷ 1,000,000 = $0.04 Output: 2,000 × $10 ÷ 1,000,000 = $0.02 Total: $0.06 per task Now look at what model choice does to the same workload, per 1,000 tasks: Agent type Budget model Mid-tier model Flagship model Inbox triage (20k in, 2k out) $3 $60 $300 Research, 5 lookups (60k in, 6k out) $9 $180 $900 Coding/ops with cached context $11.70 $222 $1,170 That's a 100x spread for the same job. And this is where most of the waste we see comes from: teams pick the flagship model for everything because it won the demo, then get a shock at month-end. Route the easy 80% of requests to a cheap model and save the expensive one for the hard cases. It's usually the single biggest saving available. Two more things on tokens. Prices move. Dupple reports Google's Gemini Argon doubling on December 1, 2026, and Gemini 3.8 Flash doubling on January 1, 2027, so lock your budget to a model you can swap out. And if a job can wait, OpenAI's Batch processing halves standard prices. Hidden Monthly Costs of Running an AI Agent The model bill is rarely the biggest line once you're in production. Budget for these too: Vector storage and memory: roughly $500 to $2,500+ a month depending on traffic and data size Logging pipeline: $300 to $800 a month Monitoring integrations: $300 to $1,000 a month, plus $100 to $500 for error tracking Prompt tuning and testing: $1,000 to $5,000 a month if you keep improving the agent (and you should) Search grounding: on Gemini, 5,000 requests a month are free, then $14 per 1,000 Hosting: your servers or serverless functions. If you're on AWS, plan this before launch, not after Those ranges come from Cleveroad's and Dupple's 2026 breakdowns. A small agent with modest traffic will land at the low end of each. You won't need every line on day one, but you'll need most of them by month three. Buy vs. Build: When Does a Custom AI Agent Pay for Itself? This is the question that actually decides your budget, so let's do the math with real list prices. Say your support agent resolves 5,000 tickets a month. On Intercom Fin at $0.99 per outcome: about $4,950 a month, or roughly $59,400 a year. On Zendesk at $1.50 per resolution: about $7,500 a month, or $90,000 a year. On a custom agent: 5,000 tasks on a mid-tier model at a triage-sized prompt costs about $300 a month in tokens. Add $1,000 to $2,000 for infrastructure and monitoring, and you're at roughly $1,300 to $2,300 a month before the build cost. At that volume, the gap is roughly $2,600 to $6,200 a month. A custom build in the $15,000 to $30,000 range can pay for itself inside a year. At 300 tickets a month, it won't. Fin would cost you about $300 a month, and no custom build beats that. So our honest rule of thumb: Under about 1,000 resolutions a month: buy. Use the agent built into your helpdesk. Thousands of resolutions a month, or the agent needs to take actions in your own systems: build, or at least get a quote. The agent is the product you sell: build. You can't rent your core feature from a vendor who sets the price. So, What Should You Actually Pay for an AI Agent in 2026? Here's where we'd land for most small and mid-sized businesses: Testing an idea: $0 to $200 a month on a no-code platform. Spend a month proving people will use it. Customer support on a standard helpdesk: $0.99 to $2.00 per resolution. Negotiate committed-volume pricing once you know your numbers. A custom agent tied to your systems: a build fee based on clear hours at a fair rate, then a monthly running cost you can predict from token math plus infrastructure. Paying $90,000 for a first agent with no hour breakdown and no running-cost estimate is the thing to avoid. Not because the agency is dishonest, but because you can't tell whether the price matches the work. Red Flags in an AI Agent Quote No hour breakdown, just a single number. No estimate of monthly token and hosting costs. Locked to one model provider with no way to switch. No test plan using your real past conversations. No answer to "what happens when the agent is wrong?" A per-resolution contract that doesn't define "resolution." If a quote has two or more of these, ask for a revised one before you compare prices. For a wider view of how development pricing works, see our breakdown of what a dedicated development team costs in 2026 and our best tech stack picks for SaaS startups . Get a Clear AI Agent Quote from Craxinno Craxinno is an AI-first design and development studio. We've been building software since 2017, and we price AI agent work the way this article recommends: hours you can see, at $25 an hour, with a running-cost estimate before you commit. If you want a second opinion on a quote you've already received, send it over. We'll tell you if it's fair. Talk to us about your AI agent project → Sources Fin: AI Agent Pricing Comparison 2026 SaaStr: Salesforce now has 3 pricing models for Agentforce Dupple: How Much Does It Cost to Build an AI Agent in 2026? Cleveroad: AI Agent Development Cost in 2026
RAGHow to Build a RAG Chatbot with the OpenAI API (Tutorial)
How to Build a RAG Chatbot with the OpenAI API (Tutorial) A RAG chatbot answers questions from your documents instead of from whatever the model memorised during training. You split your content into chunks, turn each chunk into an embedding, store them, retrieve the closest chunks for every question, and pass them to the model as context. With the OpenAI API you can do this in two ways: the managed file_search tool, or a do-it-yourself pipeline with embeddings. This tutorial builds both in Python, then shows what changes when you take it to production. What is a RAG chatbot (and why not just fine-tune)? RAG (retrieval-augmented generation) is a pattern where the app looks up relevant passages from your own data at question time and gives them to the language model as context, so the answer is grounded in those passages rather than in the model's training data. Picture a support bot asked, "Do you offer refunds after 30 days?" A plain LLM will guess. It sounds confident, and it may be wrong. A RAG bot first pulls the refund section of your policy PDF, then answers from that text and can point to the source. Fine-tuning changes how a model writes. It is a poor way to teach it facts that change every month. If your pricing page, product docs or HR policy gets edited, RAG picks up the change the moment you re-index the file. A fine-tuned model needs another training run. For a chatbot that has to be correct about your business , retrieval is almost always the first thing to build. How a RAG chatbot works: the 5-step pipeline Ingest your sources (PDFs, Markdown, help-centre pages, database rows). Chunk them into passages of a few hundred tokens with some overlap. Embed each chunk into a vector with an OpenAI embedding model and store it. Retrieve the top-k chunks closest to the user's question. Generate an answer with the model, using only the retrieved chunks, and cite them. Everything else (re-ranking, hybrid search, query rewriting, evaluation) is a refinement of one of these five steps. Two ways to build it with the OpenAI API Option A: Managed file_search Option B: DIY embeddings Setup time Minutes A few hours Chunking & embedding Handled by OpenAI You control it Where vectors live OpenAI vector store Your database (pgvector, Qdrant, Pinecone, etc.) Metadata filters, custom ranking Limited Full control Best for Prototypes, internal tools, small to medium document sets Multi-tenant SaaS, strict data residency, large or fast-changing data Our view after shipping both: start with Option A to prove the bot is useful, then move to Option B only when you hit a concrete limit (tenant isolation, filtering, cost at scale, or data that cannot leave your infrastructure). Prerequisites Python 3.10 or newer An OpenAI API key stored as the OPENAI_API_KEY environment variable A folder of documents to test with (a product manual or FAQ export works well) 1 pip install openai numpy tiktoken In the code below, the chat model is read from an OPENAI_MODEL environment variable. Set it to a current model from OpenAI's models page, since model names change more often than this tutorial will. Option A: Build a RAG chatbot with the Responses API and file_search This is the fastest route. OpenAI's file search tool parses your files, chunks them, embeds them and runs the search for you. You get a working bot in roughly 40 lines. Step 1: Upload files and create a vector store 1 2 3 4 5 6 7 8 9 10 11 12 13 from pathlib import Path from openai import OpenAI client = OpenAI ( ) vector_store = client . vector_stores . create ( name = "company_knowledge_base" ) for path in Path ( "docs" ) . glob ( "*.pdf" ) : with open ( path , "rb" ) as f : uploaded = client . files . create ( file = f , purpose = "assistants" ) result = client . vector_stores . files . create_and_poll ( vector_store_id = vector_store . id , file_id = uploaded . id , ) print ( path . name , result . status ) # expect "completed" print ( "Vector store ID:" , vector_store . id ) What goes wrong: scanned PDFs with no text layer index as almost nothing. If a file "completes" but the bot never finds anything in it, run OCR on it first. Step 2: Ask questions with the file_search tool 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 import os MODEL = os . environ [ "OPENAI_MODEL" ] VECTOR_STORE_ID = "vs_..." # from step 1 SYSTEM = ( "You are the support assistant for our company. " "Answer only from the provided files. " "If the files do not contain the answer, say you don't know " "and suggest contacting support. Keep answers short." ) def ask ( question , previous_id = None ) : response = client . responses . create ( model = MODEL , instructions = SYSTEM , input = question , tools = [ { "type" : "file_search" , "vector_store_ids" : [ VECTOR_STORE_ID ] , "max_num_results" : 5 , } ] , include = [ "file_search_call.results" ] , previous_response_id = previous_id , ) return response r1 = ask ( "What is the refund window?" ) print ( r1 . output_text ) include=["file_search_call.results"] returns the matched chunks, so you can log them and show sources in your UI. max_num_results trades quality for cost: fewer chunks means fewer input tokens and faster replies, but a higher chance of missing the right passage. Five is a sensible starting point. Step 3: Keep the conversation going 1 2 r2 = ask ( "And does that apply to annual plans?" , previous_id = r1 . id ) print ( r2 . output_text ) Passing previous_response_id lets the API carry the chat history, so the follow-up "that" resolves to the refund window. No manual message list needed. That is a complete RAG chatbot. Wrap ask() in a FastAPI endpoint, put a chat widget on top, and you have an MVP. Option B: Build RAG from scratch with OpenAI embeddings Build it yourself when you need control: per-customer filtering, your own database, custom chunking for tables or code, or a hard rule that documents never leave your servers except as embedding requests. Step 1: Chunk your documents Chunking decides retrieval quality more than any other setting. Too large and each chunk mixes topics; too small and it loses the context needed to answer. 1 2 3 4 5 6 7 8 9 10 import tiktoken enc = tiktoken . get_encoding ( "cl100k_base" ) def chunk_text ( text , source , size = 400 , overlap = 60 ) : tokens = enc . encode ( text ) chunks = [ ] step = size - overlap for start in range ( 0 , len ( tokens ) , step ) : piece = enc . decode ( tokens [ start : start + size ] ) chunks . append ( { "text" : piece , "source" : source } ) return chunks Start around 300 to 500 tokens with 10 to 15% overlap. Better still, split on headings first (one H2 section per chunk), and only fall back to token windows for long sections. Structured splits keep a question and its answer in the same chunk. Step 2: Create embeddings 1 2 3 4 5 6 7 8 9 10 11 12 13 import numpy as np EMBED_MODEL = "text-embedding-3-small" def embed ( texts ) : resp = client . embeddings . create ( model = EMBED_MODEL , input = texts ) return np . array ( [ d . embedding for d in resp . data ] , dtype = np . float32 ) chunks = [ ] for path in Path ( "docs" ) . glob ( "*.md" ) : chunks += chunk_text ( path . read_text ( ) , source = path . name ) vectors = [ ] for i in range ( 0 , len ( chunks ) , 100 ) : # batch requests vectors . append ( embed ( [ c [ "text" ] for c in chunks [ i : i + 100 ] ] ) ) matrix = np . vstack ( vectors ) matrix /= np . linalg . norm ( matrix , axis = 1 , keepdims = True ) text-embedding-3-small returns 1,536-dimension vectors, accepts up to 8,192 input tokens, and is listed at $0.02 per million tokens ($0.01 with the Batch API) at the time of writing. Embedding a few thousand pages of docs usually costs cents, not dollars. Check OpenAI's pricing page before you quote a client. If retrieval quality on your data is weak, try text-embedding-3-large (3,072 dimensions) before rewriting anything else. Step 3: Retrieve the top-k chunks 1 2 3 4 5 6 def retrieve ( question , k = 5 ) : q = embed ( [ question ] ) [ 0 ] q /= np . linalg . norm ( q ) scores = matrix @ q # cosine similarity top = np . argsort ( - scores ) [ : k ] return [ ( chunks [ i ] , float ( scores [ i ] ) ) for i in top ] NumPy is fine for a few thousand chunks. Past that, move the vectors into a vector database: pgvector if you already run Postgres, or Qdrant, Weaviate or Pinecone if you want a dedicated service. The retrieval function stays the same shape; only the storage changes. Step 4: Generate a grounded answer with citations 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 def answer ( question , history = None ) : hits = retrieve ( question ) context = "\n\n" . join ( f "[{n}] ({c['source']})\n{c['text']}" for n , ( c , _ ) in enumerate ( hits , 1 ) ) prompt = ( "Answer the question using ONLY the context below. " "Cite sources like [1]. If the answer is not in the context, " "reply: \"I don't have that information.\"\n\n" f "Context:\n{context}\n\nQuestion: {question}" ) response = client . responses . create ( model = MODEL , input = ( history or [ ] ) + [ { "role" : "user" , "content" : prompt } ] , ) return response . output_text , hits text , sources = answer ( "How do I reset my password?" ) print ( text ) The "I don't have that information" line is the single most useful instruction in the prompt. Without it, the model fills gaps with plausible guesses, which is exactly the failure RAG is meant to stop. Step 5: Add memory for follow-up questions Follow-ups like "what about on mobile?" retrieve badly because the question alone has no subject. Fix it by rewriting the question before retrieval: 1 2 3 4 5 6 7 def standalone ( question , history ) : r = client . responses . create ( model = MODEL , input = history + [ { "role" : "user" , "content" : f "Rewrite this as a standalone question: {question}" } ] , ) return r . output_text Retrieve with the rewritten question, answer with the original one. This small step fixes a large share of "the bot forgot what we were talking about" complaints. Taking your RAG chatbot to production The demo works on day one. The work is in the next four weeks. These are the points we check on every RAG build at Craxinno: Build an evaluation set first. Write 30 to 50 real questions with known correct answers and the source they should come from. Re-run them after every change to chunk size, model or prompt. Without this you are tuning by vibes. Use hybrid search for names and codes. Embeddings are weak on exact strings like SKU numbers, error codes and people's names. Combine vector search with keyword (BM25) search and merge the results. Re-rank before you generate. Retrieve 20 candidates, re-rank them, and pass the best 5. Answers get sharper and you send fewer tokens. Filter by tenant and permission. In a multi-customer product, every chunk needs metadata (customer ID, role, document date) and every query must filter on it. One leaked chunk from another customer is a serious incident. Re-index on change. Hook ingestion to your CMS or storage events so edited documents are re-embedded automatically. Stale answers erode trust faster than "I don't know". Log retrieved chunks with every answer. When a user reports a wrong answer, you need to see whether retrieval or generation failed. They need different fixes. Stream responses. Use stream=True so text appears as it is generated. Perceived speed matters more than total latency in a chat UI. Common RAG mistakes (and quick fixes) Symptom Likely cause Fix Bot says "I don't know" when the answer exists Chunks too small or question phrased differently from the docs Larger chunks, heading-based splits, query rewriting Answers mix two unrelated topics Chunks too large Split by section, reduce chunk size Wrong product or SKU in the answer Pure vector search on exact identifiers Add keyword search (hybrid) Confident but invented answers Prompt allows answering outside context Explicit "only from context" rule and a fallback reply Costs climbing Too many chunks per query, long histories Lower top-k, re-rank, trim history How much does a RAG chatbot cost to run? Two meters run. Embeddings are cheap and mostly one-off: you pay once to index and again only for changed documents. The bigger, recurring cost is the chat model, because every question sends the retrieved chunks as input tokens. Five chunks of 400 tokens add about 2,000 input tokens per question before history. Cut top_k , trim history and pick a smaller model for simple FAQ traffic, and costs stay predictable. With managed file_search , also budget for vector storage and tool calls, which OpenAI prices separately on its built-in tools pricing page. Need a production-ready RAG chatbot? A tutorial gets you a working prototype. A chatbot your customers trust needs evaluation, permissions, monitoring and a UI people actually use. Craxinno designs and ships AI products end to end, from RAG pipelines and agentic workflows in Python (FastAPI, Django) to the web and mobile apps that sit on top. If you want a RAG chatbot built on your data, talk to our team .
SaaS DevelopmentBest Tech Stack for a SaaS Startup in 2026 (Our Picks)
Best Tech Stack for a SaaS Startup in 2026 (Our Picks) Short answer: the best tech stack for a SaaS startup in 2026 is TypeScript end to end. Next.js and React on the frontend, PostgreSQL for data, a managed auth provider, Stripe for billing, and Vercel or AWS for hosting. Add Python (FastAPI) only when your product does real AI or data work. Pick boring, popular tools, because your team and your AI coding assistant already know them. That's the whole recommendation. The rest of this guide explains why, where each piece breaks, and what we'd swap for different kinds of SaaS products. We've been building web apps , payment integrations and AI products at Craxinno since 2017, so the opinions below come from projects we've shipped, not from a vendor pitch. The Best SaaS Tech Stack for 2026 at a Glance Layer Our default pick Good alternative Switch when Language TypeScript Python (for AI/data services) You run models, RAG or heavy data pipelines Frontend Next.js + React SvelteKit, Remix Your team already ships fast in something else UI Tailwind CSS + shadcn/ui Material UI, Mantine You need a heavy enterprise data-grid look Backend / API Next.js route handlers or NestJS FastAPI, Hono A mobile app or third parties need a public API Database PostgreSQL (Supabase, Neon or AWS RDS) MySQL Almost never ORM Drizzle Prisma Your team prefers a schema-file workflow Auth Supabase Auth or Better Auth Clerk, Auth0 You need enterprise SSO out of the box Payments Stripe Paddle, Polar, Razorpay You want a Merchant of Record, or you bill in INR Hosting Vercel AWS, Railway, Coolify on a VPS Bills climb, or compliance needs a private cloud Email / analytics / errors Resend, PostHog, Sentry Postmark, Mixpanel, Better Stack Personal preference Why a "Boring" Tech Stack Wins in 2026 Two years ago the argument for popular tools was hiring. That still holds. But in 2026 there's a bigger reason: most of your code will be written or reviewed with an AI assistant, whether that's Cursor, Claude Code or GitHub Copilot. AI tools are very good at Next.js, PostgreSQL and Stripe. There are millions of public examples to learn from. They are noticeably worse at a niche framework that shipped a breaking change last quarter. So a mainstream stack now buys you speed twice: from humans and from machines. We see this on client projects every week. A founder arrives with an MVP built on an exotic combination (a new edge database, a beta auth library, a custom state manager). Each piece looked clever on its own. Together, nobody can debug them, and the AI assistant keeps suggesting code for the wrong version. The rule we follow: spend your novelty budget on the product, not the plumbing. Frontend: Next.js, React, TypeScript and Tailwind Next.js is the default SaaS frontend in 2026 for practical reasons. It handles your marketing site, blog, docs and logged-in dashboard in one codebase. Server rendering keeps your public pages fast and indexable, which matters if you plan to get customers from Google instead of only paid ads. Pair it with: TypeScript everywhere. Shared types between frontend and backend remove a whole class of bugs. Tailwind CSS for styling, and shadcn/ui for components you own and can edit, instead of a locked library. TanStack Query for data fetching on client-heavy screens. When would we skip Next.js? If your SaaS is a pure internal dashboard with no public pages and no SEO needs, a plain React + Vite single-page app is simpler to host and reason about. And if your team is already fast in Vue or Svelte, stay there. Switching frameworks to follow a blog post is a bad trade. Backend: Keep It in One Codebase as Long as You Can For most early SaaS products, the backend can live inside Next.js as route handlers and server actions. One repo, one deploy, one language. That's the fastest setup for a team of one to five developers. Split out a separate API when one of these becomes true: You're shipping a mobile app or browser extension that needs the same endpoints. Customers or partners need a documented public API. Long-running jobs (imports, reports, video or AI processing) start timing out serverless functions. At that point, NestJS or Hono keep you in TypeScript. If the heavy lifting is AI or data, use Python with FastAPI . It's where the AI libraries live, and FastAPI gives you typed, documented endpoints with very little code. We often run a TypeScript product app next to a small FastAPI service that only handles model calls, embeddings and data pipelines. It's a clean split that keeps each side in the language it's best at. Database: PostgreSQL, and Stop Worrying About It Use PostgreSQL. It handles relational data, JSON columns, full-text search, and vector embeddings through the pgvector extension . That last one matters: in 2026 most SaaS products add some AI search or retrieval feature, and Postgres lets you do it without a second database. Managed options that work well: Supabase if you want database, auth, storage and realtime in one place . Neon if you want serverless Postgres with database branching for preview environments. AWS RDS or Aurora if you're already on AWS or a client's security team requires it. Add Redis for caching, rate limits and sessions once you actually need it. Not on day one. What about MongoDB? It's fine for some products. But SaaS data is almost always relational: users belong to organizations, organizations have subscriptions, subscriptions have invoices. Forcing that into documents usually ends in painful joins written by hand. Pick MongoDB only if your core data really is schemaless. For the ORM, Drizzle is our current default because it stays close to SQL and is light on serverless. Prisma is still a solid choice with a gentler learning curve. Authentication: Don't Build It Yourself Login looks like a weekend task. Then come password resets, email verification, Google sign-in, magic links, two-factor auth, team invites, roles, and session security. Every hour on that is an hour not spent on the thing customers pay for. Supabase Auth is the easy pick if you're on Supabase already. Better Auth is an open-source TypeScript library that runs in your own app and database, with organizations and roles built in. Good for B2B SaaS. Clerk or Auth0 give you polished hosted UI and enterprise SSO, at a per-user price that grows with you. Check their pricing pages against your expected user count before you commit. Whichever you choose, design for multi-tenancy from the start: every row that belongs to a customer carries an organization ID, and every query filters by it. Retrofitting this later is one of the most expensive rewrites we see. Payments and Billing: Stripe, or a Merchant of Record Stripe is still the default for SaaS billing . Subscriptions, usage-based pricing, trials, coupons, invoices and the customer portal are all there. In the US its standard card fee is 2.9% + 30¢ per transaction . The real decision is whether you need a Merchant of Record like Paddle, Polar or Lemon Squeezy. They charge a higher fee, but they become the legal seller and handle global sales tax and VAT for you. For a solo founder selling to customers in dozens of countries, that's often worth it. For founders in India billing Indian customers, Razorpay handles UPI, cards and recurring payments in INR . Plenty of our clients run Razorpay for domestic customers and Stripe for international ones. It's more setup, but it covers both markets properly. One rule regardless of provider: treat webhooks as the source of truth for subscription status. Never trust the redirect after checkout alone. The AI Layer: What a 2026 SaaS Actually Needs Almost every SaaS brief we received this year had an AI feature in it . Smart search, a chat assistant over the customer's own data, document extraction, content generation. Here's the minimal setup that works: LLM APIs from Anthropic, OpenAI or Google, called through a thin wrapper so you can switch models without touching product code. pgvector in your existing Postgres for embeddings and retrieval (RAG) . You probably don't need a dedicated vector database until you're storing many millions of vectors. A job queue for anything slower than a few seconds. Trigger.dev or Inngest are simple for TypeScript teams. RabbitMQ or Celery fit Python-heavy pipelines. GPU hosting such as RunPod only if you run open-source or fine-tuned models yourself, for example image generation. Start with hosted APIs. Self-hosting models makes sense later, once you know your volume and the API bill is a real line item . Hosting and DevOps: Vercel First, AWS When It Pays Off Deploy to Vercel at the start. Git push, preview URLs for every branch, zero server management. For a pre-revenue startup that's the right trade. Move parts of the system to AWS (or GCP or Azure) when: Your hosting bill grows faster than your revenue. Enterprise customers ask for data residency, a VPC or specific compliance controls. You run background workers, queues or GPU jobs that don't fit serverless. A middle path that's grown popular: Coolify or Railway on top of a cheap VPS, which gives you a Vercel-like workflow at server prices. What to skip early: Kubernetes and microservices. A modular monolith with clear folders for billing, auth and each product area will carry you far further than most founders expect. You can split services when a real scaling problem shows up, and you'll know exactly where the seams are by then. The Supporting Tools Every SaaS Needs Before Launch Email: Resend or Postmark for transactional email, with React Email for templates. Product analytics: PostHog. It covers events, funnels, session replay and feature flags in one tool. Error tracking: Sentry. You want to hear about a failed checkout before the customer emails you. File storage: any S3-compatible bucket, such as AWS S3 or Cloudflare R2. CI: GitHub Actions running type checks, tests and migrations on every pull request. Most of these have free tiers. Before launch, your monthly stack bill can be close to zero beyond a domain name. Best Tech Stack by SaaS Type Type of SaaS Recommended stack B2B dashboard / workflow tool Next.js, NestJS or route handlers, PostgreSQL, Better Auth with organizations, Stripe, Vercel AI-first SaaS Next.js frontend, FastAPI service, PostgreSQL + pgvector, job queue, LLM APIs, AWS or Railway for workers Mobile-first SaaS React Native (Expo) + Next.js web , shared TypeScript API, Supabase, RevenueCat or Stripe Marketplace Next.js, PostgreSQL, Stripe Connect, Redis, background jobs for payouts and notifications Data / analytics SaaS Next.js, Python ETL pipelines, PostgreSQL plus a warehouse or Parquet files for heavy queries India-focused SaaS Next.js, PostgreSQL, Razorpay subscriptions, AWS Mumbai region for data locality Six Tech Stack Mistakes We See SaaS Founders Make The Frankenstein stack. Auth from one vendor, database from another, a third tool syncing users between them. Pick tools that work together. Microservices at ten users. You'll spend months on infrastructure that a single app handles easily. Building auth and billing from scratch. Use the services above and ship the product. Skipping multi-tenancy. Adding organization IDs to every table after launch is slow and risky. Choosing by hype. A framework trending this month is not a reason to bet your company on it. No monitoring until something breaks. Sentry and PostHog take an afternoon to set up. Do it before launch. Need Help Picking or Building Your SaaS Stack? The best tech stack for a SaaS startup is the one your team can ship and maintain without a fight. If you're planning a SaaS product and want a second opinion on architecture, or a team to build the MVP , Craxinno designs and ships full-stack web apps, AI features and payment integrations for startups worldwide. Browse more engineering guides on the Craxinno blog .
© 2026 — Craxinno Technologies
