© 2026 — Craxinno Technologies
Notes from the studio — case studies, design process, engineering retrospectives, and the occasional cosmic detour.
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 .
050stories
Short answer: a dedicated development team costs between $10,000 and $200,000+ per month in 2026. The spread comes down to two things: where your engineers sit and how many of them you need. A small MVP team of 3–4 people runs roughly $9,000–$26,000 a month offshore (India, Ukraine, Poland) and $30,000–$45,000 in the US. That range is wide enough to be useless on its own. So below you'll find the actual hourly rates by region and role, three real team configurations priced out, the hidden costs that quietly add 20–30% to most quotes, and a simple formula to calculate your own budget before you talk to a single vendor. We run a dedicated-team practice at Craxinno , a Jaipur-based studio that has been building software since 2017. We'll show you our own pricing too, so you have one number in the market that isn't hidden behind a "contact us" button. Dedicated Development Team Cost at a Glance (2026) Here's the monthly cost of one full-time engineer (about 160 billable hours) by region. These figures come from 2026 market surveys published by outsourcing vendors including N-iX/Ncube and Integrio . Region Hourly rate Monthly cost per developer North America $100–$175 $16,000–$28,000 Western Europe $75–$120 $12,000–$20,000 Eastern Europe $45–$80 $7,500–$13,000 Latin America $35–$65 $6,000–$11,000 South & Southeast Asia (India, Vietnam) $25–$50 $4,000–$8,500 Notice the gap. A senior engineer in San Francisco and a senior engineer in Jaipur can ship the same React app. One costs you roughly four times more per month. That's the whole reason the dedicated team model exists. What Is a Dedicated Development Team, Exactly? A dedicated development team is a group of engineers, designers, and QA specialists hired through a vendor who work only on your product, full-time, for months or years. You direct the work. The vendor handles hiring, payroll, office, equipment, HR, and replacements. Here's how it compares with the other ways to hire: Fixed-price project: you agree on a scope and a price up front. Good for a defined MVP . Painful when requirements change (and they always change). Staff augmentation: you rent one or two engineers to plug gaps in your existing team. Dedicated team: you get a full, stable unit (developers, QA, often a PM) that behaves like your own in-house department. In-house hiring: you recruit and employ everyone yourself , with salaries, benefits, recruiting fees, and months of hiring time. If your product will need continuous development for six months or longer, the dedicated model is usually the cheapest way to get a team that actually knows your codebase. Hourly Rates by Role (2026) Not every seat costs the same. A DevOps engineer is priced very differently from a junior front-end developer. Here are typical 2026 hourly rates across the three most popular outsourcing regions: Role Asia Latin America Eastern Europe Junior developer $12–$22 $15–$25 $20–$35 Mid-level developer $22–$38 $30–$50 $40–$65 Senior developer $38–$60 $55–$80 $65–$100 QA engineer $15–$30 $20–$40 $25–$55 DevOps engineer $30–$55 $45–$75 $55–$90 Project manager $25–$45 $35–$60 $45–$75 One practical tip: you rarely need an all-senior team. A ratio of roughly one senior to two mid-level developers keeps code quality high and can bring your blended rate down by as much as 20%. The senior reviews, the mid-levels build. It works. How Much Does a Dedicated Team Cost Per Month? 3 Real Configurations Rates are abstract. Teams are what you actually pay for. Here's how the monthly bill looks for three common setups. 1. Small MVP team (3–4 people) Who's on it: 2–3 developers (say, one React and one Node.js), a QA engineer (often part-time), and a part-time PM. Region Monthly cost USA $30,000–$45,000 Eastern Europe (Poland, Ukraine) $9,000–$18,000 Asia (India) $10,000–$26,000 This is the team for getting a first version in front of users in 3–4 months. You'll want your own product owner or tech lead making decisions; the team executes. 2. Mid-size SaaS team (6–9 people) Who's on it: a PM, a business analyst, 2 front-end developers, 1–2 back-end developers, a UI/UX designer, manual and automation QA, and a DevOps engineer. Region Monthly cost USA $80,000–$120,000 Canada $65,000–$95,000 Poland $35,000–$50,000 Asia $24,000–$56,000 At this size you're running a real product : weekly releases, a proper CI/CD pipeline, and someone whose whole job is making sure nothing breaks in production. 3. Enterprise team (10+ people) Who's on it: a tech lead or architect, PM, BA, 5–6 developers across stacks, UI/UX, 2 automation QA, DevOps, and a cloud engineer. Often split into pods per product area. Region Monthly cost USA $150,000–$220,000 Eastern Europe $45,000–$95,000 Asia $55,000–$120,000+ What We Charge at Craxinno (Real Numbers) Most agency articles on this topic end with "contact us for a quote." We'd rather just tell you. Craxinno bills dedicated engineers at $25 per hour . At a standard 160-hour month, that's $4,000 per full-time team member . So: 2 developers (starter pod): about $8,000/month 3 developers + 1 QA (MVP team): about $16,000/month 5 developers + QA + designer (growth team): about $28,000/month Same rate across web, mobile, AI/GenAI, and cloud work . No AI premium, no separate line for the account manager. If you're comparing quotes, put this number next to the others and ask each vendor what's included. That question alone tells you a lot. What Drives the Cost Up (or Down)? Location is the biggest lever. It isn't the only one. Tech stack. Common stacks like React, Node.js, Laravel, or Python/Django have deep talent pools and stable rates. Niche skills (Rust, blockchain, computer vision, LLM fine-tuning) cost more because fewer people can do them well. Some vendors add a 20–30% premium for AI/ML pods . Seniority mix. Covered above. An all-senior team is a luxury most products don't need. Engagement length. Commit to 6–12 months and many vendors drop their monthly rate by 10–15%. Month-to-month flexibility costs extra. Who leads. A vendor that provides a CTO-level architect who makes technical decisions charges 15–25% more than an execution-only team. Worth it if you don't have a technical co-founder. Wasted money if you do. Time-zone overlap. Want your offshore team online for your entire US workday? Expect to pay for night-shift coverage. A 3–4 hour overlap window is usually enough, and it's free. The Hidden Costs Most Founders Miss You get a quote of $16,000/month. You budget $16,000/month. Three months later you've spent closer to $20,000 a month and you're not sure where it went. A safe rule: add 20–30% to any quote to cover these. Ramp-up time. Expect 2–4 weeks at full cost before the team hits full speed. They're reading your code and learning your domain. Your own management time. Someone on your side (founder, PM, or tech lead) will spend 3–8 hours a week on reviews, priorities, and answering questions. That time isn't free. Tooling and infrastructure. Jira, GitHub seats, Figma, staging servers, AWS bills, monitoring. These add up on long projects. Roles billed separately. Some vendors quote developer rates only , then add QA, DevOps, and PM on top. A vendor PM alone can add $2,000–$5,000/month. Get it in writing. Replacement fees. If an engineer leaves, some vendors charge to replace them. Good ones don't. Legal and compliance. Contract review, NDAs, IP assignment, and security audits if you're in healthcare, fintech, or another regulated space. Dedicated Team vs. In-House Hiring: The Real Comparison A senior software engineer in the US commonly earns well into six figures. Then add benefits, payroll taxes, equipment, office space, and a recruiter fee that's often 15–25% of first-year salary. And you'll wait 2–3 months to fill each seat. A dedicated team skips most of that. No recruiting fees, no benefits, no severance. You can usually start within 1–3 weeks and scale up or down with a month's notice. The trade-off is control and context. Your in-house engineers sit in your Slack all day and absorb the business. A dedicated team needs clear documentation, regular calls, and a single point of contact on your side. Give them that and the gap closes fast. Factor In-house team Dedicated team Freelancers Time to start 2–4 months 1–3 weeks Days Hiring & HR overhead You Vendor You Scaling up/down Slow, costly ~1 month notice Fast, unstable Long-term product knowledge High High Low Replacement if someone leaves You re-hire Vendor replaces Start over How to Calculate Your Dedicated Team Budget Use this formula before you request any quotes: Monthly budget = (number of team members × hourly rate × 160) × 1.25 The 1.25 covers the hidden costs above. Example: a team of 4 at $25/hour = 4 × 25 × 160 = $16,000, times 1.25 = $20,000/month all-in . Multiply by your expected timeline ( an MVP usually takes 3–6 months ) and you have a real number to take to your board, your co-founder, or your bank. Then work backwards: Define the first milestone. Not the full product. Just the first version real users can touch . List the roles that milestone needs. A mobile app needs a mobile developer. A data dashboard needs a back-end developer who's comfortable with SQL. Don't hire roles you won't use for 3 months. Pick your region based on budget, time-zone needs, and language. Run the formula. If the number's too high, cut scope before you cut seniority. How to Reduce Costs Without Hurting Quality Start smaller than you think. Two good engineers for the first month will tell you more about the vendor than any sales call. Use a blended seniority mix. One senior for every two mid-level developers. Sign a longer commitment once the trial month goes well, to unlock a 10–15% discount. Write things down. Clear tickets and a short product spec cut ramp-up time in half. Vague tickets are the most expensive thing in outsourcing. Own the repo and cloud accounts from day one. It costs nothing and saves you a painful handover later. Red Flags When Choosing a Dedicated Team Provider They won't share hourly rates until after three calls. You can't interview the actual engineers who'll work on your project. The contract doesn't clearly assign IP and source code to you. There's no trial period or a very long notice period to exit. They quote a fixed "team price" but won't say which roles it includes. Every portfolio project looks like a template . The single best question to ask any vendor: "Who reviews the code and makes architecture decisions on my project?" If the answer is vague, the price doesn't matter . So, What Should You Budget? If you're a startup building an MVP, plan for $9,000–$26,000 a month with an offshore team in India, Southeast Asia, or Eastern Europe. If you're scaling an existing SaaS product , plan for $25,000–$60,000 offshore. And if you're hiring in the US, multiply those numbers by three or four. Want an exact figure for your project? Talk to the Craxinno team . Tell us what you're building and we'll send you a team plan with roles, timeline, and a monthly cost based on our $25/hour rate. You can also browse more guides on our blog .
Quick answer: Choose a traditional CMS (like WordPress, Wix or Shopify) if you need a marketing site or store live fast, on a modest budget, managed by non-technical editors. Choose a headless CMS (like Sanity, Contentful, Strapi or Storyblok) if you publish the same content to several channels — website, mobile app, kiosks, AI assistants — need top-tier performance, or want full control over the front end with a developer team to support it. If you're somewhere in between, a hybrid setup (such as headless WordPress with a Next.js front end) often gives you the best of both. The rest of this guide explains the trade-offs in plain terms, shows real 2026 numbers, and ends with a five-question test you can use to make the call in minutes. What is a traditional CMS? A traditional (or "monolithic" / "coupled") CMS keeps everything in one system: the database where content lives, the admin panel where editors write, and the theme that renders pages for visitors. You write a post, pick a template, press publish — and the CMS builds the page. WordPress, Drupal, Joomla, Wix, Squarespace and Shopify all work this way by default. Traditional CMSs still run a huge share of the web. According to W3Techs (October 2026), WordPress powers about 39.5% of all websites and 58.3% of sites using a known CMS , followed by Shopify (5.3%) and Wix (4.2%). That popularity matters: it means a large talent pool, thousands of themes and plugins, and answers to almost any problem a quick search away. Strengths Fast to launch — themes and page builders get a site live in days. Editor-friendly — what you see in the editor is close to what visitors see. Low starting cost — cheap hosting and free or low-cost plugins. Huge ecosystem — SEO, forms, e-commerce and analytics plugins out of the box. Weaknesses Front end and back end are tied together, so big design changes often mean fighting the theme. Plugin sprawl slows sites and adds risk. Patchstack's State of WordPress Security report counted roughly 8,000 new vulnerabilities in the WordPress ecosystem in 2024, with the vast majority in plugins , not WordPress core ( SecurityWeek coverage ). Content is shaped around pages , which makes reusing it in an app, a smartwatch or an AI chatbot awkward. What is a headless CMS? A headless CMS removes the "head" — the presentation layer. It stores and organises content, then serves it through an API (REST or GraphQL). Developers build the front end separately, usually with frameworks like React or Next.js , and pull content from the API. Think of it like a restaurant kitchen that no longer has its own dining room. The kitchen (your content) can now deliver to a website, a mobile app, a digital signboard and a voice assistant — all from one source. Popular options in 2026 include Sanity, Contentful, Strapi, Storyblok, Payload and Hygraph. Strengths Omnichannel by design — write once, publish everywhere. Front-end freedom — use any framework and design without theme limits. Performance — static generation, edge caching and modern frameworks make very fast pages achievable. Smaller attack surface — the public site doesn't expose an admin panel or plugin layer. Structured content — clean, typed fields that are easy to feed into search, personalisation and AI tools. Weaknesses Needs developers to build and maintain the front end. Higher upfront cost and longer build time. Editors can lose live visual preview unless the team sets it up (most leading platforms now offer visual editing, but it takes configuration). More moving parts — hosting, API, front end and build pipeline to manage. Headless vs traditional CMS: side-by-side comparison Factor Traditional CMS Headless CMS Architecture Content + presentation in one system Content backend only; front end built separately via API Time to launch Days to a few weeks Several weeks to months Upfront cost Low Medium to high Editor experience Visual, familiar, WYSIWYG Form-based by default; visual editing needs setup Design flexibility Limited by theme/builder Unlimited Performance Good with tuning; plugin bloat is common Excellent potential with static/edge delivery Security Larger attack surface (plugins, admin exposed) Smaller public attack surface Multi-channel delivery Difficult Built in Scalability Needs caching and hosting upgrades Scales well via CDN and decoupled services SEO Easy via plugins Excellent, but developers must implement meta, sitemaps, schema Developer dependency Low High Best for Blogs, brochure sites, small stores Products, apps, multi-brand, high-traffic platforms Is a headless CMS better for SEO? Not automatically. A headless CMS gives you the potential for better SEO because you control every line of HTML and can ship very fast pages — and page experience and Core Web Vitals do matter. But a traditional CMS gives you SEO basics for free : plugins handle meta titles, XML sitemaps, canonical tags, redirects and schema markup. In a headless build, developers must build each of these. Teams that skip this step often launch a beautiful, fast site that ranks worse than the old WordPress one. Rule of thumb: headless wins on SEO when your team implements server-side rendering or static generation, plus metadata, sitemaps, structured data and redirects from day one. If no one owns that work, stay traditional. What does each option really cost in 2026? Exact numbers depend on scope, but here's how the costs are shaped differently: Traditional CMS Build: theme customisation and plugin setup — lowest upfront cost. Running costs: hosting, premium plugins/themes, and regular updates. Hidden cost: plugin maintenance, security patching and performance clean-ups as the site grows. Headless CMS Build: content modelling, a custom front end and integrations — higher upfront cost. Running costs: CMS subscription (many have free tiers; paid plans rise with users, locales and API usage), front-end hosting (e.g. Vercel, Netlify or AWS) and developer time. Hidden cost: every new page type or feature usually needs developer work. The honest takeaway: a traditional CMS is cheaper to start . A headless CMS can be cheaper to scale when you're serving multiple channels or high traffic, because you avoid rebuilding content for each platform. When should you choose a traditional CMS? Pick a traditional CMS if most of these sound like you: You need a website live in weeks, not months. Your content team is non-technical and wants to publish without help. You only publish to one website. Your budget is limited and you don't have in-house developers. You need a standard blog, company site, portfolio or small online store. Example: A local clinic, restaurant or consultancy that needs a fast, good-looking site with a blog and contact form. WordPress or Wix will do the job well at a fraction of the cost. When should you choose a headless CMS? Pick a headless CMS if most of these sound like you: You publish to a website and a mobile app (or more channels). You run multiple brands, regions or languages from one content hub. Performance and design control are business-critical — for example, high-traffic marketing or e-commerce. You have (or can hire) developers comfortable with React, Next.js or similar. You want to feed structured content into search, personalisation or AI assistants. Example: A SaaS company with a marketing site, docs, in-app help and a mobile app — all pulling the same product content from one headless CMS so every channel stays in sync. The middle path: hybrid and headless WordPress You don't have to pick an extreme. Two popular in-between options: Headless WordPress — keep WordPress as the editing backend your team already knows, and build the front end in Next.js using the WordPress REST API or WPGraphQL. You keep the familiar editor and gain speed and design freedom. Hybrid CMS — platforms that offer both a traditional page-building experience and content APIs, so marketers get visual editing while developers get API access. This is often the smartest route for businesses already invested in WordPress who want a faster, more modern front end without retraining their editors. The 5-question test: which CMS is right for you? Answer yes or no: Will your content appear on more than one channel (site, app, kiosk, AI assistant) in the next 12–24 months? Do you have, or plan to hire, front-end developers ? Is page speed or custom design a direct revenue driver for you? Do you manage multiple brands, regions or languages ? Is your budget and timeline flexible enough for a longer build? 0–1 yes → Traditional CMS. Speed and simplicity win. 2–3 yes → Hybrid / headless WordPress. Keep your editors happy and modernise the front end. 4–5 yes → Headless CMS. You'll grow into its flexibility. Thinking about migrating? A quick checklist Moving from a traditional to a headless CMS is where many projects lose traffic. Protect yourself: Audit content first — remove what's outdated before you migrate it. Design the content model — turn pages into reusable fields and content types. Map every URL and set up 301 redirects for any that change. Rebuild SEO essentials — metadata, sitemaps, canonicals and schema. Set up previews so editors can see changes before publishing. Migrate in phases — start with one section, measure, then expand. Benchmark before and after — compare rankings, traffic and Core Web Vitals. Frequently asked questions Is WordPress a headless CMS? Not by default — it's a traditional CMS. But it can be used headlessly through its REST API or WPGraphQL, with a separate front end built in a framework like Next.js. Is a headless CMS more secure? Generally, yes, for the public site. Because the content backend isn't directly exposed to visitors and there's no plugin-heavy theme layer, the attack surface is smaller. You still need to secure API keys, user roles and hosting. Is headless CMS good for small businesses? Usually not as a first website. Most small businesses get better value from a traditional CMS. Headless makes sense once you need multiple channels, very high performance or custom experiences. Does a headless CMS help with AI search and chatbots? It can. Structured, well-labelled content is easier to feed into AI assistants, RAG systems and personalisation tools than page-based HTML. That said, no CMS guarantees visibility in AI search results — content quality still matters most. How long does a headless CMS project take? It depends on scope, but expect longer than a theme-based site because the front end is built from scratch. A focused marketing site can take a few weeks; a multi-channel platform can take months. Can I switch from a traditional CMS to headless later? Yes. Many teams start on WordPress and later move to headless WordPress or a dedicated headless CMS. Planning a clean content structure early makes that move much easier. Final verdict There's no universal winner in the headless CMS vs traditional CMS debate — there's only the right fit for your team, budget and growth plans. Need speed, simplicity and a low budget? Go traditional. Need omnichannel delivery, performance and design control? Go headless. Want both? Go hybrid or headless WordPress. Not sure which path fits your project? Craxinno's web development team designs and builds both — fast WordPress and Shopify sites, and custom headless builds with React and Next.js. Talk to our team and we'll help you pick the right architecture before you commit to a build.
Quick answer: A solid AWS S3 backup strategy in 2026 has four layers. Turn on S3 Versioning with lifecycle limits. Run AWS Backup with continuous plus snapshot rules. Copy recovery points into a logically air-gapped vault in a separate account and Region. Then test restores on a schedule, because an untested backup is a guess. That's the whole strategy in one paragraph. The rest of this guide covers the decisions behind each layer, what each one costs, and the gaps AWS doesn't advertise loudly. Key takeaways S3's 11 nines of durability protects you from AWS losing your data. It does nothing when you (or an attacker with your keys) delete it. Replication is not a backup. It copies mistakes as fast as it copies good data. AWS Backup's continuous mode gives point-in-time restore for up to 35 days. Snapshots cover anything longer, up to 99 years. The low-cost warm tier (launched November 2025) cuts long-term S3 backup storage by up to 30%. Since August 2026 you can read backup data through S3 Access Points without running a full restore. That changes how cheaply you can test. Why "11 nines" isn't an S3 backup strategy Here's the conversation we keep having with founders. "We're on S3. It's 99.999999999% durable. Why would we need backups?" Then picture this. A developer runs a cleanup script against the wrong bucket on a Friday evening. Or an IAM access key leaks in a public repo, and someone encrypts or deletes every object they can reach. S3 performs those deletes with the same 11-nines reliability it uses to store your files. Durability worked perfectly. Your data is still gone. Durability is a promise about hardware. A backup is a promise about your ability to undo things . Those are different contracts, and the AWS shared responsibility model puts the second one on you. So the real question for an AWS S3 backup strategy is: what are you recovering from? Start with the threat model, not the tools Most S3 backup setups we audit were built tool-first. Someone enabled versioning, someone else added replication, and nobody wrote down what failure each piece was supposed to handle. Flip it. List the failures, then pick the control. Failure you need to survive What actually protects you What does NOT Accidental overwrite or delete of a few objects S3 Versioning Replication (it replicates the overwrite) Bad deploy corrupts thousands of objects over hours AWS Backup continuous (point-in-time restore) Versioning alone (painful to roll back at scale) Leaked credentials, ransomware, malicious insider Immutable copy in a separate account (air-gapped vault, Object Lock compliance mode) Anything in the same account the attacker controls Full Region outage Cross-Region copy or Cross-Region Replication Same-Region backups Compliance audit asking for 7-year retention AWS Backup snapshots with Vault Lock Lifecycle rules that quietly expire data Then set two numbers for each data set: RPO (Recovery Point Objective): how much data you can afford to lose. 15 minutes? A day? RTO (Recovery Time Objective): how long you can be down while restoring. Don't set one RPO for the whole company. Your user-uploaded files and your build-artifact bucket deserve very different treatment, and pricing them the same is how backup bills get out of hand. The 11 AWS S3 backup best practices for 2026 1. Tier your buckets before you back up anything Tag every bucket with a data tier. We use three: Tier 1: data the business can't run without (customer uploads, invoices, medical or financial records). Continuous backup, air-gapped copy, tight RPO. Tier 2: important but rebuildable with effort (analytics exports, processed media). Daily snapshots, cross-Region copy. Tier 3: reproducible from source (build artifacts, caches, logs you already ship elsewhere). Versioning with short retention, or no backup at all. Skipping backup for Tier 3 is a legitimate decision. Write it down so it reads as a choice, not an oversight. 2. Turn on versioning, then put a ceiling on it AWS Backup for S3 requires S3 Versioning. So does Object Lock. That makes versioning non-negotiable. But versioning without lifecycle rules is a slow cost leak. Every overwrite keeps the old copy forever. On a bucket that rewrites the same JSON file every minute, you'll pay for roughly 43,000 versions of it per month. Two lifecycle rules fix most of this: 1 2 3 4 5 6 7 8 9 10 { "Rules" : [ { "ID" : "expire-noncurrent-versions" , "Status" : "Enabled" , "Filter" : { } , "NoncurrentVersionExpiration" : { "NoncurrentDays" : 30 } , "Expiration" : { "ExpiredObjectDeleteMarker" : true } , "AbortIncompleteMultipartUpload" : { "DaysAfterInitiation" : 7 } } ] } The ExpiredObjectDeleteMarker line matters more than it looks. AWS Backup bills each delete marker as if it were a 128 KiB object, so orphaned markers on a high-churn bucket add up. Pick the NoncurrentDays value with care. Once a version expires, AWS Backup can't restore it either. Your noncurrent retention should be at least as long as your shortest RPO window. (For the exact console and CLI steps, see our AWS S3 backup setup guide .) 3. Use AWS Backup with continuous and snapshot rules together AWS Backup has two modes for S3, and the right answer for Tier 1 data is both: Continuous backup tracks changes through EventBridge and lets you restore to any point in the last 35 days . This is your "undo the bad deploy from Tuesday at 14:20" button. Snapshot (periodic) backup runs on a schedule (hourly, daily, weekly, monthly) and can be retained for up to 99 years . When both rules sit in the same backup vault, AWS Backup builds snapshots from the continuous recovery point. You get long retention without scanning the whole bucket again or paying for duplicate storage. AWS's own guidance recommends this combined setup. Two setup traps we see often: EventBridge isn't enabled on the bucket. Continuous backup silently depends on it. Check with aws s3api get-bucket-notification-configuration and look for "EventBridgeConfiguration": {} . The same bucket sits in two backup plans with continuous rules. AWS supports one continuous backup per bucket. Keep continuous and periodic recovery points in the same vault. 4. Keep one copy outside the blast radius This is the practice that separates a real AWS S3 backup strategy from a checkbox. If your backups live in the same AWS account as production, anyone with admin on that account can delete them. Ransomware crews know this. They go after the backups first. The fix in 2026 is the AWS Backup logically air-gapped vault : Recovery points are locked by default and encrypted with AWS-owned keys, or with your own KMS key since November 2025. Since November 2025 you can send primary backups directly into the air-gapped vault, so you don't pay for a second copy in a standard vault first. With multi-party approval (June 2025), a team of approvers across your AWS Organization can grant recovery access even if the source account is fully compromised or locked out. AWS added six more Regions for these vaults in July 2026, so availability is much less of a blocker than it was at launch. Our default layout: production account, a dedicated backup account in a second Region, and the air-gapped vault in that backup account. Nobody's day-to-day IAM role touches the backup account. 5. Make backups immutable on purpose You have two immutability tools, and they protect different things. S3 Object Lock works on the bucket itself. In compliance mode , no user, including the root account, can delete or shorten retention on a locked object version until the retention date passes. In governance mode , users with s3:BypassGovernanceRetention can override it. Governance mode is fine for testing. For ransomware protection, use compliance mode, and be sure about the retention period, because you can't undo it. AWS Backup Vault Lock works on recovery points in the backup vault. In compliance mode it stops anyone from deleting backups early or changing the retention policy once the cooling-off period ends. For Tier 1 data, we'd use Vault Lock (or the air-gapped vault) on the backups and save Object Lock for buckets with a regulatory write-once requirement. Object Lock on a busy production bucket can lock you into paying for data you'd love to delete. 6. Don't confuse replication with backup S3 Cross-Region Replication (CRR) is excellent at one job: keeping a live copy in another Region for failover. With S3 Replication Time Control , AWS replicates 99.99% of objects within 15 minutes. But look at what it does with bad changes: Ransomware overwrites 2 million objects with encrypted versions. CRR copies the encrypted versions. An app bug writes empty files. CRR copies the empty files. Delete marker replication is optional. Permanent deletes of specific versions are never replicated, which helps a little, but an attacker with access to both buckets doesn't care. CRR also has no built-in point-in-time restore. Rebuilding a bucket "as of last Tuesday" from replicas means stitching together S3 Inventory and Batch Operations by hand. Use CRR when your RTO is minutes and you need a hot standby. Pair it with AWS Backup for the "go back in time" requirement. One is availability, the other is recoverability, and you usually need both. 7. Assign backups by tag, so new buckets aren't forgotten The bucket that loses data is rarely the one you planned for. It's the one a developer created six months ago for "a quick feature." Assign resources to AWS Backup plans by tag (for example backup-tier = tier1 ), not by listing bucket ARNs. Then enforce the tag: Add it to your Terraform or CloudFormation bucket module so every new bucket gets one. Use AWS Backup Audit Manager or an AWS Config rule to flag buckets that have no backup tier tag. For multi-account setups, push backup policies through AWS Organizations so new accounts inherit them. 8. Cut storage costs with the warm tier and smarter retention AWS Backup storage for S3 runs about $0.05 per GB-month in US East (N. Virginia), against $0.023 for S3 Standard itself. Backups can easily cost more than the bucket they protect. A few levers: Turn on the low-cost warm tier. Launched November 2025, it moves backed-up objects that have been in the vault at least 60 days to a tier about 30% cheaper (roughly $0.035 per GB-month in AWS's example), with the same restore speed. There's a one-time fee of about $0.01 per 1,000 objects to transition. Watch small objects. Objects under 128 KB are billed as 128 KB, even in the warm tier. A bucket of millions of tiny thumbnails is a bad warm-tier candidate, and sometimes a bad AWS Backup candidate overall. Exclude ACLs and object tags if you don't need them restored. AWS Backup lets you disable both in advanced backup settings. Delete expired recovery points and partial backups. They keep billing until they're gone. AWS published a worked example worth stealing for your own business case: 500 TB and 1 billion objects in US East, 80% of objects tiered. Monthly backup storage dropped from $25,600 to $19,456. The $8,000 transition fee pays for itself in under two months. 9. Get encryption and key access right Encryption is where restores fail at 2 a.m. SSE-S3 and SSE-KMS objects back up fine. With SSE-KMS, the AWS Backup role needs kms:Decrypt on the source key, and you'll see those calls in CloudTrail. SSE-C (customer-provided keys) is not supported by AWS Backup. If any of your buckets use it, you need a different backup path for those objects. If you use a customer-managed KMS key for an air-gapped vault, protect that key's policy as carefully as the vault itself. Losing the key means losing the backup. One more trap: if CloudTrail data events or S3 server access logs are enabled for a backed-up bucket, deliver them to a different bucket. Logging into the bucket being logged creates an endless write loop, and AWS Backup will dutifully back up every log line. 10. Know what AWS Backup does NOT back up This list surprises almost every team we review: Bucket configuration: bucket policies, CORS, lifecycle rules, access points and bucket settings are not included. Restore gives you objects, not the bucket as it was. S3 Glacier Flexible Retrieval and Glacier Deep Archive objects are not supported. Directory buckets (S3 Express One Zone) and S3 on Outposts are not supported. General purpose buckets only. Restored objects don't keep their original version ID, creation date, storage class, or ETag. The answer for bucket configuration is infrastructure as code. If your buckets live in Terraform or CloudFormation, the config is "backed up" in Git. If they were clicked together in the console, fix that before you need a restore. 11. Test restores like you mean it Every backup strategy looks great until the first restore. Teams find out during the incident that the IAM role can't decrypt the KMS key, or that the restore of 40 million objects needs a service limit increase, or that the "daily" backup job failed silently three weeks ago. What changed in 2026 is how cheap testing has become: Backup access points (August 2026). AWS Backup can now create read-only S3 Access Points on a recovery point. You can run GetObject , HeadObject and ListObjectsV2 against backup data directly, with no restore job. That's perfect for spot-checking files, validating data, or forensics after an incident. The recovery point can't be deleted while an access point is active. AWS Backup restore testing runs scheduled restores into an isolated environment and records whether they worked. Amazon GuardDuty Malware Protection for AWS Backup (November 2025) scans recovery points for malware before you restore, so you don't restore the infection along with the data. A simple cadence we recommend: automated restore tests monthly for Tier 1, quarterly for Tier 2, and one full game-day restore of a Tier 1 bucket every year with a stopwatch running. Compare the result against the RTO you wrote down in step one. Sample S3 backup strategies by company stage Not everyone needs the full stack on day one. Here's how we'd scale it. Early-stage startup Growing SaaS Regulated / enterprise Versioning + lifecycle Yes Yes Yes AWS Backup Daily snapshots, 30-day retention Continuous + daily snapshots Continuous + daily/monthly snapshots, multi-year retention Separate backup account Optional Yes Yes, with multi-party approval Air-gapped vault / Vault Lock Nice to have Yes for Tier 1 Required Cross-Region Backup copy only Backup copy + CRR for Tier 1 CRR with RTC + backup copy Restore testing Quarterly manual check Monthly automated Monthly automated + annual game day + audit reports If you're still picking your stack, our SaaS tech stack guide for 2026 covers where S3 fits next to your database and hosting choices. Common S3 backup mistakes we keep finding Backups in the same account as production. The single most common gap, and the one ransomware exploits. Lifecycle rules shorter than the RPO. Old versions expire before anyone notices the corruption. No alert on failed backup jobs. Wire AWS Backup job events to EventBridge and send failures to Slack or PagerDuty. Assuming Glacier objects are covered. They aren't. Never timing a restore. Your RTO is a guess until you've measured it. These are the same kind of quiet failures we wrote about in the real cost of bad software : cheap to prevent, very expensive to discover late. Need a second pair of eyes on your S3 backups? At Craxinno we design and ship cloud infrastructure for startups and growing businesses, including AWS Backup plans, multi-account setups and restore runbooks. If you'd like us to review your current setup against the checklist above, talk to our team and we'll tell you where the gaps are.
How to Hire AI Developers in India (2026 Guide) Quick answer: To hire AI developers in India in 2026, first define the exact AI role you need (LLM app developer, ML engineer, MLOps or data engineer), choose a hiring model (freelancer, agency, dedicated team or EOR hire), screen for shipped production work, run a short paid test, then lock IP and data terms before day one. Expect $25 to $75 an hour for most mid-to-senior work. That's the short version. The long version matters because "AI developer" now covers everything from someone who wires the OpenAI API into a chatbot over a weekend to an engineer who can fine-tune a model, build an evaluation suite and keep inference costs under control at 50,000 requests a day. Hire the first when you need the second and you'll find out three months and a few lakh rupees later. We've been building software out of Jaipur since 2017, and over the last two years most of our new briefs have had an AI component: RAG over company documents, agentic workflows, image generation pipelines on RunPod, Python back ends in FastAPI. This guide is what we'd tell a founder or CTO who asked us how to hire AI developers in India without getting burned, including the parts that don't flatter agencies like ours. Why companies hire AI developers in India in 2026 Cost gets the headlines. Depth is the better reason now. Talent volume: A NASSCOM–Deloitte report projects India's AI talent pool will reach about 1.25 million professionals by 2027, with the domestic AI market roughly tripling to $17 billion. Skill penetration: The Stanford AI Index 2025 ranks India second in the world for AI skill penetration (2015 to 2024), behind only the United States, and first for year-over-year AI hiring growth in 2024 at 33.4%. There's a catch in that same Stanford report. India scored -1.55 on net AI talent migration, meaning more AI professionals leave than arrive. The good people get poached, by GCCs, by foreign employers, by better-funded startups. So the real hiring problem in India isn't finding AI developers. It's identifying the strong ones fast and keeping them. Step zero: figure out which "AI developer" you need Most hiring mistakes we see start here. A founder posts a job for an "AI developer," gets 300 applications, and can't tell them apart because the role was never defined. Role What they actually build Hire them when AI / LLM application developer Chatbots, RAG over your documents , AI features inside web and mobile apps, API integrations with OpenAI, Anthropic or open models You want AI inside a product, quickly, using existing models AI agent developer Multi-step agentic workflows, tool calling, n8n or custom orchestration, human-in-the-loop approvals You're automating a business process end to end Machine learning engineer Custom models, fine-tuning, computer vision, forecasting, recommendation systems Off-the-shelf models don't solve the problem or your data is the moat MLOps engineer Deployment, GPU infrastructure, monitoring, model versioning, cost control Models are going to production and need to stay up Data engineer ETL pipelines, vector stores, data cleaning, warehouses Your data is messy (it almost always is) For most startups and SMBs in 2026, the first hire is an LLM application developer who is also a solid back-end engineer. Not a PhD researcher. You probably don't need to train a model at all, and a researcher who's bored building your CRUD layer will leave in six months. How to hire AI developers in India: 7 steps 1. Write the problem, not the job title Replace "Looking for an experienced AI developer" with something like: "We need a support assistant that answers questions from 4,000 help-centre articles and our Zendesk history, hands off to a human under 70% confidence, and costs under $0.02 per conversation." Now candidates can tell you how they'd build it. And you can compare answers. What goes wrong: vague briefs attract generalists who say yes to everything. Specific briefs make weak candidates self-select out. 2. Pick a hiring model Model Speed to start Best for Main risk Freelancer (Upwork, Contra, LinkedIn) Days Prototypes, one well-scoped feature No backup if they disappear; quality varies wildly Agency / development studio 1–2 weeks Full products where AI is one part of the build (design, front end, back end, AI) Paying for overhead if the agency doesn't specialise in AI Dedicated developer or team (staff augmentation) 1–3 weeks Long-running work under your own product manager You still own the management Direct hire via an Employer of Record (EOR) 4–8 weeks Core, long-term roles you want on your payroll Slow hiring, 30–90 day notice periods, counter-offers Our honest take: if AI is the core of your company, hire in-house eventually. If AI is a feature inside a bigger product, an agency or dedicated team gets you to production faster because you also need design, front end, DevOps and QA, and hiring all of those one by one is slow. 3. Screen for production evidence, not certificates Certificates and Kaggle ranks tell you someone can study. You want proof they've shipped. Ask every shortlisted candidate for one AI system that real users touched, then ask: How many users or requests did it handle? How did you measure whether answers were correct? What did it cost per request, and what did you do to bring that down? What broke after launch? Someone who has actually run AI in production answers the last question instantly, usually with a slightly pained smile. Hallucinated citations. A vector index that went stale. A prompt that worked in English and fell apart in Hinglish. Someone who has only built demos gets vague. 4. Run a short, paid practical test Skip the LeetCode round. Give a 4 to 6 hour task that mirrors your real work, and pay for it. Paying signals respect and gets you better candidates, especially senior ones who won't do free homework. A test we like for LLM application roles: "Here are 30 PDF policy documents and 20 questions with expected answers. Build a small RAG service with an API endpoint. Include a script that scores your answers against ours, and write half a page on what you'd change before production." The half-page matters more than the code. You're looking for someone who mentions chunking strategy, retrieval evaluation, citation of sources, cost per query and failure handling without being prompted. 5. Interview questions that separate engineers from API wrappers "When would you not use an LLM for this?" (Good engineers have opinions. Rules and regex still win sometimes.) "How would you evaluate a RAG system before launch?" (Listen for a test set, retrieval metrics and human review, not "I'd try some questions.") "Our token bill doubled last month. Walk me through what you'd check." (Caching, prompt length, model routing, retries.) "How do you stop prompt injection in an agent that can send emails?" (Permission scoping and human approval for risky actions.) "Fine-tuning or RAG for our use case, and why?" Then the boring question that predicts success better than any of the above: "Show me a pull request you're proud of." Clean back-end code is most of an AI product. 6. Lock the contract: IP, data and compliance Get these in writing before anyone touches your data: IP assignment: all code, prompts, fine-tuned weights and evaluation datasets belong to you. Data handling: where your data is stored, which model providers it's sent to, and whether those providers can train on it. India's DPDP Act 2023: if personal data of Indian users is involved, your vendor needs to process it within the Act's rules. Add GDPR or HIPAA terms if you serve EU or US healthcare users. Access and exit: repo ownership in your GitHub organisation, cloud accounts in your name, and a handover clause. What goes wrong: the code lives in the developer's personal GitHub and the OpenAI key is on their card. We've inherited projects like this. Untangling it costs weeks. 7. Onboard with a 30-day milestone Give the new developer or team one measurable target for the first 30 days, such as "RAG assistant answering the top 50 support questions with 85%+ accuracy on our test set, deployed to staging." A clear milestone surfaces a bad hire in four weeks instead of four months. How much does it cost to hire AI developers in India? Rates vary by role, seniority, city and engagement model. These ranges come from published 2026 rate cards and salary data (Second Talent, Wisemonk, Glassdoor and Indeed figures as reported in their guides), so treat them as a starting point rather than a quote. Hourly rates for international clients Experience Typical rate (USD/hour) Junior (0–2 years) $25–35 Mid-level (3–6 years) $35–50 Senior (6–10 years) $50–75 Lead / principal (10+ years) $70–110 Generative AI and LLM specialists typically command a 15–20% premium over general ML engineers. For comparison, US freelance AI rates commonly run $100 to $200+ an hour. Annual salaries for full-time hires Experience Annual salary (INR) Junior (0–2 years) ₹6–14 LPA Mid-level (3–6 years) ₹15–30 LPA Senior (6–10 years) ₹30–70 LPA Lead / principal (10+ years) ₹60–110 LPA The costs nobody puts in the rate card Employment overhead: for direct hires, budget about 1.3x to 1.4x base salary once statutory benefits, equipment and EOR fees are added. Notice periods: 30 to 90 days is normal in India, and counter-offers of 25–40% are common. Your "hired" candidate may never join. Model and infrastructure spend: LLM API tokens, vector databases and GPU hours are separate from developer cost. A good developer will reduce this bill; a weak one can make it the biggest line item. Rework: a cheap prototype that has to be rebuilt for production is the most expensive option on this list. Red flags when you hire AI developers Every portfolio project is a ChatGPT wrapper with a new UI and no evaluation. They promise a fixed accuracy number before seeing your data. They can't explain how much a feature will cost to run per month. No questions about your data quality, users or edge cases. They want your production data on their own accounts. Estimates for a "full AI agent" in a week. Prototypes, yes. Production, no. Freelancer, agency or in-house: which should you choose? Choose a freelancer if you need a proof of concept in under a month and can review the code yourself. Choose an agency or dedicated team if you need a production product with AI inside it and don't want to hire designers, front-end, back-end and DevOps people separately. Our checklist on how to vet an AI development company covers the questions to ask before signing. Choose an in-house hire (via EOR) if AI is your core product, you have 2+ months to hire, and you can offer a role that keeps a strong engineer interested for years. Plenty of companies do two of these in sequence: an agency builds and launches v1, then the company hires in-house and the agency hands over. Best cities in India to hire AI developers Bengaluru has the largest concentration of AI and data teams and the highest pay, with Hyderabad, Pune, Gurugram, Chennai and Mumbai close behind. Tier-2 cities like Jaipur, Indore and Kochi have smaller senior talent pools but lower costs. For remote work, the city matters far less than the person's track record. Hire AI developers in India with Craxinno Craxinno is an AI-first design and development studio based in Jaipur, India, building since 2017. Our team of 35+ specialists has shipped 200+ projects across SaaS, fintech, e-commerce and mobile. On the AI development side we work with Python (FastAPI, Flask, Django), RAG pipelines, agentic workflows, image generation with Flux, RunPod and AWS deployment, plus the React, Next.js and Node.js work that turns a model into a real product. You can hire a dedicated AI developer or a full product team at $25 per hour , with code in your repository and IP assigned to you from day one. See the projects we've shipped or talk to our team about your AI build .
Quick answer: The cost to build an app like Instagram is roughly $22,000 to $50,000 for an MVP built by an offshore team at $25/hour, and $150,000 to $300,000 for the same scope with a US agency. A full product with Reels-style video, AI feed ranking and live streaming runs $100,000 to $1M+ , depending on who builds it. That's a wide range, and every agency page you've read gives you a different one. So instead of another vague estimate, we did the math in the open: feature-by-feature hours, the same hours priced at three different rates, and the monthly server bill nobody mentions until after launch. Instagram App Cost at a Glance Build tier What you get Effort At $25/hr (India) At $75/hr (E. Europe) At $150/hr (US) Timeline Basic photo app Profiles, photo upload, filters, follow feed, likes, comments 900–1,200 hrs $22.5K–$30K $67.5K–$90K $135K–$180K 2–3 months Instagram-style MVP Basic + Stories, DMs, Explore, push notifications, admin panel 1,500–2,000 hrs $37.5K–$50K $112.5K–$150K $225K–$300K 3–5 months Full platform MVP + short-video feed, ML ranking, live streaming, ads, shopping 4,000–8,000+ hrs $100K–$200K+ $300K–$600K+ $600K–$1.2M+ 9–18 months Look at that table for a second. The scope in each row is identical across the columns. The only thing that changes is the hourly rate, and it moves the price by 6x. Hold that thought; we'll come back to it. Instagram Was Built by 13 People. Your Clone Still Won't Be Cheap Here's the part that confuses founders. Kevin Systrom and Mike Krieger launched Instagram on iOS on October 6, 2010, and roughly 25,000 people signed up on day one. When Facebook bought it for $1 billion in April 2012, the company had 13 employees. So why does a "simple photo app" cost six figures today? Because the 2010 version of Instagram was a photo feed with filters. That's it. No Stories (added in 2016), no Reels (2020), no DMs worth talking about, no shopping, no ads. Today Instagram has more than 3 billion monthly active users, a figure Meta announced in September 2025 , and the app you're comparing against is fifteen years of features stacked on top of that original feed. You don't need fifteen years of features. You need the 20% your users will open the app for. That's where the budget conversation should start. Feature-by-Feature Cost Breakdown Below is a realistic hour estimate for an Instagram-style MVP built cross-platform (one codebase for iOS and Android) with a backend and admin panel. Your own scope will shift these numbers, but the proportions hold up. Feature What it involves Est. hours Cost at $25/hr Discovery + UI/UX design User flows, wireframes, high-fidelity screens, design system 160 $4,000 Sign-up and profiles Email/phone OTP, Google/Apple login, edit profile, follow/unfollow, private accounts 120 $3,000 Photo and video upload Camera, gallery picker, crop, filters, compression, multiple resolutions 200 $5,000 Home feed Following feed, infinite scroll, caching, pull-to-refresh 140 $3,500 Likes, comments, saves, shares Real-time counters, threaded comments, saved collections 90 $2,250 Search and Explore User and hashtag search, a basic trending grid 100 $2,500 Push notifications Likes, comments, follows, DMs via FCM/APNs 50 $1,250 Direct messaging 1:1 real-time chat over WebSockets, media in chat, read receipts 180 $4,500 Stories 24-hour expiry, viewer list, simple text and sticker overlays 120 $3,000 Admin panel + moderation User management, report queue, content takedown, basic analytics 140 $3,500 Backend, media pipeline, DevOps API, database design, CDN, cloud setup, CI/CD, security 180 $4,500 QA and launch Device testing, load testing, App Store and Play Store submission 180 $4,500 Total 1,660 hrs $41,500 For a sanity check: Cleveroad's published estimate puts the core Instagram features at about 1,180 hours per platform , and that excludes design and the admin panel. Ours lands in the same zone once you account for cross-platform development covering both apps at once. Two lines in that table deserve a closer look. Media upload is never "just an upload." A user picks a 12 MB photo from their gallery. Your app has to crop it, compress it, generate three or four sizes (thumbnail, feed, full screen), push them to storage and serve them through a CDN so the feed doesn't stutter on a 4G connection in a small town. Video multiplies all of that, because now you're transcoding too. DMs are a product inside your product. Real-time messaging means persistent connections, delivery states, offline sync and push fallbacks. Founders routinely underestimate it. If messaging isn't the reason people will use your app, push it to version two. What Makes an Instagram Clone Expensive Some features cost a few thousand dollars. Others quietly double the budget. These are the ones that do the doubling: Short-form video (Reels): Vertical video means transcoding into several bitrates, adaptive streaming, autoplay that doesn't drain the battery, and a much bigger bandwidth bill. Expect 400–700+ hours on its own. AI-ranked feed: A chronological feed is a database query. A ranked feed needs event tracking, a recommendation model, and constant tuning. You can start with simple rules (recency plus engagement) and move to ML once you have enough users to learn from. Live streaming: Low-latency video, live comments, moderation in real time. Most teams buy this from a provider like Agora or Mux rather than building it. Content moderation: Once strangers can post photos, you need automated screening (services like AWS Rekognition flag nudity and violence) plus a human review queue. App stores will reject a social app with no reporting system. Two native apps instead of one cross-platform app: Separate Swift and Kotlin codebases take roughly 1.6–2x the effort of a single cross-platform build, according to Scrums.com's benchmarks . For a social MVP, Flutter or React Native is almost always the better call. Why Your Team's Location Changes the Bill More Than Any Feature Go back to the 1,660-hour MVP. Here's the same scope, same features, same quality bar, priced at typical market rates: Team location Typical hourly rate 1,660-hour MVP India (Craxinno) $25 $41,500 Eastern Europe $50–$75 $83,000–$124,500 Western Europe / UK $80–$120 $132,800–$199,200 United States $150–$200 $249,000–$332,000 The gap between the top and bottom of that table is enough to fund a full year of marketing, or your second and third app versions. We're obviously biased here, since we're a studio in Jaipur billing $25 an hour. But the honest version of this advice is the same one we'd give a friend: rate matters less than whether the team has shipped a social app before and talks to you every week. A cheap team that misjudges the media pipeline will cost you more than an expensive one that doesn't. Ask any vendor to walk you through how they'd handle image compression and feed caching. Their answer tells you more than their rate card. The Cost Nobody Quotes You: Running the App Most "cost to build" articles stop at launch day. Your bills don't. Here's a rough monthly infrastructure estimate for a modest app with 10,000 daily active users , using AWS list prices before discounts or free tiers: Bandwidth (the big one): If each user scrolls through about 100 MB of photos and short clips a day, that's 1 TB a day, or roughly 30 TB a month. At CloudFront's US/Europe rates ($0.085/GB for the first 10 TB, $0.080/GB after that), you're paying around $2,450 a month just to deliver media. Storage: Say users upload 2,000 posts a day at about 5 MB each across all resized versions. That's around 300 GB of new data a month. Even after a full year (about 3.6 TB), S3 Standard at $0.023/GB costs roughly $85 a month . Servers, database, real-time chat, push and moderation APIs: typically another $500–$1,500 a month at this scale. Notice the pattern? Storage is cheap. Serving media is what costs money, and it grows with every user who scrolls. That's why aggressive image compression, WebP/AVIF formats and short-video caps aren't technical nice-to-haves; they come straight off your monthly bill. Then add maintenance. Cubix puts annual maintenance at 15–20% of the original build cost, which matches what we see: OS updates, new device sizes, security patches and bug fixes don't stop. On a $41,500 build, budget roughly $6,000–$8,500 a year for upkeep, separate from new features. Tech Stack for an App Like Instagram A fun fact that tends to reassure founders: Instagram's backend famously started on Django (Python) and PostgreSQL , the same boring, proven tools available to you today. You don't need exotic technology. You need sensible choices. Layer Our usual pick Why Mobile app Flutter or React Native One codebase for iOS and Android, near-native performance Backend API Node.js or Python (Django/FastAPI) Fast to build, huge ecosystem, scales well behind a load balancer Database PostgreSQL + Redis Relational data for users and posts, Redis for feeds, counters and sessions Media storage + delivery Amazon S3 + CloudFront (or Cloudinary) Cheap storage, global CDN, on-the-fly image resizing Real-time chat WebSockets (Socket.io) or Stream Reliable messaging without reinventing it Push notifications Firebase Cloud Messaging + APNs Industry standard, free at the notification layer Moderation AWS Rekognition + human review queue Automated first pass, people for edge cases If you're curious how we use these in practice, our React and Node.js pages go deeper into the stack. How Long Does It Take to Build an App Like Instagram? A basic photo-sharing app takes 2–3 months. An Instagram-style MVP with Stories and DMs takes 3–5 months. A full platform with short video, ML ranking and live streaming takes 9–18 months. Timelines assume a dedicated team of four to six people: a designer, two or three developers, a QA engineer and a project manager. The phase that slips most often isn't coding. It's decisions. A founder who answers "should comments be threaded?" in a day keeps the project on schedule; one who takes two weeks to decide doesn't. Our work process is built around weekly demos for exactly this reason. How to Cut the Cost Without Building a Worse App Pick a niche, not a planet. Instagram for everyone is a billion-dollar fight. Instagram for tattoo artists, home cooks, wedding photographers or college campuses is a product you can launch for under $50,000 and actually win. A niche also cuts features: a recipe-sharing app may not need DMs at all. Launch with the feed, not the kitchen sink. Profiles, upload, feed, likes, comments, notifications. Ship it. Watch what people do. Then build Stories or messaging based on real behavior instead of guesses. Buy the hard parts. Chat, live video and media processing all have mature providers (Stream, Agora, Mux, Cloudinary). Paying a monthly fee is usually far cheaper than 300 hours of custom engineering, at least until you hit serious scale. Go cross-platform. One Flutter or React Native codebase instead of two native apps is the single biggest saving on the mobile side. Use AI-assisted development, with humans in charge. We use AI coding tools daily at Craxinno, and they've cut the time spent on boilerplate, tests and admin screens noticeably. They don't replace architecture decisions, and they won't save a badly scoped project. Should You Build an Instagram Clone at All? Straight answer: a pure clone is a bad business plan. People already have Instagram, and "the same thing, but ours" gives nobody a reason to switch. But "an app like Instagram" is a different idea. A visual feed, follows, likes and short video are proven patterns users already know how to use. Wrap them around a specific community or use case and you get familiarity without the head-to-head fight. That's the version worth paying for. On monetization, one detail catches founders off guard: Apple and Google's 15–30% commission applies to digital goods and subscriptions sold inside the app, not to ad revenue. An ad-supported social app keeps its ad income; a subscription-based one needs to plan for the fee. Frequently Asked Questions How much does it cost to make an app like Instagram? An Instagram-style MVP costs about $22,000–$50,000 with an offshore team at $25/hour, or $150,000–$300,000 with a US agency. A full platform with Reels-style video, AI ranking and live streaming ranges from $100,000 to over $1 million depending on team rates and scope. What is the cheapest way to build an Instagram-like app? Start with a niche MVP built cross-platform in Flutter or React Native, limit version one to profiles, uploads, feed, likes, comments and notifications, and use third-party services for chat and media processing. With a $25/hour team, this lands around $22,000–$30,000. How long does it take to develop an app like Instagram? A basic version takes 2–3 months, an MVP with Stories and DMs takes 3–5 months, and a full-featured platform takes 9–18 months with a dedicated team of four to six people. How much does it cost to run an Instagram-like app every month? For about 10,000 daily active users, expect roughly $3,000–$4,000 a month in infrastructure, mostly bandwidth for delivering photos and video. Maintenance adds 15–20% of the build cost per year. Which is the most expensive feature in an Instagram clone? Short-form video and the recommendation feed. Video needs transcoding, adaptive streaming and heavy bandwidth; an ML-ranked feed needs event tracking and a recommendation model. Each can add hundreds of development hours. Can I build an app like Instagram with Flutter? Yes. Flutter handles feeds, camera access, filters, video playback and real-time chat well, and it lets one codebase ship to iOS and Android, which cuts mobile development effort significantly compared with two native apps. Get a Real Number for Your App Every estimate in this article is a starting point. Your actual cost depends on your niche, your must-have features and how fast you want to launch. Send us your idea and we'll come back with a feature list, an hour-by-hour estimate and a timeline, free and without a sales script. At $25/hour, you'll see exactly where every dollar goes. Talk to the Craxinno team or browse apps we've shipped first.
Short answer: The best tech stack for a SaaS startup in 2026, for most teams, is TypeScript end to end : Next.js 16 and React 19 on the front, PostgreSQL (through Supabase or Neon) with Drizzle ORM for data, managed auth, Stripe or a Merchant of Record for billing, Vercel for hosting, and pgvector plus a model API for AI features. Boring on purpose. Boring ships. That's the answer we give founders on discovery calls, and it rarely changes. At Craxinno we've shipped 200+ web apps since 2017, and the stack conversation almost never decides whether a SaaS product succeeds. What it does decide is how fast you can ship the next feature, how easily you can hire, and whether you'll be stuck rewriting your billing code in month 14 instead of selling. So this guide to the best tech stack for a SaaS startup skips the "top 25 frameworks" roundup. You'll get one opinionated default stack, the reasoning behind each layer, what it costs per month, and the specific situations where you should throw our advice out. The 2026 SaaS Tech Stack at a Glance Layer Our default pick Swap it when... Language TypeScript Your product is mostly ML or data work → Python Frontend Next.js 16 + React 19 The app is 100% behind a login and SEO doesn't matter → Vite + React SPA UI Tailwind CSS + shadcn/ui You hire a designer and need a custom design system Backend/API Next.js route handlers, then a Node.js service (Hono or NestJS) Heavy AI pipelines → FastAPI. Very high throughput → Go Database PostgreSQL (Supabase or Neon) Almost never. Seriously ORM Drizzle Your team already knows Prisma well Auth Supabase Auth or Better Auth You want hosted UI in an afternoon → Clerk. Enterprise SSO → WorkOS Payments Stripe You sell globally and don't want to file taxes → Paddle, Lemon Squeezy or Polar. Indian customers paying in INR → Razorpay Hosting Vercel + managed Postgres Steady heavy compute, long jobs or strict compliance → AWS Background jobs Inngest or Trigger.dev High-volume queues → BullMQ on Redis or RabbitMQ Email Resend Very high volume → AWS SES Analytics PostHog You only need traffic stats → Plausible Error tracking Sentry (Rarely worth swapping) AI layer OpenAI / Claude APIs + pgvector RAG, agents or self-hosted models at scale → Python service on GPU infra Now the why, layer by layer. We spend a lot more time on the database and payments than on CSS, because that's where the expensive mistakes live. Why TypeScript End to End Wins for Most SaaS Startups One language from the database schema to the button component. That's the whole argument, and it's a strong one. When your Drizzle schema, your API responses and your React props share the same types, a renamed column breaks the build instead of breaking production. A three-person team can move between frontend and backend tickets without context switching between languages. And hiring is easier: TypeScript and React developers are the deepest talent pool you'll find in India, the US or Eastern Europe. There's a 2026-specific reason too. Most teams now write a big chunk of their code with AI assistants like Claude , Cursor or Copilot. Those tools are noticeably more reliable on mainstream, well-documented stacks than on niche ones, simply because there's far more public TypeScript and Next.js code for them to have learned from. Picking a popular stack is now also picking the stack your AI pair programmer writes best. (The counter-case: if your founding engineer is a Django or Rails veteran who can ship a feature a day, let them. Team fluency beats trend fluency every time. More on that below.) Read more about how we use TypeScript on client projects. Frontend: Next.js 16, With One Honest Caveat Next.js 16 wen t stable on October 21, 2025 , with Turbopack as the default bundler and React 19.2 support. For a SaaS product, it gives you the marketing site, the blog, the docs and the logged-in app in a single codebase, with server rendering where Google needs it and client interactivity where users need it. Pair it with Tailwind CSS and shadcn/ui. You copy components into your repo instead of installing a black-box library, so you own every line and can restyle anything without fighting a theme API. The caveat. Next.js's App Router, server components and caching model have a real learning curve. If your product is a dashboard that lives entirely behind a login, with no public pages that need to rank, a plain Vite + React single-page app is simpler to reason about and cheaper to host. Put your marketing site on a separate Next.js or static build and move on. Database: Just Use PostgreSQL This is the one decision we'd defend in any argument. PostgreSQL was used by 55.6% of all respondents in the 2025 Stack Overflow Developer Survey , and it ranked first for both "admired" (65.5%) and "desired" (46.5%). Popularity isn't the reason to pick it, though. The reason is that Postgres alone covers what used to take three databases: Relational data for users, organizations, subscriptions and invoices JSONB columns for the flexible, schema-light data people used to reach for MongoDB to store Full-text search that's good enough until you have hundreds of thousands of documents Vector search through pgvector, so your AI features don't need a separate vector database on day one Supabase or Neon? Supabase gives you Postgres plus auth, storage and realtime in one dashboard, and its Pro plan is $25/month per organization. Neon is a leaner serverless Postgres with database branching that's handy for preview environments. Both are plain Postgres underneath, which means you can migrate to AWS RDS later with a dump and restore. That exit path matters. Plan multi-tenancy on day one Every B2B SaaS is multi-tenant, and the cheapest time to design for it is before your first table exists. Our default: a shared schema where every tenant-owned table carries an organization_id , enforced with Postgres row-level security. Schema-per-tenant or database-per-tenant only makes sense when an enterprise contract demands data isolation, and you can add it for that one customer later. One production gotcha we see in audits: RLS policies that filter on organization_id without an index on that column. Everything works fine at 1,000 rows and crawls at 1,000,000. Index the tenant column on every table. It's a one-line fix that saves a very bad week. Authentication: Don't Build It Yourself You can write a login form in an hour. You can't write password resets, email verification, rate limiting, session rotation, OAuth, MFA and SAML SSO in an hour, and every one of those will eventually be asked for. Your realistic options in 2026: Supabase Auth if you're already on Supabase. The free plan covers up to 50,000 monthly active users and Pro covers 100,000, which is plenty for most early SaaS products. Better Auth if you want an open-source library that stores everything in your own Postgres, with plugins for organizations and SSO. Clerk if you want polished, prebuilt sign-in UI and are fine paying per user as you grow. WorkOS when your first enterprise prospect asks for SAML SSO and SCIM provisioning. Whichever you pick, model organizations, members and roles from the start. Retrofitting "teams" into an app built around single users is one of the most expensive refactors we get hired for. Payments: Stripe vs. a Merchant of Record (and the India Question) Billing is where SaaS founders lose the most time, so think about it earlier than feels necessary. Stripe is the default for good reason: excellent subscription APIs, a hosted customer portal and the best developer docs in payments. The standard US card rate is 2.9% + 30¢ per successful charge. The catch is that you are the seller, so sales tax, VAT and GST compliance are your problem (Stripe Tax helps, for an extra fee). A Merchant of Record (Paddle, Lemon Squeezy, Polar) becomes the legal seller of your software. They charge more per transaction, but they calculate, collect and remit taxes in every country for you. For a two-person team selling worldwide, that trade is usually worth it. If you're a founder in India , there's one more wrinkle. Stripe moved to invite-only onboarding for new Indian businesses in 2024 . The two common routes: Set up a US entity (Delaware or Wyoming are the usual picks; Craxinno itself runs a US entity out of Cheyenne, Wyoming) and use Stripe or a Merchant of Record for international customers. Use Razorpay for Indian customers paying in INR, including UPI AutoPay for recurring subscriptions. Plenty of Indian SaaS companies end up running both: Razorpay for domestic billing, Stripe or a Merchant of Record for everyone else. Build a thin billing layer in your code so the provider is swappable. We've done enough payment gateway integrations to know that "we'll only ever need one provider" doesn't survive the first enterprise deal. Hosting and Infrastructure: Start Managed, Move When the Bill Tells You To Start on Vercel for the Next.js app and a managed Postgres host for data. Zero servers to patch, preview deployments for every pull request, and deploys that take minutes. One thing founders miss: Vercel's free Hobby plan is restricted to non-commercial, personal use . The moment you charge customers, you need Pro at $20 per developer seat per month. When should you move to AWS ? Watch for these signals: Your Vercel function and bandwidth bill has become a meaningful line item every month You have long-running jobs (video processing, large imports, model inference) that don't fit serverless time limits An enterprise customer or regulation requires a specific data region, a signed BAA or a dedicated VPC You need a mix of always-on workers, queues and GPUs Even then, skip Kubernetes. ECS on Fargate, or a platform like Railway or Fly.io, covers most SaaS workloads well into the millions of requests without a dedicated DevOps hire. The AI Layer Is Now Part of the Default Stack In 2026, customers expect at least one AI feature in a SaaS product: a smart search, a summary, a draft, an agent that does the boring part of the workflow. So plan for it in the architecture instead of bolting it on. Stage 1: call models from your TypeScript backend. Use the Vercel AI SDK (or the official SDKs) to call OpenAI or Anthropic's Claude . Store embeddings in pgvector, in the same Postgres database as everything else. This handles AI search, summarization, chat over your users' data and simple tool-calling agents. Most startups never need to leave this stage. Stage 2: add a Python service when the work gets heavy. Python still owns the AI ecosystem. Once you're building multi-step RAG pipelines, parsing messy PDFs at volume, running evaluations or hosting open-source models on GPU providers like RunPod, stand up a separate FastAPI service. Your Next.js app talks to it over HTTP for quick calls and through a queue (Inngest, BullMQ or RabbitMQ) for long-running jobs. Four habits save real money here: Meter tokens per tenant from the first AI feature. Otherwise one heavy customer quietly eats your margin. Route by difficulty. Send easy tasks to a small, cheap model and escalate only the hard ones. Cache repeated requests. Identical prompts (the same document summary, the same FAQ answer) shouldn't hit the model twice. Log every prompt and output so you can evaluate quality before swapping models. What This SaaS Stack Actually Costs Per Month List prices at the time of writing. Always check the vendor's pricing page before you budget, because these change often. Stage Setup Fixed monthly cost Building / pre-revenue Vercel Hobby, Supabase Free, Resend Free (3,000 emails/month), PostHog and Sentry free tiers $0 First paying customers Vercel Pro (1 seat, $20), Supabase Pro ($25), Resend Pro ($20 for 50,000 emails) ~$65 + AI usage Growing team Add a Vercel seat per developer ($20 each), paid Sentry and PostHog tiers as volume grows, larger database compute Scales with usage, not with a big jump On top of fixed costs you pay variable fees: Stripe's 2.9% + 30¢ per card charge (or a higher Merchant of Record rate) and your LLM token spend. For AI-heavy products, token spend is often the biggest infrastructure line by far, which is why per-tenant metering matters so much. Two warnings. Supabase's free projects pause after 7 days of inactivity, so don't run a demo for investors on one. And Vercel Hobby isn't allowed for commercial use, so budget for Pro on launch day. When You Should Ignore This Stack A default is a starting point, not a rule. Break it when: Your team is already fast in something else. A senior Django, Rails or Laravel developer will ship a SaaS MVP faster in their framework than in a stack they're learning. Their admin panels and conventions are a gift at MVP stage. The core product is AI or data science. If 80% of the work is models and pipelines, go Python-first: FastAPI and Postgres on the backend, a React frontend on top. You need extreme real-time throughput. Trading systems, IoT ingestion or multiplayer collaboration may need Go or Elixir services for the hot path. You're in a regulated industry from day one. Healthcare or fintech products should check every vendor for HIPAA BAAs, SOC 2 reports and data residency options before writing code. AWS-first is often simpler here. 6 Tech Stack Mistakes That Force a Rewrite We see these on almost every rescue project that comes through our door. Microservices on day one. A modular monolith is faster to build, easier to debug and simpler to deploy. Split services only when a specific part has different scaling or team needs. Building auth or billing in-house. Weeks of work, ongoing security liability, zero differentiation. No tenant model. Adding organization_id to 40 tables after launch, while keeping live customer data intact, is miserable. Choosing a database for scale you don't have. You aren't Netflix. Postgres on a modest instance handles more traffic than most SaaS products ever see. Proprietary data APIs without an exit plan. Firebase and similar platforms are quick to start with, but moving off a non-SQL proprietary backend later can mean a full data-layer rewrite. No error tracking or logs until the first outage. Sentry and structured logs take an hour to add. Debugging a production incident blind takes days. Security and Compliance: What to Have Before Your First Enterprise Deal Few stack guides cover this, yet it's exactly what stalls B2B deals. Enterprise buyers will send a security questionnaire. Have answers ready: Encryption in transit (TLS) and at rest (default on Supabase, Neon and RDS) Automated backups with point-in-time recovery, and a restore you've actually tested Role-based access control and audit logs for admin actions SSO/SAML on your roadmap, or available on a higher plan A data processing agreement covering GDPR for EU customers and India's Digital Personal Data Protection Act, 2023 for Indian users A path to SOC 2. Tools like Vanta or Drata make the first audit far less painful when your infra is already on mainstream cloud providers None of this requires a different stack. It requires choosing vendors that publish their own compliance reports, which every tool in our default stack does on its paid plans. How Craxinno Helps SaaS Founders Pick and Ship a Stack We're an AI-first design and development studio based in Jaipur, with a US entity in Wyoming. We've been building web apps, SaaS platforms and AI products since 2017, across Next.js, Node.js, Python (FastAPI, Django), AWS and payment gateway integrations. If you're choosing the best tech stack for a SaaS startup of your own, or you've inherited one that's slowing you down, we'll review it with you and tell you plainly what to keep and what to change. See how we work , browse projects we've shipped , or talk to us about your stack .
How to Build a Chatbot with the OpenAI API: Step-by-Step Python Tutorial Quick answer: To build a chatbot with the OpenAI API, install the openai Python SDK, save your API key in an environment variable, and send each user message to client.responses.create() with your system prompt in instructions . Pass the previous reply's ID back as previous_response_id so the bot remembers the conversation, then stream the output to a web page through a small backend. That's the whole idea. The rest of this tutorial turns it into code you can run in about 20 minutes. One warning first. Search "OpenAI chatbot tutorial" and a good share of the top results still call openai.ChatCompletion.create() . That function was removed when the Python SDK hit version 1.0 back in November 2023, and the SDK is on version 3.29 as of October 2026. Copy that code today and you get an error before your bot says hello. Everything below is written against the current Responses API and tested on openai 3.29.0. What you'll build A support assistant called Ava for a made-up coffee subscription brand, Brewly. By the end you'll have: A terminal chatbot that streams replies word by word and remembers earlier messages. A FastAPI backend that keeps your API key off the browser. A plain HTML chat page that talks to that backend. A clear idea of what each conversation costs you. Python 3.9 or newer and an OpenAI account with billing enabled are all you need. No frameworks like LangChain. You'll understand every line, which matters the first time something breaks in production. Responses API vs Chat Completions vs Assistants: which one? OpenAI has three APIs that can power a chatbot, and older tutorials mix them up. API Status (Oct 2026) Who manages conversation history Use it for Responses API Recommended for all new projects You, or OpenAI via previous_response_id / Conversations New chatbots and agents Chat Completions Still supported You (resend the messages array) Existing apps you don't want to migrate yet Assistants API Listed under legacy APIs OpenAI (threads) Nothing new OpenAI's own migration guide says Responses is "recommended for all new projects," and reports 40–80% better cache utilization than Chat Completions in internal tests. Better cache hits mean lower bills on long chats, which is reason enough for a chatbot. So this tutorial uses the Responses API throughout. Step 1: Set up the project and your API key Create a folder, a virtual environment and install four packages: 1 2 3 4 mkdir openai - chatbot && cd openai - chatbot python - m venv . venv source . venv / bin / activate # Windows : . venv\Scripts\activate pip install openai python - dotenv fastapi uvicorn Generate a key at platform.openai.com → API keys , then create a .env file in the project folder: 1 2 OPENAI_API_KEY = sk - proj - your - key - here OPENAI_MODEL = gpt - 6 - luna Add .env to .gitignore right now, before your first commit. Leaked keys get scraped from public GitHub repos within minutes, and the bill lands on your account. What goes wrong here: if you see OpenAIError: Missing credentials. Please pass an api_key... , the SDK can't find the variable. Check that load_dotenv() runs before OpenAI() is created and that you started Python from the folder containing .env . Step 2: Send your first request Create hello.py : 1 2 3 4 5 6 7 8 9 from dotenv import load_dotenv from openai import OpenAI load_dotenv ( ) client = OpenAI ( ) # reads OPENAI_API_KEY from the environment response = client . responses . create ( model = "gpt-6-luna" , input = "Explain what an API key is in one sentence." , ) print ( response . output_text ) Run python hello.py . If a sentence comes back, your account, key and billing all work. response.output_text is a convenience property that joins all the text the model produced. The full response.output list also holds reasoning items and tool calls, which you'll need later for memory. Which model should a chatbot use? These are the current text models and their prices per 1 million tokens, from OpenAI's models page: Model Input Output Good for gpt-6-luna $0.10 $0.50 FAQ and support bots, high volume, fastest replies gpt-6.1-sol $2 $10 Bots that need to reason over policies, data or code gpt-6-astra $10 $50 Hard, high-value queries where accuracy beats cost Our take: start every chatbot on Luna. Most customer-facing questions ("where's my order?", "can I change my plan?") don't need a frontier model, and Luna costs 1/20th of Sol. Upgrade only the conversations that need it. Because the model name lives in .env , switching is a one-line change. Step 3: Give the bot a personality and rules with a system prompt Without instructions, the model answers anything about anything. A support bot needs a job description. In the Responses API, that goes in the instructions parameter: 1 2 3 4 5 6 7 8 9 10 11 SYSTEM_PROMPT = """You are Ava, the support assistant for Brewly, an online coffee subscription. - Only answer questions about orders, subscriptions, shipping and coffee. - Keep replies under 80 words unless the user asks for more detail. - If you are not sure, say so and point the user to help@brewly.example. - Never invent order numbers, prices or delivery dates.""" response = client . responses . create ( model = "gpt-6-luna" , instructions = SYSTEM_PROMPT , input = "Can I pause my subscription for a month?" , ) print ( response . output_text ) A few things we've learned writing system prompts for client bots: Rules beat adjectives. "Keep replies under 80 words" works. "Be concise" gets interpreted loosely. Tell it what to do when it doesn't know. The fallback line (email support) is what stops a bot from making up a refund policy. Ban the specific lies. Order numbers and delivery dates are what support bots most love to invent, so the prompt names them. If you want to go deeper on wording, our guide to prompt engineering covers structure and testing. Step 4: Add conversation memory (three ways) Ask the bot from Step 3 "Can I pause my plan?", then follow up with "What about two months?" It has no idea what you mean. Every API call starts with a blank slate, because the model is stateless. You have three ways to fix that. Approach How it works Where history lives Best for A. Manual history Append every message and reply to a list, send the whole list each time Your app Full control, store=False for sensitive data B. previous_response_id Pass the last reply's ID; OpenAI fills in the earlier turns OpenAI (responses kept 30 days by default) Terminal bots, short sessions C. Conversations API Create a conversation object once, attach every response to it OpenAI (no 30-day expiry) Web apps where users come back later One thing none of the three changes: you pay for the history every turn. OpenAI's docs say it directly: with previous_response_id , "all previous input tokens for responses in the chain are billed as input tokens." Server-side memory saves you code, not tokens. Option A: manual history (stateless) 1 2 3 4 5 6 7 8 9 10 11 history = [ ] def ask ( user_text ) : history . append ( { "role" : "user" , "content" : user_text } ) response = client . responses . create ( model = "gpt-6-luna" , instructions = SYSTEM_PROMPT , input = history , store = False , # nothing kept on OpenAI's side ) history . extend ( response . output ) # keep ALL output items, not just the text return response . output_text Note history.extend(response.output) . OpenAI's conversation-state guide says to keep every output item so reasoning items stay intact. Appending only output_text as a string works on simple models and quietly degrades answers on reasoning ones. Option B: previous_response_id (the terminal chatbot) This is the full, runnable terminal bot. Save it as chat.py : 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 26 27 28 29 30 31 32 33 34 35 36 37 import os from dotenv import load_dotenv from openai import OpenAI load_dotenv ( ) client = OpenAI ( ) MODEL = os . getenv ( "OPENAI_MODEL" , "gpt-6-luna" ) SYSTEM_PROMPT = """You are Ava, the support assistant for Brewly, an online coffee subscription. - Only answer questions about orders, subscriptions, shipping and coffee. - Keep replies under 80 words unless the user asks for more detail. - If you are not sure, say so and point the user to help@brewly.example. - Never invent order numbers, prices or delivery dates.""" def main ( ) : previous_id = None print ( "Ava is ready. Type 'quit' to exit.\n" ) while True : user_text = input ( "You: " ) . strip ( ) if user_text . lower ( ) in { "quit" , "exit" } : break if not user_text : continue stream = client . responses . create ( model = MODEL , instructions = SYSTEM_PROMPT , # resend every turn input = user_text , previous_response_id = previous_id , reasoning = { "effort" : "low" } , stream = True , ) print ( "Ava: " , end = "" , flush = True ) for event in stream : if event . type == "response.output_text.delta" : print ( event . delta , end = "" , flush = True ) elif event . type == "response.completed" : previous_id = event . response . id print ( "\n" ) if __name__ == "__main__" : main ( ) Run python chat.py , ask about pausing, then ask "what about two months?" Ava now knows what "that" refers to. See the comment # resend every turn ? That's the bug that catches almost everyone. The SDK documentation says that with previous_response_id , "the instructions from a previous response will not be carried over to the next response." Send instructions only on the first call and by turn three Ava has forgotten she's a coffee bot and will happily write you a cover letter. Option C: the Conversations API For a web app, a user might close the tab and come back tomorrow. A conversation object survives that, and unlike stored responses it isn't subject to the 30-day TTL: 1 2 3 4 5 6 7 conversation = client . conversations . create ( ) response = client . responses . create ( model = "gpt-6-luna" , instructions = SYSTEM_PROMPT , input = "Can I pause my plan?" , conversation = conversation . id , ) Save conversation.id against your user record and pass it back on every message. We'll use this in the web version. Step 5: Stream replies instead of waiting You already saw streaming in chat.py , but it deserves its own section because it changes how the bot feels more than any model upgrade. Without streaming, the user types a question and stares at nothing for two, three, four seconds while the whole answer generates. Then a wall of text appears. With streaming, the first words show up almost immediately and the reply types itself out. Same total time. Completely different experience. The mechanics are two lines: pass stream=True , then loop over events and print the ones of type response.output_text.delta . Other events you'll see include response.created , response.completed (which carries the final response object and its ID) and error . Step 6: Put the chatbot on a web page with FastAPI Here's where a lot of tutorials go wrong. They call the OpenAI API straight from browser JavaScript, which means shipping your API key to every visitor. Anyone who opens dev tools can copy it and run up your bill. The fix is a thin backend. The browser talks to your server; only your server talks to OpenAI. Create app.py : 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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 import os from dotenv import load_dotenv from fastapi import FastAPI from fastapi . responses import FileResponse , StreamingResponse from openai import OpenAI from pydantic import BaseModel , Field load_dotenv ( ) client = OpenAI ( timeout = 30 , max_retries = 3 ) MODEL = os . getenv ( "OPENAI_MODEL" , "gpt-6-luna" ) SYSTEM_PROMPT = """You are Ava, the support assistant for Brewly, an online coffee subscription. - Only answer questions about orders, subscriptions, shipping and coffee. - Keep replies under 80 words unless the user asks for more detail. - If you are not sure, say so and point the user to help@brewly.example. - Never invent order numbers, prices or delivery dates.""" app = FastAPI ( ) class ChatIn ( BaseModel ) : conversation_id : str message : str = Field ( min_length = 1 , max_length = 2000 ) @app . get ( "/" ) def home ( ) : return FileResponse ( "index.html" ) @app . post ( "/conversations" ) def new_conversation ( ) : conversation = client . conversations . create ( ) return { "conversation_id" : conversation . id } @app . post ( "/chat" ) def chat ( body : ChatIn ) : def generate ( ) : stream = client . responses . create ( model = MODEL , instructions = SYSTEM_PROMPT , input = body . message , conversation = body . conversation_id , reasoning = { "effort" : "low" } , max_output_tokens = 800 , stream = True , ) for event in stream : if event . type == "response.output_text.delta" : yield event . delta return StreamingResponse ( generate ( ) , media_type = "text/plain" ) Three small details doing real work here: max_length=2000 on the message stops someone pasting a novel into your bot and charging you for it. FastAPI rejects it with a 422 before OpenAI is ever called. max_output_tokens=800 caps the reply cost. Reasoning tokens count toward this limit, so don't set it too tight or replies get cut off. OpenAI(timeout=30, max_retries=3) raises the SDK's default of 2 automatic retries, which covers most brief rate-limit and network blips. Now the front end. Create index.html in the same folder: 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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 <! doctype html > < html lang = " en " > < head > < meta charset = " utf-8 " > < title > Brewly Assistant </ title > </ head > < body > < div id = " log " > </ div > < form id = " chat-form " > < input id = " msg " autocomplete = " off " placeholder = " Ask about your order... " > < button > Send </ button > </ form > < script > const log = document.getElementById("log"); let conversationId = null; function addLine(who, text) { const p = document.createElement("p"); p.textContent = `${who}: ${text}`; // textContent, never innerHTML log.appendChild(p); return p; } document.getElementById("chat-form").addEventListener("submit", async (e) => { e.preventDefault(); const input = document.getElementById("msg"); const text = input.value.trim(); if (!text) return; input.value = ""; if (!conversationId) { const res = await fetch("/conversations", { method: "POST" }); conversationId = (await res.json()).conversation_id; } addLine("You", text); const botLine = addLine("Ava", ""); const res = await fetch("/chat", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ conversation_id: conversationId, message: text }), }); const reader = res.body.getReader(); const decoder = new TextDecoder(); let reply = ""; while (true) { const { done, value } = await reader.read(); if (done) break; reply += decoder.decode(value, { stream: true }); botLine.textContent = `Ava: ${reply}`; } }); </ script > </ body > </ html > Start the server: 1 uvicorn app : app -- reload Open http://127.0.0.1:8000 and chat. That's a working, streaming, memory-aware chatbot in roughly 130 lines across two files. (The textContent comment isn't decoration. Model output rendered with innerHTML is an XSS hole: a user can talk the bot into returning a <script> tag. If you later want Markdown formatting, run it through a sanitizer such as DOMPurify first.) For a production widget with a launcher bubble, mobile layout and analytics, see our walkthrough on how to add AI chat to your website . How much does an OpenAI chatbot cost to run? Less than most people expect, if you pick the model deliberately. Take a typical support chat: a 300-token system prompt, 10 back-and-forth turns, user messages around 50 tokens and replies around 150. Because earlier turns are re-billed as input each time, the 10 turns add up to roughly 12,500 input tokens and 1,500 output tokens. Model Cost per 10-turn conversation Cost per 10,000 conversations gpt-6-luna ~$0.002 ~$20 gpt-6.1-sol ~$0.04 ~$400 gpt-6-astra ~$0.20 ~$2,000 These are estimates from list prices. They leave out reasoning tokens (billed as output) and cached-input discounts, which push in opposite directions. Measure your real numbers from response.usage after a week of traffic. The pattern that matters: cost grows with conversation length , not just count, because every turn re-sends the history. Two ways to keep long chats in check: Trim manual history. With Option A, keep the system prompt plus the last 10–20 items. Turn on server-side compaction. Pass context_management=[{"type": "compaction", "compact_threshold": 200000}] and OpenAI compresses older context once the conversation crosses that token count. Our full playbook on reducing LLM API costs covers caching, routing and batching in more depth. If you're budgeting a whole project rather than API calls, see what an AI chatbot costs to build in 2026 . Common mistakes (and the fix for each) AttributeError: module 'openai' has no attribute 'ChatCompletion' You copied pre-2023 code. Use client = OpenAI() and client.responses.create() . 400 Bad Request mentioning temperature GPT-6 models don't accept temperature , top_p or top_logprobs while reasoning is switched on. Remove them. Control tone through the system prompt instead. (On Luna you can set reasoning={"effort": "none"} if you really need sampling controls.) The bot forgets its role after a few messages You only sent instructions on the first call. With previous_response_id , resend them every turn. Replies stop mid-sentence max_output_tokens is too low. Reasoning tokens eat into it before visible text does. Raise the cap or lower the reasoning effort. RateLimitError (429) under load The SDK retries automatically, but sustained traffic needs a queue or per-user rate limit on your side. Check your usage tier in the OpenAI dashboard. Before you go live: a short production checklist The tutorial bot works. A public bot needs a bit more: Authenticate users and rate-limit per user. An open /chat endpoint is a free LLM for the whole internet. Send a safety_identifier . It's a stable per-user ID (OpenAI recommends hashing the email or username) that helps OpenAI detect abuse coming through your app without flagging your whole account. Decide on data retention. Responses are stored for 30 days by default. For health, finance or other sensitive data, use manual history with store=False . Log every conversation on your side. You can't improve a prompt you can't read. Review 20 real chats a week and you'll find the gaps fast. Write a test set. Twenty questions with expected answers, run after every prompt change, catches regressions before customers do. Give the bot real knowledge. A system prompt can't hold your entire help center. That's what retrieval is for. Where to go next: from chatbot to something useful Right now Ava is polite but knows nothing about Brewly's actual policies or orders. The next two upgrades fix that: Retrieval-augmented generation (RAG) lets the bot answer from your own documents. Upload them to a vector store and give the model the file_search tool, or build your own pipeline. Start with how RAG works , and if you're weighing it against training a custom model, read RAG vs fine-tuning . Function calling lets the bot do things: look up an order, pause a subscription, book a call. At that point it stops being a chatbot and starts being an agent. Here's the difference in practice: AI agents vs chatbots . Need a chatbot built for your business? This tutorial gets you a working prototype in an afternoon. Getting from prototype to a bot that knows your products, connects to your CRM or order system, and holds up under real traffic is where most of the work lives. That's the work our AI development team does: RAG chatbots, support agents and LLM integrations built in Python and FastAPI and shipped to production. Tell us what you're building and we'll tell you honestly whether you need us or this tutorial is enough.
How to Add Stripe Payments to a Next.js App Adding Stripe payments to a Next.js app takes about 30 minutes with the modern approach, and it is simpler than most tutorials make it look. The trick is to use Stripe Checkout , Stripe’s own hosted payment page, rather than building your own card form. You create a checkout session on the server, redirect the user to Stripe to pay, and Stripe sends you back. You never handle raw card details, which makes it faster to build and far more secure. This guide walks through the whole thing, step by step, for the Next.js App Router. Here is the one principle that matters more than any line of code, and the thing beginners get wrong: never trust the browser to confirm a payment. A user can close the tab, lose connection, or tamper with the page after paying. The only reliable way to know a payment succeeded is a webhook, a message Stripe sends directly to your server. Getting the webhook right is what separates a real integration from one that silently loses orders, so this guide treats it as essential, not optional. This guide covers setup, the checkout flow, the all-important webhook, testing, and going live. The quick answer: the whole flow If you want the shape of it first, here is what you are building. Install Stripe and add your API keys to environment variables. Create a server route that makes a Stripe Checkout session and returns its URL. Add a button that calls that route and redirects the user to Stripe to pay. Create a webhook route that listens for Stripe’s confirmation and fulfills the order (this is the critical part). Test locally with the Stripe CLI, then add your live keys and production webhook to go live. The golden rule throughout: Stripe Checkout handles the payment UI and card security for you, and the webhook, not the browser, is the source of truth for whether a payment actually happened. Prerequisites Get these in place first. A Next.js app using the App Router (Next.js 13 or newer), and Node.js 18 or newer. A Stripe account (free to create), with access to your API keys in the Stripe Dashboard. You will use test keys while building. Basic familiarity with Next.js API routes (route handlers) and environment variables. Step 1: Install Stripe and set up your keys Install the Stripe packages: npm install stripe @stripe/stripe-js Then add your keys to a .env.local file in your project root (use your test keys while building): STRIPE_SECRET_KEY=sk_test_your_key NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_your_key STRIPE_WEBHOOK_SECRET=whsec_your_secret NEXT_PUBLIC_APP_URL= http://localhost:3000 Add .env.local to your .gitignore so your secret keys never reach your repository. The secret key must stay on the server only; the publishable key (prefixed NEXT_PUBLIC_) is safe in the browser. It also helps to create one shared Stripe client. Make a file at lib/stripe.ts: import Stripe from “stripe”; export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!); Now every route can import the same configured client. Step 2: Create the checkout session route This server route creates a Stripe Checkout session and returns its URL. Create app/api/checkout/route.ts: import { NextResponse } from “next/server”; import { stripe } from “@/lib/stripe”; export async function POST() { const session = await stripe.checkout.sessions.create({ mode: “payment”, line_items: [ { price_data: { currency: “usd”, product_data: { name: “Your Product” }, unit_amount: 2000, // $20.00, in cents }, quantity: 1, }, ], success_url: ${process.env.NEXT_PUBLIC_APP_URL}/success , cancel_url: ${process.env.NEXT_PUBLIC_APP_URL}/cancel , }); return NextResponse.json({ url: session.url }); } A few notes: amounts are in the smallest currency unit (cents), mode is “payment” for a one-time purchase (use “subscription” for recurring), and success_url and cancel_url are where Stripe sends the user after. The route returns session.url, the hosted Stripe page you will redirect to next. Step 3: Add the checkout button On your page, add a button that calls the route and redirects the user to Stripe. In a client component: “use client”; export default function CheckoutButton() { async function handleClick() { const res = await fetch(“/api/checkout”, { method: “POST” }); const data = await res.json(); window.location.href = data.url; // redirect to Stripe } return <button onClick={handleClick}>Buy now</button>; } That is the entire customer-facing flow: the user clicks, your route makes a session, and the browser sends them to Stripe’s secure page to enter card details. You never touch the card data. Step 4: Create the webhook (the critical part) This is the step that makes the integration trustworthy. After a payment, Stripe sends a message to your server confirming it. You listen for that message and fulfill the order, send the product, mark it paid, email the receipt. Create app/api/webhooks/stripe/route.ts: import { NextResponse } from “next/server”; import { headers } from “next/headers”; import { stripe } from “@/lib/stripe”; import Stripe from “stripe”; export async function POST(req: Request) { const body = await req.text(); // CRITICAL: raw text, not JSON const signature = (await headers()).get(“stripe-signature”)!; let event: Stripe.Event; try { event = stripe.webhooks.constructEvent( body, signature, process.env.STRIPE_WEBHOOK_SECRET! ); } catch (err) { return new NextResponse(“Invalid signature”, { status: 400 }); } if (event.type === “checkout.session.completed”) { const session = event.data.object as Stripe.Checkout.Session; // Fulfill the order here: mark paid, send the product, email receipt console.log(“Payment confirmed:”, session.id); } return NextResponse.json({ received: true }); } Two things catch almost everyone here. First, you must read the raw request body with req.text(), not parsed JSON, because Stripe verifies a signature against the exact raw bytes. Second, always return a 200 response, even for events you do not handle, otherwise Stripe retries for up to 72 hours. Verifying the signature is what proves the message genuinely came from Stripe and not an attacker. Step 5: Test locally with the Stripe CLI You cannot test webhooks just by clicking around, you need Stripe to reach your local server. The Stripe CLI does this. Install it, log in, then forward events to your app: stripe listen --forward-to localhost:3000/api/webhooks/stripe This prints a webhook signing secret (starting whsec_), put that in your STRIPE_WEBHOOK_SECRET. Now run a test payment through your checkout button using Stripe’s test card number, 4242 4242 4242 4242 with any future expiry and any CVC, and watch the CLI forward the checkout.session.completed event to your webhook. When your webhook logs the confirmation, the full loop works. Step 6: Go live Switching to real payments is a short checklist. Replace your test API keys with your live keys (from the Stripe Dashboard, after activating your account). In the Stripe Dashboard, under Developers then Webhooks, add your production webhook endpoint, https://your-domain.com/api/webhooks/stripe , and copy its signing secret into your production environment variables. Deploy, and run one real, small transaction to confirm the live flow end to end. On Vercel or similar, add all your environment variables in the project settings. That is it: real payments flowing, confirmed by webhook, with card security handled entirely by Stripe. The mistakes that break Stripe integrations A few errors catch almost everyone. Avoid these. Trusting the browser instead of the webhook. If you mark an order paid based on the user landing on your success page, you will lose orders and let people fake payments. The webhook is the only source of truth. This is the single most important rule. Parsing the webhook body as JSON. Reading the body any way other than raw text breaks signature verification. Use req.text(). Exposing the secret key. The secret key must stay server-side only. Never prefix it with NEXT_PUBLIC_ or use it in a client component. Not returning 200 from the webhook. If your handler errors or returns a non-200, Stripe retries for up to 72 hours. Handle events, then return 200. Forgetting the production webhook. Local testing uses the CLI; production needs a webhook endpoint registered in the Stripe Dashboard with its own signing secret. Forgetting this means payments work but orders never get fulfilled live. Ready to add payments to your app? Adding Stripe to a Next.js app is genuinely approachable: hosted Checkout handles the hard, sensitive parts, and a correct webhook makes it reliable. Get those two right, and you have production-grade payments without ever touching raw card data. When you want payments built properly, including subscriptions , multiple gateways, or complex billing, as part of a real product, the Craxinno team integrates Stripe and other payment gateways into Next.js and mobile apps. See recent work in the Craxinno portfolio, explore our custom software development service , or email sales@craxinno.com .
