How Much Does It Cost to Build a SaaS in 2026?
TL;DR
The cost to build a SaaS in 2026 runs $25K to $150K for most products, from $15K MVPs to $300K+ enterprise platforms. The biggest cost drivers aren't features — they're two architecture decisions: multi-tenancy and billing, both of which cost 2-3x more to add after launch. Validate with a lean MVP first, then fund each stage from the last.
How Much Does It Cost to Build a SaaS in 2026?
The cost to build a SaaS in 2026 runs between $25,000 and $150,000 for most products, with lean MVPs starting near $15,000 and enterprise platforms passing $300,000. That is the honest range. This guide helps you find your number inside it.
But here is what most SaaS cost guides get wrong. They treat the price as a sum of features, when the biggest cost drivers are two architecture decisions you make before writing a single feature: how you handle multiple customers (multi-tenancy), and how you handle subscriptions (billing). Get those right on day one and your SaaS scales cheaply. Bolt them on later, after launch, and you pay two to three times more to retrofit them. That is the real story of SaaS cost, and this guide walks through it.
We will break the cost down by stage, from MVP to enterprise, explain the SaaS-specific things that drive the price, expose the hidden costs, and share the one sequencing move that saves founders the most money.
The cost to build a SaaS by stage (2026)
SaaS is not built once. It grows through stages, and each stage has its own budget. These bands use Indian development rates, which run 40% to 60% below US and UK firms. For a US agency, multiply by roughly two to three.
Stage 1: The SaaS MVP — $15,000 to $50,000
The smallest version that proves people will pay. It has one core workflow, user authentication with team accounts, a basic dashboard, and one payment integration wired in from day one. Real multi-tenancy, where each customer's data is cleanly separated, is built into the foundation. Ships in about 3 to 4 months. The goal here is to validate demand, not to scale to thousands of users.
Stage 2: The growth SaaS — $50,000 to $150,000
This is where most B2B SaaS products actually launch to market. Multiple user roles and permissions, several integrations, custom reporting, a real admin panel, and subscription tiers with metering. Ships in about 5 to 8 months. Build this tier only after your MVP has proven that people want the product.
Stage 3: The enterprise SaaS — $150,000 to $300,000+
Now the platform serves large customers. Single sign-on, advanced security, compliance like SOC 2 or HIPAA, scalable multi-tenant architecture, and the reliability big clients demand. Long timeline, full team, ongoing governance. Compliance-heavy products in fintech and healthcare sit at the top of this range.
If you are weighing a SaaS against other kinds of builds, see our guide to custom software development cost for the wider picture, and our guide to the cost to build an MVP for how to scope a lean first version.
The two architecture decisions that drive SaaS cost
This is the part that separates a SaaS from an ordinary web app, and it is where the money really goes.
Multi-tenancy: keeping customers separate. A SaaS serves many customers from one system, and each customer's data must be perfectly walled off from the others. The common 2026 approach is a shared database with strict tenant scoping, which balances cost and isolation. Fully isolated databases per customer roughly double the cost. This decision shapes your entire architecture, which is why it must be made first, not later.
Billing and subscriptions: the engine of the business. A SaaS lives on recurring revenue, so subscription logic is core, not a feature. That means plan tiers, upgrades and downgrades, metered usage, failed-payment handling, and webhooks that keep everything in sync. The single most expensive mistake in SaaS is adding billing to a live product after launch. Wire it in from day one, even in the MVP.
Both of these are invisible to your users and enormous in your budget. A team that treats them as afterthoughts is a team that will bill you again later to fix them.
What actually drives your SaaS price
Beyond architecture, five factors move the number most.
Number and depth of features. The obvious driver. Every workflow is design, build, test, and integration time. Scope discipline is your biggest lever here.
Integrations. Connecting to Stripe, email, analytics, and other tools each adds work. Clean modern APIs are cheap; messy or legacy ones are not.
User roles and permissions. A single-role app is simple. A SaaS where admins, managers, and members each see different data and have different rights adds real complexity to design and security.
AI features. Adding AI, such as an assistant, smart search, or automation, typically adds 15% to 40% to the build due to data work, model integration, and guardrails.
Compliance. SOC 2, HIPAA, or GDPR requirements add a real security and legal layer. Compliance-heavy SaaS runs 25% to 40% more than the same product in an unregulated space.
The hidden costs founders forget
The build price is not the whole number. Budget for these too.
Ongoing infrastructure. Cloud hosting, database, and services scale with your users. Modern managed platforms like Vercel, Supabase, and Stripe keep this low early, often a few hundred dollars a month, but it grows with success.
Maintenance. Plan for 15% to 20% of the build cost every year for fixes, updates, and improvements. A SaaS your customers rely on cannot be left alone.
Payment processing. Stripe and similar services take a percentage of every transaction, roughly 2.9% plus a small fee, for the life of the product.
The cost of scaling. A successful MVP leads to a growth build, which leads to enterprise features. Each stage is real spend, so budget the journey, not just the first step.
A useful rule: budget your first-year running cost at 15% to 25% of the build cost, on top of the build itself.
The sequencing move that saves the most money
Here is the single most valuable decision in SaaS budgeting, and it is about order, not price.
Validate before you build big. The revenue from 50 early customers funds the custom build that serves 5,000. Founders who skip validation routinely spend $100,000 building a technically impressive product that discovers, too late, what a small, cheap prototype would have told them for a fraction of the cost.
The smart path is staged. Prove demand with a lean MVP, or even a no-code prototype, then invest in the growth build once real customers are paying, then add enterprise features once large clients ask for them. Each stage is funded by the proof from the last. Building the enterprise version before you have a single paying customer is the most common and most expensive mistake in SaaS. This is the same scope discipline that keeps any software project on budget: prove the small thing first, then expand.
How to control SaaS costs without cutting corners
Four moves keep a SaaS build lean without hurting the result.
Get the architecture right on day one. Multi-tenancy and billing decided early cost a fraction of what they cost to retrofit. This is the one place not to cut corners.
Cut features ruthlessly for the MVP. Sort features into must-have, should-have, and won't-have. Build only the must-haves. Analytics, deep customization, and extra integrations can wait for v2.
Use proven building blocks. Do not build authentication, billing, or hosting from scratch. Managed services like Clerk or Auth0, Stripe Billing, and Supabase save enormous time and cost, and they are more secure than a first custom version.
Hire experienced developers, not the cheapest. On a SaaS, senior engineers who make the right architecture calls early save far more than their higher rate, because they prevent the expensive rebuilds that sink budgets.
The most expensive SaaS is the one whose foundation has to be rebuilt. Spend where the architecture lives, and stay lean everywhere else.
Get an honest estimate for your SaaS
The right number depends on your features, architecture, compliance needs, and the stage you are actually at. There is no universal price, only the right one for your build.
The Craxinno team builds production SaaS on modern, scalable foundations, and we are happy to review your idea, map the real scope, and give you an honest estimate, including where you can spend less by staging the build. See recent work in the Craxinno portfolio, view our full stack on the technologies page, or email sales@craxinno.com.
Frequently Asked Questions
How much does it cost to build a SaaS in 2026?+
The cost to build a SaaS in 2026 ranges from $25,000 to $150,000 for most products. A lean MVP runs $15,000 to $50,000, a growth-stage SaaS runs $50,000 to $150,000, and an enterprise platform runs $150,000 to $300,000 or more. The price depends heavily on two architecture decisions, multi-tenancy and billing, plus features, integrations, and compliance needs.
Why is building a SaaS more expensive than a normal web app?+
Because a SaaS carries two hidden but expensive requirements: multi-tenancy, which keeps every customer's data cleanly separated, and subscription billing, the recurring-revenue engine. Both are invisible to users but shape the entire architecture. Getting them right on day one is far cheaper than retrofitting them to a live product, which can cost two to three times more.
How much does a SaaS MVP cost?+
A SaaS MVP costs $15,000 to $50,000 at Indian development rates, covering one core workflow, user authentication with team accounts, a basic dashboard, real multi-tenancy, and one payment integration wired in from day one. It ships in about 3 to 4 months and exists to validate demand, not to scale to thousands of users.
What are the hidden costs of building a SaaS?+
Beyond the build, budget for ongoing infrastructure that scales with users, maintenance at 15% to 20% of build cost per year, payment processing fees of roughly 2.9% per transaction, and the cost of scaling through growth and enterprise stages. A good rule is to budget first-year running costs at 15% to 25% of the build cost.
Should I use no-code or custom code to build my SaaS?+
Use no-code to validate, custom code to scale. A no-code prototype can prove demand cheaply and quickly, often for a few thousand dollars. Once real customers are paying, invest in a custom build that scales. Founders who skip validation often spend six figures building the wrong product, discovering too late what a cheap prototype would have revealed.
Need this built properly?
Custom software from scoping to deployment — production code from week one, bi-weekly demos.
Start a projectKeep ReadingMore case studies like this
Engineering retros, product launches, and brand systems from our studio — updated monthly.
All case studiesTechnology Used
.svg){kind=logo}
Node.js
TypeScript
Next.js
AWS
React
Vercel
StripeTags & Keywords
Continue with Blogs.
View all blogs
Software AgencyHow to Vet a Software Development Agency Before You Hire
How to Vet a Software Development Agency Before You Hire Vetting a software development agency before you hire comes down to one principle: judge them on evidence, not on the pitch. Any agency can build a polished website and a confident sales call. What separates the ones who deliver from the ones who disappoint is what they show you when you ask the right questions, real work, real references, a real process, and honest answers about how they handle problems. We are an agency, so we will be straight about the uncomfortable parts, including the questions that expose a weak agency and the red flags that should make you walk away, even from a team that pitches well. This guide gives you a practical vetting process: what to check before you talk, the questions that reveal the truth on a call, the warning signs, and how to test an agency cheaply before you commit real money. This is not about finding the biggest or cheapest agency. It is about finding the one that will actually ship what you need, on time, without drama. The quick answer: how to vet an agency If you want the process in one glance, here it is. Each part is detailed below. Check the evidence first: real portfolio work, live products you can use, and references you can actually call. Then ask the hard questions: how they run projects, who does the work, how they handle delays, and what happens when something breaks. Watch for red flags: vague answers, no clear process, only good news, and pressure to sign fast. Then test small: a paid trial task before a big commitment. Judge what they show you, not what they say. The agencies worth hiring make this easy, because they have real work and a real process to point to. The ones to avoid get vague exactly where it matters. Before you talk: what to check on your own Do this homework before the first call, and half the field eliminates itself. Look at real, live work, not just screenshots. A portfolio of pretty mockups proves nothing. Ask for links to products actually in use, and open them. Do they work well? Are they fast? Would you be happy if that were your product? Real, shipped software is the single strongest signal an agency can give. Check for depth in your kind of project. An agency that has built things like what you need, your platform, your industry, your complexity, carries hard-won knowledge a generalist does not. Look for evidence they have solved your specific kind of problem before. Read reviews on independent platforms. Look beyond the testimonials on their own site, which are curated. Check independent sources for patterns, especially in how they handle things going wrong, since every project hits bumps and the reviews reveal how an agency behaves when they do. Look at how they communicate before you hire. Their responsiveness, clarity, and professionalism during your first few emails is a preview of what working with them will feel like. Slow, vague, or careless now rarely improves later. The questions that reveal the truth on a call Once you are talking, these questions separate real agencies from good salespeople. Ask them directly and listen for specifics. "Can I see work similar to my project, and talk to that client?" A confident agency offers references freely. Hesitation here is a warning. Actually calling a reference is one of the most revealing things you can do, and most buyers skip it. "Who exactly will work on my project?" You want to know whether the senior people in the sales meeting are the ones who build, or whether the work is quietly handed to juniors. Ask who your team is and who leads delivery. "How do you run a project week to week?" Listen for a real process: regular demos, clear communication, and a way to track progress. A vague "we're agile" with no specifics often means no real process at all. This is exactly what good project management looks like , and its absence is a serious risk. "How do you handle delays and problems?" Every project has them. A strong agency describes a process for surfacing issues early and honestly. An agency that only talks about smooth successes is either inexperienced or not being straight with you. "How do you handle changes to scope?" Look for a clear, open process for new requests, so you are never surprised by an invoice or a silent delay. Vagueness here predicts budget pain later. "What does your testing and QA process look like?" An agency that treats quality as an afterthought ships buggy work. A serious one has a real approach to testing, because skipping QA costs far more than it saves . The red flags that should make you walk away Some signals mean stop, even if everything else looks good. The price is far below everyone else. A quote dramatically under the rest of the market is not a bargain; it usually signals inexperience, hidden costs, or corners about to be cut. The cheapest agency is rarely the cheapest outcome. They cannot show real, live work. If everything is "under NDA" or only exists as mockups, be skeptical. Legitimate agencies can almost always show something real. There is no clear process or point of contact. If you cannot get a straight answer on how projects run or who owns your delivery, expect chaos once the work starts. They only tell you what you want to hear. An agency that agrees with everything, promises everything, and raises no concerns is selling, not advising. The good ones push back and tell you hard truths before you hire, not after. They pressure you to sign quickly. Urgency and "this price is only good today" are sales tactics, not signs of a good partner. A confident agency lets the evidence speak and gives you time. Vague pricing and scope. If they will not put a clear scope and price in writing, that ambiguity will cost you later . Get specifics before money changes hands. Test small before you commit big Here is the single most effective way to vet an agency, and most buyers never do it. Start with a small, paid trial project before the large commitment. A well-scoped first task, a small feature, a prototype, a self-contained piece of the work, tells you more in two weeks than any number of sales calls. You see how they actually communicate, how they handle feedback, whether they hit their estimate, and whether the work is good. A confident agency welcomes this, because they know their work will earn the larger project. An agency that resists a paid trial, or insists you commit to everything up front, is telling you something. This staged approach removes almost all of your risk, and it is exactly how the best client-agency relationships tend to begin. How to make the final decision Once you have done the homework, asked the questions, and ideally run a trial, the decision gets simpler. Weigh evidence over impression. The agency that showed real work, gave real references, explained a real process, and delivered a solid trial is a safer bet than the one that merely pitched better. Charisma is not delivery. Weigh fit over size. The right agency for you is the one that fits your project, your stage, and your communication style, not necessarily the biggest name or the lowest price. A great fit at a fair price beats a famous logo that treats you as a small account. Trust how it felt to work with them. Your experience during vetting, the clarity, the honesty, the responsiveness, is the most reliable preview of the whole engagement. Believe it. Ready to work with an agency that earns it? Vetting well is worth the effort, because the cost of choosing wrong, a blown budget, a missed deadline, a product you have to rebuild, dwarfs the time it takes to check properly. Judge on evidence, ask the hard questions, watch for the red flags, and test small before you commit. The Craxinno team is happy to be vetted exactly this way, with real work to show, references to call, a clear process, and a paid trial task to prove the fit before you commit. See recent work in the Craxinno portfolio , view how we work on the work process page, or email sales@craxinno.com .
NginxNginx SSL Setup: Free HTTPS with Let's Encrypt
Nginx SSL Setup: Free HTTPS with Let's Encrypt Setting up SSL on Nginx with Let's Encrypt gives your site free HTTPS in about ten minutes, and it is far simpler than most people expect. You do not hand-edit certificates or wrestle with config files. A tool called Certbot does the hard parts for you: it gets the certificate, rewrites your Nginx config to use it, and even sets up the automatic HTTP-to-HTTPS redirect. This guide walks through the whole process, start to finish. Here is the one part you must not skip, and the part cheap tutorials gloss over. Let's Encrypt certificates expire every 90 days. If a certificate expires, your entire site goes offline for every visitor, showing a scary security warning. So the goal is not just to turn on HTTPS today; it is to set up automatic renewal so it stays on forever without you thinking about it. We will cover both. The quick answer: the whole process If you just want the path, here it is. Details for each step follow. Point your domain at your server and make sure Nginx is running. Install Certbot and its Nginx plugin. Run one Certbot command to get the certificate and configure HTTPS automatically. Choose to redirect all traffic to HTTPS. Test that automatic renewal works. That is it. The single Certbot command does most of the work. The renewal test at the end is what guarantees your site never goes down from an expired certificate. What Let's Encrypt and Certbot actually are Two quick definitions, because they do different jobs. Let's Encrypt is a free, automated certificate authority. A certificate authority is the trusted organization that issues the SSL/TLS certificates browsers rely on to show the padlock and enable HTTPS. Traditionally these cost money; Let's Encrypt provides them free, and its certificates are trusted by every major browser. Certbot is the tool that talks to Let's Encrypt for you. It proves you own your domain, downloads the certificate, installs it, edits your Nginx configuration to use it, and sets up renewal. In short: Let's Encrypt issues the free certificate, and Certbot does the work of getting and installing it. Together they turn what used to be a fiddly paid process into a few free commands. Prerequisites Get these in place first, or the process will fail at the domain-verification step. A server running Nginx on Linux (Ubuntu or Debian for this guide), which you can access over SSH with sudo privileges. A registered domain name whose DNS A record points to your server's public IP address. This is essential, Let's Encrypt verifies you control the domain by reaching it over the internet, so the domain must resolve to your server before you start. Ports 80 and 443 open on your server's firewall, since Let's Encrypt uses port 80 to verify ownership and port 443 serves the secure traffic. Step 1: Install Certbot and the Nginx plugin Connect to your server over SSH, then update your package list and install Certbot with its Nginx plugin: sudo apt update sudo apt install certbot python3-certbot-nginx -y Confirm it installed: certbot --version The python3-certbot-nginx plugin is the important part, it is what lets Certbot read and edit your Nginx configuration automatically, which is what makes this whole process easy. Step 2: Get your certificate and enable HTTPS This is the step that does almost everything. Run one command, replacing the domains with your own: sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com Certbot will ask for an email address (for renewal reminders and urgent notices) and ask you to agree to the terms. Then, on its own, it verifies you own the domain, obtains the certificate from Let's Encrypt, edits your Nginx configuration to use it, and reloads Nginx. When it asks whether to redirect HTTP traffic to HTTPS, choose yes (the redirect option). This ensures visitors always land on the secure version of your site. That single command has now given you working HTTPS. Step 3: Confirm HTTPS is working Open your site in a browser using https:// and look for the padlock icon in the address bar. Click it, and you should see that the connection is secure and the certificate was issued by Let's Encrypt. For a thorough check, you can run your domain through a public SSL testing tool, which grades your configuration and flags any weaknesses. A clean result here means your certificate and Nginx settings are solid. Step 4: Set up automatic renewal (do not skip this) This is the step that keeps your site online for good. Let's Encrypt certificates last only 90 days, so they must be renewed regularly, and doing it by hand is a recipe for an eventual, avoidable outage. The good news: modern Certbot sets up automatic renewal for you during installation. It installs a scheduled task (a systemd timer) that quietly checks twice a day and renews any certificate close to expiry. You usually do not have to configure anything. What you must do is confirm it works. Run a renewal dry run, which simulates a renewal without actually doing one: sudo certbot renew --dry-run If it completes without errors, your automatic renewal is working, and your certificate will keep renewing itself indefinitely. This one test is the difference between "set and forget" and a surprise outage in three months. Step 5: Reload Nginx automatically after renewal One refinement worth adding. When a certificate renews, Nginx needs to reload to actually start serving the new one. Modern Certbot generally handles this, but you can make it explicit and reliable with a deploy hook, a small script Certbot runs automatically after every successful renewal, that reloads Nginx. Adding this guarantees the freshly renewed certificate is served immediately, with no manual step and no gap. Common problems, and how to fix them A few issues catch almost everyone. Here is how to clear them fast. "Challenge failed" or domain verification error. Your domain's DNS is not yet pointing to the server, or port 80 is blocked. Confirm your A record resolves to the server's IP and that the firewall allows port 80, then try again. The certificate works but the site still shows "not secure." Nginx may not have reloaded, or HTTP is not redirecting. Reload Nginx and confirm you chose the HTTPS redirect in Step 2. Renewal dry run fails. Something changed since setup, often the Nginx config or the domain's DNS. The error message points to the cause; fixing it now prevents a real expiry outage later. "Too many certificates already issued." Let's Encrypt limits how many certificates you can request for a domain in a short window. Wait for the window to reset rather than retrying repeatedly. Ready to ship a secure, production-ready site? Getting free HTTPS on Nginx with Let's Encrypt is genuinely quick, and with automatic renewal set up and tested, it stays secure without any ongoing effort. The padlock is not just for trust; it is required for modern SEO and for many browser features, so it is one of the highest-value ten-minute jobs you can do for a site. If you would rather have secure, well-configured hosting handled as part of a real product build, the Craxinno team sets up and maintains production infrastructure for clients regularly. See recent work in the Craxinno portfolio , view our full stack on the technologies page , or email sales@craxinno.com .
Google Places APIHow to Get a Google Places API Key (Step-by-Step)
How to Get a Google Places API Key (Step-by-Step) Getting a Google Places API key takes about five minutes, and this guide walks you through every step. But here is the part most tutorials rush past, and the part that actually matters: creating the key is easy, and restricting it is what saves you from a surprise bill. An unrestricted key that leaks can be used by anyone, and the charges land on you. So we will get your key first, then lock it down properly. One thing to know up front, because it catches everyone: Google requires you to enable billing and add a credit card, even if you only plan to use the free tier. The key itself is free to create, and Google will not charge you unless you exceed the generous free limits, but the card is mandatory. This guide covers the full setup, how to secure the key, and how to make sure you never pay more than you meant to. The quick answer: the six steps If you just want the path, here it is. Each step is detailed below. Create a Google Cloud project at the Google Cloud Console. Enable billing (a credit card is required, even for the free tier). Enable the Places API for your project. Create the API key under Credentials. Restrict the key immediately by app and by API. Set quotas and budget alerts so you never overspend. The whole thing takes a few minutes. The two steps people skip, restriction and quotas, are the two that protect your wallet, so do not skip them. What a Google Places API key actually is A quick definition, so the steps make sense. The Google Places API is a service that lets your website or app use Google's location data, searching for places, autocompleting addresses as a user types, and pulling details like a business's name, hours, or rating. An API key is a unique string of characters that identifies your project to Google every time your app makes one of these requests. It is both your pass to use the service and the way Google tracks your usage for billing. Think of the key like a membership card with your name on it. It lets you in, and everything you do is charged to your account. That is exactly why keeping it private and restricted matters so much, which we will cover after the setup. Step 1: Create a Google Cloud project Go to the Google Cloud Console at console.cloud.google.com and sign in with a normal Google account. At the top of the page, click the project dropdown, then New Project. Give it a clear name (something like "my-app-places") and click Create. If you are new to Google Cloud, you will also be offered a $300 free trial credit that lasts 90 days. This is separate from the Places API free tier and applies across Google Cloud, so it is a useful cushion while you get set up. Step 2: Enable billing This is the step that surprises people. Before you can use the Places API, you must enable billing on your project, which means adding a credit card, even if you intend to stay entirely within the free tier. In the console menu, go to Billing, then link or create a billing account and add your card. Google will not charge you unless your usage goes past the free monthly limits, but it will not let you use the API at all without a card on file. This is normal and required for everyone. Step 3: Enable the Places API Now turn on the specific service you need. In the console menu, go to APIs & Services, then Library. Search for "Places API," select it, and click Enable. Only enable the APIs you actually plan to use. Each one is billed separately, so enabling extras you do not need just widens the surface where costs, or mistakes, could appear. Step 4: Create your API key With the Places API enabled, go to APIs & Services, then Credentials. Click Create Credentials at the top, and choose API key. Google generates your key instantly and shows it in a dialog. Copy the key somewhere safe. This is the string your app will use to make requests. Do not paste it into public code, a public repository, or anywhere it can be seen, for reasons the next step makes clear. Step 5: Restrict your key (the step that protects you) This is the most important step in the whole guide, and the one most tutorials treat as optional. It is not optional. An unrestricted key is a key anyone can steal and use, running up charges billed to you. Restrict it in two ways. First, application restrictions: tell Google which websites, apps, or IP addresses are allowed to use this key, so a stolen key will not work from anywhere else. For a website, restrict it to your domain. Second, API restrictions: limit the key to only the Places API, so even if it leaks, it cannot be used for other, pricier Google services. On the key's settings page in Credentials, set both restrictions and save. A properly restricted key is nearly useless to anyone who steals it, which is exactly what you want. Step 6: Set quotas and budget alerts The final safety layer. Restriction stops misuse; quotas and alerts stop overspending. Set a quota limit on your Places API usage, ideally at or below the free monthly allowance, so requests simply stop once you hit your ceiling rather than rolling into paid usage. Quotas are the control that actually prevents charges. Then set a budget alert so Google emails you when spending approaches a limit you choose. Note the difference: a budget alert only warns you, while a quota actually caps usage. Use both, but rely on the quota to protect the bill. What the Google Places API costs in 2026 A quick, honest picture so there are no surprises. Google Places uses pay-as-you-go pricing, billed per SKU, meaning each type of request- a search, an autocomplete, a place-details lookup- has its own price. There is a free monthly allowance for each, and you only pay once you exceed it. As rough 2026 figures, a text search runs a few dollars per 1,000 requests, and a place-details call runs higher, in the range of several dollars to around $17 per 1,000 depending on how much data you request. One counterintuitive thing worth knowing: with autocomplete, an abandoned search where the user types and then leaves can sometimes cost more than a completed one, because each keystroke can trigger a billable request. This is exactly why the quotas in Step 6 matter. Always check Google's official pricing page for current, exact numbers before you launch, since these change. Common problems, and how to fix them A few issues catch almost everyone. Here is how to clear them fast. "This API key is not authorized." Your key restrictions are blocking the request. Check that your app's domain or IP is in the allowed list, and that the Places API is among the key's allowed APIs. "Billing not enabled." You skipped or did not finish Step 2. Add a valid credit card to the billing account, even for free-tier use. The key works locally but not in production. Your application restrictions likely allow your test environment but not your live domain. Add the production domain to the allowed list. Unexpected charges. Almost always an unrestricted key that leaked, or missing quotas. Restrict the key immediately and set a quota below the free allowance. Ready to build with Google's location data? Getting a Google Places API key is quick, but doing it safely- restricting the key and capping usage- is what separates a smooth launch from a surprise invoice. Follow the six steps above, and you get a working key that stays secure and stays within budget. If you would rather have the setup, integration, and cost controls handled properly as part of a real product build, the Craxinno team implements Google Maps and Places integrations for clients regularly. See recent work in the Craxinno portfolio , view our full stack on the technologies page , or email sales@craxinno.com .
© 2026 — Craxinno Technologies
