DEV Community: Ravi Rai

From Excel to a CRM in 2026: When to Switch, and How to Move Without the Chaos

Ravi Rai — Mon, 29 Jun 2026 20:16:56 +0000

Nearly every business starts the same way. Sales lives in a spreadsheet. One tab for leads, one for customers, a column for status, and a colour code only the person who built it really understands. For a while this works beautifully, and anyone who tells you to buy a CRM on day one is usually selling one. A spreadsheet is free, flexible, and instant. The trouble is that it scales right up until it doesn't, and the day it stops working, it stops working quietly. No alarm goes off. You just start losing deals you never knew you had.

This post is the honest version of the Excel-to-CRM conversation. Not a pitch to rip out your sheet tomorrow, but a clear way to tell when you have genuinely outgrown it, what a migration actually involves, how to move your data over without losing your history, and the part everyone underestimates: how to get your team to actually use the new system instead of drifting back to the old one. We have moved enough businesses off spreadsheets to know where it goes wrong.

If you want to see what the other side looks like before reading on, you can explore the BuildByRavi CRM live demo and click through a real pipeline, dashboard, and reports. Log in with demo@buildbyravi.com and the password Demo@2026. Seeing a working pipeline next to your spreadsheet makes the gap obvious faster than any list of features.

When a spreadsheet is still the right answer

Let us be fair to the spreadsheet first, because switching too early wastes money and goodwill. If you are one or two people, your deal volume is low enough that nothing slips, you can hold the whole pipeline in your head, and you are still figuring out what your sales process even is, a sheet is perfect. It costs nothing, it bends to whatever you need, and there is no setup. Plenty of healthy businesses run on Excel or Google Sheets far longer than a software salesperson would like to admit. The question is not whether spreadsheets are good or bad. It is whether yours has started leaking.

The signs you have outgrown the sheet

You rarely decide to leave the spreadsheet. You notice, one painful incident at a time, that it can no longer hold your business. The common signs:

Leads are falling through gaps. Someone meant to follow up, the row scrolled out of view, and three weeks later the customer bought from a competitor who simply replied. If you cannot say what the next action is for every open deal, the sheet is failing at its one job.
More than one person needs it at once. The moment two or three people edit the same file, you get version conflicts, overwritten cells, and the dreaded 'final_v3_latest' copies. Spreadsheets were never built for a team working a shared pipeline.
Nobody trusts the numbers. When the forecast in the sheet and reality have quietly drifted apart, every meeting turns into an argument about whose copy is right instead of which deals to chase.
Follow-up depends on memory. A spreadsheet cannot remind you, message a customer, or chase a quote on its own. If your follow-up only happens when a human remembers, you are losing the deals that needed a second or third touch.
You cannot see history. Who spoke to this customer last, what was said, what was promised? A sheet shows the current state, not the story, and that story is where deals are won or lost.
Reporting takes hours. If pulling a simple 'how many deals did we close this month and why did we lose the rest' answer means an evening of copy-paste, the sheet has become the bottleneck.

One of these is a nuisance. Three or more, week after week, is the spreadsheet telling you it is done. The cost is rarely a dramatic disaster. It is the slow, invisible bleed of deals that quietly went nowhere because the system forgot them.

What you actually gain by moving

A CRM is not a fancier spreadsheet. The point of moving is to get things a sheet structurally cannot do. Every contact carries its full history, so anyone can pick up a conversation without asking around. Follow-up runs on its own through reminders and automated sequences, so the second and third touch happen whether or not anyone remembers. The whole team works one shared pipeline in real time with no version conflicts. The forecast reflects what is actually happening rather than someone's optimism. And in India specifically, the conversation can live on WhatsApp where deals really close, logged against the right lead instead of trapped on one person's phone. We walked through each of these in detail in what a modern sales CRM should do. The short version: a CRM stops you losing deals you never knew you were losing.

How a migration actually works

The word 'migration' sounds heavier than it is. For most small and mid-sized businesses, moving off a spreadsheet is a few focused days, not a quarter-long project, as long as you do it in the right order:

Clean the sheet first. A migration is the best chance you will ever get to throw out dead leads, duplicate rows, and the columns nobody has filled in for a year. Move tidy data, not a mess, because garbage that goes in is garbage that comes out, now in a more expensive tool.
Map your columns to fields. Decide what each spreadsheet column becomes in the CRM: which is the contact name, the company, the deal value, the stage, the owner. This mapping is the real work, and getting it right is what makes the new system feel like yours.
Define your stages honestly. Your pipeline stages should match how you actually sell, not a generic template. New lead, contacted, quoted, negotiating, won, lost is a fine start. The CRM should fit your process, not force you into someone else's.
Import in one clean pass. Export the sheet to CSV, import it, and check a handful of records by hand to confirm everything landed in the right place. A good CRM import is mostly a file upload and a column match.
Keep the old sheet read-only for a bit. Do not delete it on day one. Freeze it as a backup and a reference for a few weeks until everyone trusts the new system, then archive it.

That is the whole shape of it. The data move is the easy part. The hard part, the part that decides whether the migration succeeds, comes next.

The real challenge is adoption, not data

Here is the uncomfortable truth that most CRM articles skip: roughly half of CRM rollouts fail, and almost never because the data did not import. They fail because the team quietly goes back to the spreadsheet. If the CRM feels heavier than the sheet it replaced, reps will route around it, keep their real pipeline in WhatsApp and a private tab, and within a month your shiny new system is a half-empty graveyard that everyone lies to in meetings. Avoiding that is mostly about a few human choices, not technology:

Make it lighter than the spreadsheet, not heavier. If logging a deal takes more clicks than typing a row, you have already lost. The CRM has to remove work, not add it.
Start with only the fields you need. A new system with forty mandatory fields is a system nobody fills in. Begin with the handful that matter and add more once the habit sticks.
Move everyone at once. If half the team is on the CRM and half is still on the sheet, both fail. Pick a date, move together, and freeze the old sheet so there is no fallback.
Let leadership live in it. If the boss still asks for updates over WhatsApp and reads the old spreadsheet, the team learns the CRM is optional. When the forecast everyone is judged on comes out of the CRM, the CRM gets used.
Show the win early. Nothing drives adoption like a rep closing a deal because the system reminded them to follow up. Find that story in the first two weeks and tell it.

Get adoption right and the migration pays for itself fast. Get it wrong and the cleanest data import in the world ends up in a tool nobody opens.

Off-the-shelf, or built around how you sell?

Once you have decided to move, the next fork is which CRM. The global names, Salesforce and HubSpot, are powerful but heavy, priced in dollars, and they make you bend your process to fit their software, which is exactly the friction that kills adoption for a small Indian team. We broke down the real numbers in custom CRM vs Salesforce and HubSpot. For most businesses coming off a spreadsheet, the better fit is a focused CRM that matches your workflow out of the box, or a custom one shaped around exactly how you sell, with only the modules you need. For marketplace and multi-seller businesses we package this as the MultiVendor CRM. The deciding question is never which CRM has the most features. It is which one your team will actually use.

What it costs to make the move

Cost has two parts, and people usually only think about the first. There is the price of the CRM itself, which for a small team can start free and scale with seats, and there is the cost of the move: cleaning data, mapping fields, importing, and training the team. The second is almost always the bigger number, and it is mostly time rather than money. Set against that is the cost of staying on the spreadsheet, which is invisible precisely because you never see the deals it loses. Most businesses that switch find the migration pays for itself within a couple of months of recovered, no-longer-leaking deals. If you want a rough figure for a custom build shaped around your process, the cost calculator gives a starting estimate, and the honest comparison lives in our custom CRM pricing guide.

How we handle the move

When we move a business off a spreadsheet, we treat the migration and the adoption as one job, because a perfect import that nobody uses is a failure. We clean and map your data, set up the stages and fields to match how you actually sell, import your history so nothing is lost, and get your team to a usable pipeline before adding anything fancy. Under the hood, BuildByRavi CRM is a multi-tenant web application on a Node.js backend with WhatsApp messaging built in, and when a business needs something specific to how it sells, we customise from what we have already built rather than starting from a blank page. You get a real working system in days, not a six-month software project.

Common questions about moving from Excel to a CRM

When should I move from a spreadsheet to a CRM?

When the spreadsheet starts costing you deals rather than saving you money. The clearest signals are leads slipping through the cracks, more than one person needing the file at once, follow-up depending on memory, and reporting taking hours. If one or two of those are happening occasionally, the sheet is probably still fine. If three or more happen every week, you have outgrown it and the leak is real.

Will I lose my data when I move to a CRM?

No, a proper migration keeps all of it. You export your spreadsheet to CSV, map each column to a CRM field, and import it in one pass, then spot-check a few records to confirm everything landed correctly. The smart move is to keep the old sheet frozen as a read-only backup for a few weeks until everyone trusts the new system, so there is always a safety net during the switch.

How long does it take to move from Excel to a CRM?

For most small and mid-sized businesses, the data move is a few days, not months. Cleaning and mapping the data is the real work; the import itself is mostly a file upload and a column match. What takes longer, and matters more, is adoption: giving the team a couple of weeks to build the habit of working in the CRM instead of the sheet. The technology is fast. The behaviour change is what to plan for.

Why do CRM rollouts fail, and how do I avoid it?

They fail because the team quietly returns to the spreadsheet, almost always because the CRM felt heavier than the sheet it replaced. Avoid it by making the CRM lighter to use than Excel, starting with only the fields you truly need, moving the whole team on one date with no fallback, and having leadership read the forecast out of the CRM rather than asking for updates elsewhere. Adoption is a human problem, not a software one.

Is a free CRM enough, or do I need a custom one?

For a small team just leaving a spreadsheet, a focused CRM with a free or low-cost tier is often the perfect first step, and far better than staying on Excel. You move to a custom build when your sales process is specific enough that off-the-shelf tools force you to work around them, or when you need particular integrations like WhatsApp, payments, or your accounting tool. Start with what gets you off the sheet fastest, and customise once you know exactly what you need.

Honest summary

Spreadsheets are a great place to start and a terrible place to scale. You have outgrown yours when leads start slipping, the team trips over a shared file, follow-up depends on memory, and nobody trusts the numbers. Moving off it is not the heavy project people fear: clean the data, map the columns, import in one pass, and keep the old sheet as a backup. The part that actually decides success is adoption, so make the CRM lighter than the spreadsheet, move everyone together, and let leadership live in it. Do that, and you stop losing the deals the sheet was quietly dropping.

Still running sales on a spreadsheet and feeling the cracks? See the BuildByRavi CRM live demo (log in with demo@buildbyravi.com and password Demo@2026), then message us on WhatsApp with how your sheet is set up today and we will tell you honestly whether it is time to move and what it would take.

Outgrowing the spreadsheet? We move Indian businesses from Excel to a CRM the right way: clean your data, import your history, set up the pipeline around how you actually sell, plug in WhatsApp, and get your team genuinely using it instead of drifting back to the sheet. See what we have built, then let us move you. → Explore the MultiVendor CRM

What a Modern Sales CRM Should Do in 2026 (Inside BuildByRavi CRM)

Ravi Rai — Sun, 28 Jun 2026 08:20:59 +0000

Most businesses do not lose deals because their product is weak. They lose deals because follow-up leaks. A lead comes in, someone means to call back, and three days later it is buried under newer work. The spreadsheet forgot, the sticky note vanished, and a customer who was ready to buy quietly went to whoever replied first. A CRM exists to stop that leak. We built BuildByRavi CRM as our own take on what a modern sales platform should do, and this post is a walk through what is inside it and why each piece earns its place.

One honest thing up front: a CRM is only worth it if your team actually uses it. Half of CRM rollouts fail because the tool is heavier than the problem it solves, so reps go back to WhatsApp and notebooks. So everything here is built around speed and clarity, not a feature checklist. A good CRM should feel like it removes work, not adds it.

Prefer to see it rather than read about it? You can explore the BuildByRavi CRM live demo and click through the dashboard, pipeline, and reports as you go. Log in with demo@buildbyravi.com and the password Demo@2026. Here is what each part does and why it is there.

Find the leads worth chasing

Most pipelines are full of names that will never buy. The cost is not just wasted time, it is that real buyers get the same lukewarm attention as dead ones. BuildByRavi CRM filters prospects by intent signals, so reps spend their hours on the accounts actually showing buying behaviour instead of working the list top to bottom. The job of a CRM is not to store every contact, it is to point you at the next right conversation.

Let the follow-up run itself

Follow-up is where humans are weakest and software is strongest. BuildByRavi CRM runs multi-step sales sequences with built-in A/B testing, so the second, third, and fourth touch happen on schedule whether or not anyone remembers. No-code automation workflows handle the busywork around them: move a deal stage, assign an owner, fire a reminder, log an activity, all without a developer. The rep does the human part, the talking, and the system does the parts humans forget.

Meet customers where they already are: WhatsApp

In India, deals do not close over email. They close on WhatsApp. A CRM that ignores that is fighting reality, so BuildByRavi CRM has WhatsApp Business messaging built in, with conversations logged against the right lead instead of trapped on one rep's phone. If you are weighing this seriously, we wrote a full guide to a WhatsApp CRM setup and cost, and a primer on what the WhatsApp Business API actually is. For Indian sales teams, this single feature usually moves the needle more than any other.

Know which deals are real

Every founder has been burned by a forecast built on optimism. A rep says a deal is 'almost closed' and it slips for the third month running. BuildByRavi CRM uses AI-powered forecasting and deal risk scoring to flag the deals that are stalling, the ones with no recent activity, and the ones the numbers say will not land, so your forecast reflects what is actually happening rather than what everyone hopes. Knowing a deal is at risk while you can still save it is worth more than any dashboard.

Learn from every call

Your best rep does something on calls your newest rep does not, and usually nobody can say exactly what. BuildByRavi CRM records and transcribes calls and turns them into coaching, so the patterns that win become teachable instead of locked in one person's head. A built-in AI co-pilot drafts replies and summarises calls, which means less time typing notes and more time selling. The CRM stops being a filing cabinet and starts being a coach.

Keep your data yours

A CRM holds your most valuable asset: every customer relationship you have. So control is not optional. BuildByRavi CRM has role-based access and audit trails, so the right people see the right data, departing employees cannot walk out with your whole pipeline, and you can always see who changed what. This matters more the moment you grow past a handful of trusted people.

The numbers we built it around

Every feature above exists to move a real metric. These are the targets BuildByRavi CRM is designed to hit, and the reason each module is in the product rather than the goals of any one customer, since your results depend on your team and your market:

Around 2.4x more replies from disciplined, tested sequences instead of one-and-done outreach.
Roughly 38% faster sales cycles when follow-up is automatic and the right leads get worked first.
Forecast accuracy within about 4%, so the number you tell your board is closer to the number that lands.
A free tier for up to 3 seats, so a small team can start without a budget conversation.
Setup in under an hour, because a CRM nobody finishes configuring is a CRM nobody uses.

Off-the-shelf or built for your workflow?

Salesforce and HubSpot are powerful, but they are heavy, priced in dollars, and they make you bend your process to fit their software. For a lot of Indian teams that means paying for ninety features to use nine, and fighting the tool every day. A CRM shaped around how your team actually sells wins on the only metric that matters for a CRM: whether people use it. We break down the real cost and trade-offs in custom CRM vs Salesforce and HubSpot, and for marketplace and multi-vendor businesses we package this as the MultiVendor CRM, a CRM built for businesses that sell through many sellers at once.

How we build it

Under the hood, BuildByRavi CRM is a multi-tenant web application on a Node.js backend, with the WhatsApp Business API for messaging, a clean internal API for the automations and integrations, and role-based security throughout. The same engineering we use for client SaaS builds goes into it, which is the point: when we build a custom CRM for your business, you get a real product, not a spreadsheet with a login screen.

Common questions about getting a CRM

Can you build a custom CRM for my business?

Yes. BuildByRavi CRM is our own product, but we also build CRMs shaped around how a specific business sells, with only the modules you need, your fields, your stages, and integrations like WhatsApp, payments, or your accounting tool. The fastest path is usually to start from what we have already built and customise, rather than from a blank page. Tell us how your team sells and we will scope it.

How long does it take to set up a CRM?

BuildByRavi CRM itself is designed to set up in under an hour for a standard sales workflow. A customised CRM built around your exact process takes longer, typically a few weeks depending on integrations, but you are never staring at a blank, generic system wondering where to start. We get you to a usable pipeline first, then refine.

Does it work with WhatsApp?

Yes, WhatsApp Business messaging is built in, because for most Indian sales teams that is where deals actually happen. Conversations are logged against the right lead so nothing lives only on a personal phone. See our WhatsApp CRM guide for how it works in practice.

Is it cheaper than Salesforce or HubSpot?

For most small and mid-sized Indian businesses, yes, both to run and to actually adopt. Global CRMs charge per seat per month in dollars and pile on features you will not use. A focused CRM, or a custom one built around your workflow, usually costs less over time and gets used more. We lay out the full comparison in custom CRM vs Salesforce and HubSpot.

Who owns the data?

You do. With role-based access and audit trails, you control who sees what, and with a custom build you can host it where you want. Your pipeline is your business, and it should never be hostage to a vendor or a single employee's phone.

Honest summary

A modern sales CRM in 2026 should do five things well: point you at the leads worth chasing, run the follow-up automatically, meet customers on WhatsApp, tell you honestly which deals are real, and turn your best calls into coaching for everyone else. That is what we built BuildByRavi CRM to do, and it is the same standard we hold a custom CRM to when we build one for a client. A CRM that just stores contacts is a spreadsheet with extra steps. A CRM that grows revenue earns its place.

Want a CRM built around how your team actually sells? Try the BuildByRavi CRM live demo to see it in action (log in with demo@buildbyravi.com and password Demo@2026), then message us on WhatsApp with how you sell today, or use the cost calculator for a rough estimate on a custom CRM build.

Tired of leads leaking out of spreadsheets? We build sales CRMs that surface the right leads, automate follow-up, plug into WhatsApp, and forecast honestly, shaped around how your team actually sells. See what we have built, then let us build yours. → Explore the MultiVendor CRM

REST API Design Best Practices 2026: How to Build APIs That Last

Ravi Rai — Sun, 28 Jun 2026 07:26:01 +0000

An API is a promise you make to everyone who builds on it. The moment your mobile app, your web frontend, or a partner integrates with it, that shape is hard to change and dangerous to break. Rename a field or change a status code and somewhere an app stops working, often silently, often in production. That is why API design deserves real thought up front, even though it feels invisible to anyone who is not a developer.

The reassuring part is that good API design is mostly conventions, not cleverness. Decades of people building HTTP APIs have settled on a set of patterns that just work, and following them makes your API predictable, easy to consume, and safe to evolve. This is the practical guide to designing REST APIs in 2026: the conventions that matter, and the mistakes that quietly cost teams later.

Resources and naming

REST is built around resources (things), addressed by URLs, acted on with HTTP methods. So URLs should be nouns, not verbs, and usually plural. Use /users and /users/123, not /getUser or /createUser, because the method already says the action. Nest to show relationships, like /users/123/orders, keep names lowercase with hyphens, and be relentlessly consistent: if it is /products in one place, it is never /product or /items elsewhere. Consistency is the single biggest thing that makes an API feel good to use.

Use HTTP the way it was meant

HTTP already gives you a vocabulary; use it instead of inventing your own. Methods carry meaning: GET reads (and never changes anything), POST creates, PUT and PATCH update, DELETE removes. Status codes carry meaning too, and getting them right is half of good API design:

200 OK for a successful read or update, 201 Created when you make something new, 204 No Content for a successful delete.
400 Bad Request for malformed input, 422 for validation errors, 401 Unauthorized when login is needed, 403 Forbidden when the user is logged in but not allowed.
404 Not Found for a missing resource, 409 Conflict for a clash like a duplicate.
500 for your own errors, and never use 200 with an error message in the body, because clients cannot tell success from failure.

Versioning: never break v1

The day you ship an API, assume someone will depend on it forever. Put a version in the path from the start (/v1/users) so you can evolve without breaking existing clients. The rule that saves you: add, do not change. Adding a new field or a new endpoint is safe; renaming a field, removing one, or changing a response shape is a breaking change that belongs in a new version. When you do need breaking changes, ship /v2 and keep /v1 alive long enough for clients to migrate.

Authentication and security

Every real API needs to know who is calling and what they are allowed to do. Use tokens (a JWT or OAuth access token) sent in the Authorization header, over HTTPS only, always. Beyond auth: validate and sanitise every input (never trust the client), apply rate limiting so one caller cannot hammer you, return only the data the caller is allowed to see, and never leak internal details in errors. The billing and payment APIs we build treat this as non-negotiable, because an API is the front door to your data.

Pagination, filtering, and sorting

Any endpoint that returns a list must paginate. Returning ten thousand records in one response is slow, expensive, and will fall over as your data grows. Offer pagination (offset-based is simplest; cursor-based scales better for large or changing datasets), plus filtering and sorting via query parameters, like /orders?status=paid&sort=-created_at&page=2. Decide on one consistent style and use it on every list endpoint.

Error handling that helps

Errors are part of your API, not an afterthought. Return a consistent error shape every time, with a machine-readable code and a human-readable message, so clients can handle failures programmatically. Make messages specific enough to be useful ('email is already registered' beats 'invalid input') without leaking internals like stack traces or SQL. A predictable error format is one of the kindest things you can do for the developers consuming your API, including your own future self.

Idempotency and reliability

Networks fail and clients retry, so design for it. GET, PUT, and DELETE are naturally idempotent (calling them twice has the same effect as once). POST is not, which is dangerous for actions like creating an order or taking a payment, where a retry could charge someone twice. The fix is idempotency keys: the client sends a unique key with the request, and your server returns the same result for a repeat of that key instead of doing the work again. We go deep on this for payments in the Razorpay webhooks guide.

Document it, or it does not exist

An undocumented API is unusable, no matter how well designed. Describe it with the OpenAPI (Swagger) standard, which gives you interactive docs developers can read and try, and which many tools can generate clients and tests from. Keep the docs next to the code so they stay current. If a developer cannot understand your API without messaging you, the design is not finished.

The mistakes that haunt teams later

Verbs in URLs. /createOrder instead of POST /orders. It works, but it fights every convention and tool.
Wrong status codes. Returning 200 for errors, or 500 for a user's bad input. Clients cannot react correctly.
Breaking changes with no version. Renaming or removing a field with no /v2 silently breaks every existing client.
No pagination. Fine with 50 records, a disaster at 50,000.
Leaky errors. Returning stack traces or database errors to the client is both confusing and a security risk.
No rate limiting or input validation. The two holes that turn an API into an attack surface.
Inconsistent naming. /products here, /item there, camelCase in one response and snake_case in another. Death by a thousand small surprises.

How we build APIs

We build REST APIs on Node.js and Laravel with these conventions baked in: noun-based versioned routes, correct HTTP semantics, token auth over HTTPS with rate limiting and input validation, consistent pagination and error shapes, idempotency on anything that touches money, and OpenAPI docs that stay in sync with the code. The same disciplined API sits under our multi-tenant SaaS builds and the MultiVendor CRM, because a clean API is what lets a web app, a mobile app, and partners all build on one backend without chaos.

Common questions about REST API design

Should API endpoints use nouns or verbs?

Nouns, almost always plural. Use POST /orders to create an order and GET /orders/123 to read one, not /createOrder or /getOrder. The HTTP method already expresses the action, so the URL should name the resource. This keeps the API predictable and works naturally with HTTP tools and caches.

How should I version my API?

Put the version in the URL path from day one, like /v1/users, and follow the add-do-not-change rule: new fields and endpoints are safe, but renaming or removing anything is a breaking change that needs a new version. Ship /v2 only when you must, and keep /v1 running until existing clients have migrated.

What is API idempotency and why does it matter?

An idempotent request has the same effect whether it runs once or many times. It matters because networks fail and clients retry, and a retried POST could create a duplicate order or a double charge. The solution is an idempotency key: the client sends a unique key, and the server returns the same result for repeats instead of redoing the work. It is essential for anything involving payments.

Do I need OpenAPI or Swagger?

You need documentation, and OpenAPI (Swagger) is the standard way to provide it. It gives consumers interactive, accurate docs and lets tools generate client libraries and tests. Even a small internal API benefits, because clear docs save endless back-and-forth. An API nobody can understand without asking you is not finished.

REST or GraphQL?

For most APIs, REST is the simpler, more widely understood choice and is what we default to. GraphQL shines when clients need to fetch many related things in flexible shapes and you want to avoid over-fetching, common in complex apps with many screens. Pick REST for straightforward resource access; consider GraphQL when query flexibility genuinely earns its extra complexity.

Honest summary

Good REST API design is mostly discipline, not genius: name resources as nouns, use HTTP methods and status codes correctly, version from day one and never break v1, secure it with token auth and validation, paginate lists, return consistent errors, make money-touching actions idempotent, and document it with OpenAPI. Get these right and your API is a pleasure to build on and safe to grow. Skip them and you inherit breaking changes, security holes, and confused integrators.

Building or fixing an API and want it done to last? Send us a WhatsApp message with what you are building, or the cost calculator gives a rough estimate for an API or backend build.

Building an API that a web app, mobile app, or partners will depend on? We design and build REST APIs in Noida and Gurgaon on Node.js and Laravel: clean resource design, versioning, token auth, idempotency, pagination, and OpenAPI docs. Built to last, not to rewrite. → Scope an API build

How to Choose the Right Tech Stack for Your Startup in India 2026 (A No-Hype Guide)

Ravi Rai — Fri, 26 Jun 2026 05:53:33 +0000

Every project starts with the same question: what should we build it on? And the moment you search it, the internet hands you a hundred confident, contradictory answers. Use Next.js. No, use WordPress. Real startups use React Native. Actually, Flutter. Everyone is right and everyone is wrong, because they are all answering a question you did not ask: what is best in the abstract, instead of what is best for you.

The right tech stack does not come from a trend or from whatever your last developer happened to know. It comes from your constraints: what you are building, your budget, your timeline, and crucially, who maintains it after launch. This is the no-hype guide for Indian founders in 2026: the questions that actually decide your stack, the sensible default for each kind of project, and the mistakes that quietly cost you later.

The wrong way to choose a stack

Three traps catch most people. The first is choosing by hype: picking whatever is loudest on Twitter or in a YouTube title, regardless of whether it fits a small business. The second is choosing by whoever you hired: a freelancer who only knows WordPress will tell you everything is a WordPress job, and a React enthusiast will build a single-page app for a brochure site. The third is choosing by 'what big companies use': Netflix's architecture is the worst possible template for your five-page site or your first MVP. None of these start from your actual situation, which is the only place a good answer can come from.

The five questions that actually decide it

What are you actually building? A marketing site, an online store, a web app or SaaS, and a mobile app are four different problems with four different right answers. Be precise about which one you have.
What is the budget? A custom build and a template on a builder are an order of magnitude apart. The honest stack depends on what you can spend now and later.
What is the timeline? Need to be live in two weeks, or building a serious product over months? Speed-to-launch favours different tools than long-term flexibility.
Who maintains it after launch? The most ignored question, and the most important. A stack your team (or a local developer) can actually maintain beats a clever one nobody can touch.
How complex and how big will it get? A simple site and a multi-tenant SaaS with real scale need very different foundations. Build for where you are heading, not three startups beyond it.

Answer those five honestly and the choice narrows itself. Most bad stack decisions come from skipping straight to the tool before answering these.

The right default for each kind of project

A marketing or content website

If it is mostly pages and a blog and a non-technical person updates it, WordPress is still a sensible default for the easy editing. If speed, security, and scale matter more, a modern Next.js build wins on performance and maintenance. We compared them directly in WordPress vs Next.js for Indian small businesses.

An online store

For most first stores, Shopify gets you selling fast with the least maintenance. WooCommerce fits if you live in WordPress already or need deep customisation, and a custom or headless build makes sense at scale. The trade-offs are in Shopify vs WooCommerce and WordPress vs Shopify.

A web app or SaaS

This is custom territory: a Next.js or React front end with a Laravel or Node.js backend is our default, chosen by the team that will maintain it. Start with the smallest version that proves people will pay, as in how to build a SaaS MVP.

A mobile app

Cross-platform is almost always the right call for a startup: one codebase for iOS and Android. The choice is Flutter vs React Native, which we build with on the mobile side, and the right pick depends on your team and whether you also have a web app.

You just need a site, fast and cheap

Be honest if you are at the validate-the-business stage. A website builder can be the smart short-term move, covered in website builder vs custom and AI website builders vs hiring a developer. Move to a custom build you own once revenue justifies it.

The mistakes that cost you later

Over-engineering. Building for a million users you do not have yet. The cost is real now; the scale is hypothetical.
Choosing a stack nobody local can maintain. An exotic framework feels clever until your developer leaves and nobody in your city can pick it up.
Picking by trend. The hot tool of this year is the legacy burden of the next. Choose proven, well-supported tools.
Ignoring who maintains it. If you do not know who updates and fixes it after launch, you have not finished choosing.
Lock-in you did not notice. Some platforms make it painful to leave. Know how you would move before you commit.

Our default stacks, and why

After enough builds you stop chasing novelty and settle on tools that are fast, hireable, and boring in the best way. Ours: Next.js and React for sites and web apps (great performance, huge talent pool), Shopify for most stores, Laravel or Node.js for backends, and Flutter or React Native for mobile. We pick from these based on your five answers above, not the other way around, and we will happily talk you out of a heavier stack than you need.

Common questions about choosing a tech stack

What is the best tech stack for a startup?

There is no single best stack, only the best fit for your project, budget, timeline, and maintenance situation. For a web app or SaaS, a Next.js or React front end with a Laravel or Node.js backend is a strong, hireable default. For a store, Shopify; for a content site, WordPress or Next.js; for mobile, Flutter or React Native. Decide by your constraints, not by what is trending.

Should I use what is popular or what my developer knows?

Lean toward what can be maintained, which usually means a proven, widely-known stack rather than the newest one or a niche one only your current developer understands. Popularity matters mainly because it means more developers can maintain and extend the project later. Avoid both blind trend-chasing and being locked to one person's favourite tool.

Is WordPress still a good choice in 2026?

Yes, for the right job. WordPress remains excellent for content-led sites where non-technical people update pages, as long as it is maintained. For high-performance sites, web apps, or anything that needs to scale, a modern framework like Next.js is usually the better foundation. It depends on the project, not on WordPress being good or bad.

Can I change my tech stack later?

You can, but it costs time and money, so the goal is to choose well enough that you do not have to soon. Migrations are normal as a business grows (a builder to a custom site, a monolith to something more scalable), and a good team plans the move with redirects and data migration. Choosing a maintainable, non-locked-in stack makes any future move far cheaper.

Do I need a different stack for mobile and web?

Often you can share a lot. A web app and a cross-platform mobile app can share a backend and API, and React Native shares language and tooling with a React or Next.js web app, which is one reason teams pick it. Flutter is a separate toolchain but excellent for polished apps. If web and mobile both matter, factor that into the choice from the start.

Honest summary

Choosing a tech stack is not about finding the objectively best technology, it is about matching the tool to your project, budget, timeline, and the people who will maintain it. Name what you are building, answer the five questions honestly, pick the sensible default for that category, and avoid the traps of hype, over-engineering, and stacks nobody local can maintain. Boring, proven, hireable tools win far more often than exciting ones.

Not sure which way to go for your project? Send us a WhatsApp message with what you are building and your constraints, and we will give you an honest recommendation, or the cost calculator gives a rough estimate once you know the shape of it.

Stuck on what to build your product on? We help Indian founders choose a tech stack that fits the project and the budget, not the trend, then build it: Next.js, Shopify, Laravel, Node.js, Flutter, and React Native. Honest advice first, in Noida and Gurgaon. → Get an honest stack recommendation

Website Security for Indian Businesses 2026: The Basics That Actually Stop Most Attacks

Ravi Rai — Thu, 25 Jun 2026 06:45:28 +0000

Security feels abstract right up until the morning your website shows a pharmacy ad you did not put there, or Google flags it as deceptive, or it simply will not load. Then it is very concrete, and usually expensive, and almost always avoidable. The reassuring truth is that most websites are not hacked by a clever person who singled you out. They are hacked by automated bots that crawl millions of sites looking for the same small set of weaknesses, and you got caught because one of those weaknesses was open.

That is good news, because it means the defence is mostly about closing the common holes, not about hiring a security team. This is the plain-language guide for Indian business owners in 2026: what actually attacks your site, the handful of things that genuinely protect it, and the calm steps to take if you do get hacked.

What actually attacks your website

Forget the movie image of a hacker targeting your business. The reality is bots: programs that scan the entire internet, around the clock, probing every site they find for known weaknesses. They are looking for an outdated plugin with a public exploit, a login page with a weak password they can guess, an admin area left exposed, or a known hole in old software. When they find one, they get in automatically and use your site to send spam, host scam pages, mine crypto, or steal data. It is nothing personal, which is exactly why the fix is the same boring basics for everyone.

The basics that stop almost everything

HTTPS everywhere. A valid SSL certificate (free with most hosts and Cloudflare) encrypts traffic and is table stakes. A site on plain HTTP is flagged as 'not secure' and is an easy target.
Keep everything updated. The single biggest cause of hacked sites is outdated software: old plugins, themes, and CMS versions with known holes. Update promptly, and turn on auto-updates where you safely can.
Strong, unique passwords plus 2FA. Most break-ins are just guessed or reused passwords. Use a password manager, a unique strong password per account, and two-factor authentication on every admin login.
Least-privilege access. Give each person the lowest access they need, remove accounts when people leave, and do not share one admin login.
Remove what you do not use. Every unused plugin, theme, or old install is an unlocked door. Delete them, do not just deactivate them.
A firewall in front (WAF). Cloudflare or a web application firewall blocks the bad bots and common attacks before they ever reach your site, and the free tier covers most small businesses.
Backups. Covered below, because it is the one that saves you when everything else fails.

WordPress: the biggest target

If your site runs on WordPress, this section is for you, because WordPress powers a huge share of the web and is therefore the most attacked platform by far. The vast majority of WordPress hacks trace back to one thing: outdated plugins. Keep the core, themes, and plugins updated, use as few plugins as you can, only install ones that are actively maintained, hide or protect the login page, and put a security plugin or Cloudflare in front. WordPress is perfectly safe when it is maintained, and a sitting duck when it is not. If you would rather not babysit it, a WordPress maintenance plan or a move to a lower-maintenance stack solves it.

Backups: your real safety net

Everything above reduces the chance of being hacked. Backups decide whether a hack is a two-hour scare or a two-week disaster. You want automated backups taken regularly, stored somewhere separate from the site itself (not just on the same server), kept for several versions back, and, crucially, tested. A backup you have never restored is a guess, not a safety net. With a good recent backup, recovering from almost any attack is a restore and a patch. Without one, you may be rebuilding from nothing.

If you collect customer data, you have duties too

Security is not only about your site staying up, it is about protecting the personal information people give you. Under India's Digital Personal Data Protection Act, 2023, if you collect names, emails, phone numbers, or payment details, you are expected to keep them reasonably secure and to handle a breach responsibly. Practically: collect only what you need, secure it, have a privacy policy that is honest about what you do, and if data is ever exposed, act quickly and tell affected users. This is both the law and simply how you keep customers' trust.

What to do if you get hacked

Do not panic, and do not just delete things at random. A calm order of operations:

Contain it. Put the site into maintenance mode or take it offline so it stops harming visitors and your reputation.
Change every password and revoke sessions: hosting, CMS admin, database, email, and any connected accounts.
Restore from a clean backup taken before the hack, if you have one. This is the fastest reliable recovery.
Find and close the hole that let them in (usually an outdated plugin or a weak login), or you will be hacked again within days.
Scan for leftovers: attackers often hide backdoor files so they can return. Remove them, or rebuild clean.
Tell affected users if any personal data was exposed, and ask Google to review the site if it was flagged.

If that sounds like a lot under pressure, it is, which is why having a developer on call and recent backups in place beforehand turns a crisis into a routine fix.

How we secure the sites we build

Security is built in, not bolted on. We ship sites on HTTPS, keep dependencies current, put Cloudflare or a firewall in front, enforce least-privilege access and strong auth (including passkeys where it fits), and set up automated, tested, offsite backups. In the code itself we validate input, keep secrets out of the repository, and follow the boring secure-coding habits that stop the common attacks. Whether it is a fast custom build or cloud and DevOps hardening of what you already have, the goal is a site that is safe by default and quick to recover if anything ever slips through.

Common questions about website security

How do most websites actually get hacked?

Through automated bots finding a known weakness, not through targeted attacks. The most common causes are outdated plugins or software with public exploits, and weak or reused passwords. Keeping software updated and using strong passwords with two-factor authentication prevents the large majority of hacks.

Is WordPress safe?

Yes, when it is maintained. WordPress is the most attacked platform simply because it is the most popular, and almost all WordPress hacks come from outdated plugins and themes. Keep everything updated, run few well-maintained plugins, protect the login, and put a firewall in front, and it is perfectly safe. Neglect updates and it becomes an easy target.

Do I really need backups if my host says they back up?

Yes, and you should know exactly how to restore one. Host backups are often limited, overwritten, or hard to access in a crisis, and some keep them on the same infrastructure as your site. Have your own automated, offsite backups, keep several versions, and test a restore at least once so you know it works before you need it.

What does a firewall (WAF) actually do?

A web application firewall, like the one in Cloudflare, sits in front of your site and filters traffic, blocking known bad bots, common attack patterns, and floods of malicious requests before they reach your server. It is one of the highest-value, lowest-effort protections you can add, and the free tier is enough for most small businesses.

My site got hacked once and we cleaned it. Why did it happen again?

Almost always because the original hole was never closed, or a hidden backdoor file was left behind. Cleaning the visible damage without patching the entry point and removing backdoors means the bots simply walk back in. Fix the root cause and scan thoroughly, or rebuild from a known-clean backup.

Honest summary

You do not need to be a security expert to keep your website safe, because you are not being targeted by one, you are being scanned by bots looking for easy holes. Close the common ones: HTTPS, prompt updates, strong passwords with 2FA, least-privilege access, remove unused software, put a firewall in front, and keep tested offsite backups. Those few habits stop almost everything, and backups make the rare miss recoverable instead of ruinous.

If you are not sure how exposed your site is, or it has already been hacked, send us a WhatsApp message with your URL and we will tell you honestly what to fix, or the cost calculator gives a rough estimate for a security pass or a clean rebuild.

Worried your website is exposed, or already hacked? We secure and rebuild sites in Noida and Gurgaon: HTTPS, updates, firewall, strong auth, secure code, and tested offsite backups, so you are safe by default and quick to recover. Free WhatsApp check. → Get a website security check

Deploying a Web App to Production in 2026: Docker, CI/CD, and Zero-Downtime (Without the Overkill)

Ravi Rai — Wed, 24 Jun 2026 06:40:12 +0000

There is a moment every growing app hits: the deploy that goes wrong. Someone SSHes into the server, runs git pull, restarts the process, and the site is down for two minutes, or worse, half-broken because a dependency changed or a migration did not run. It works until the evening it does not, usually right before something important.

Deployment is the unglamorous engineering that decides whether shipping is calm or terrifying. Done well, releasing a change is a non-event: push code, it goes live, nobody notices any downtime. This is the practical guide to getting there in 2026: what Docker and CI/CD actually buy you, how zero-downtime deploys work, the simple pipeline we use, and the honest question of whether you need heavy infrastructure at all (most teams do not).

Why manual deploys hurt you

The SSH-and-git-pull approach feels fine at first, then quietly becomes a liability:

Downtime. Restarting the app to deploy means a window where the site is unavailable, however short.
'Works on my machine'. The server's runtime, library versions, and environment drift from your laptop, so things that worked locally break in production.
No clean rollback. When a deploy breaks something, getting back to the last good state is a scramble, not a button.
Human error. Manual steps get skipped: a migration forgotten, an env var missed, the wrong branch pulled.
It does not scale to a team. When more than one person deploys, undocumented manual steps cause chaos.

Docker: ship the environment, not just the code

Docker packages your app together with everything it needs to run (the runtime, the libraries, the system dependencies) into a container image. That image runs identically on your laptop, in CI, and in production, which kills the 'works on my machine' problem at the root. You build the image once, and that exact image is what runs everywhere.

For most web apps that means a small Dockerfile describing how to build and run the app, and that is the unit you deploy: not loose files on a server, but a versioned image you can run, roll back to, or scale by starting more copies.

CI/CD: deploys become a git push

CI/CD is the pipeline that runs automatically when you push code. CI (continuous integration) checks every change: install, lint, run tests, build the image. CD (continuous delivery or deployment) takes a passing build and ships it. The practical effect is that releasing becomes git push to main, and a tested, consistent build goes live without anyone touching a server.

In India, the common setup is GitHub Actions or GitLab CI (both have generous free tiers) running the pipeline, pushing the Docker image to a registry, and deploying it. The win is consistency and speed: the same steps run every time, tests catch problems before they reach users, and a deploy takes minutes with no manual checklist.

Zero-downtime deploys

The trick to deploying without users noticing is to never turn the old version off before the new one is ready. A rolling deploy starts the new version alongside the old, waits for a health check to confirm it is actually serving traffic, then shifts traffic over and retires the old one. Blue-green does the same with two full environments and a switch. Either way, there is no window where the site is down, and if the new version fails its health check, traffic never moves to it, so a bad deploy does not take you offline.

A simple, solid pipeline (what we actually use)

You do not need anything exotic. A reliable pipeline for most apps looks like this:

Push to main (or merge a pull request).
CI runs: install dependencies, lint, run the test suite, build the Docker image.
Push the image to a container registry, tagged with the commit.
Run database migrations as a controlled step, not by hand.
Deploy with a rolling update behind a health check, so traffic only shifts once the new version is healthy.
Keep the previous image so rollback is one command if something slips through.

Secrets and environment variables live in the CI/CD platform or a secrets manager, never in the code. That single pipeline turns deployment from a nervous manual ritual into something you trust enough to do several times a day.

Do you even need Docker and Kubernetes?

Honest answer: you need reliable deploys, you do not necessarily need to run the infrastructure yourself. Kubernetes is powerful and almost always overkill for a single app or an early-stage product, it adds real operational overhead that a small team will feel. For a lot of businesses the smartest move is a managed platform (Vercel for Next.js, Render, Railway, or a managed cloud service) that gives you CI/CD, zero-downtime deploys, and rollbacks out of the box, with no servers to babysit.

Reach for your own Docker-plus-orchestration setup when you genuinely need it: complex multi-service systems, specific compliance or data-residency needs, or scale where the managed-platform bill stops making sense. Until then, the simplest thing that gives you safe deploys is the right thing. We will tell you honestly which side of that line you are on.

The India angle

Two practical notes for Indian teams. First, keep infrastructure in or near India (an India cloud region, or a host with India presence) so your users get low latency, the same point we make in the web hosting guide. Second, resist over-engineering: a founder with one app and a small team does not need a Kubernetes cluster, they need a clean CI/CD pipeline and a managed host. Spend the saved time and money on the product, not on ops you do not need yet.

Common deployment mistakes

No rollback plan. If your only way back is to fix forward under pressure, you do not have a deploy process, you have a gamble.
Secrets in the code or repo. Keys and passwords belong in environment variables or a secrets manager, never committed.
No health checks. Without them a deploy can shift traffic to a broken version. The health check is what makes zero-downtime real.
Migrations run by hand. Make schema changes a controlled, automated step, or they get forgotten and break production.
No staging environment. Test the deploy somewhere safe before it hits real users.
Friday-evening deploys. Ship when someone is around to watch, not right before the weekend.

How we set it up

When we build or take over an app, calm deploys are part of the work, not an afterthought. We containerise with Docker where it helps, wire up CI/CD on GitHub Actions (tests and build on every push), deploy with health checks so releases are zero-downtime, automate migrations, keep secrets out of the code, and keep a one-command rollback. We do this on Node.js and Laravel apps as part of our cloud and DevOps work, and for many clients it runs on CloudNX or a managed platform rather than a self-run cluster, because simpler is more reliable.

Common questions about deployment

Do I need Docker for a small web app?

Not always. Docker shines when you want identical environments and easy rollbacks, and it is the standard for self-hosted apps. But if you deploy to a managed platform like Vercel, Render, or Railway, much of that is handled for you and you may not write a Dockerfile at all. Use Docker when you are managing your own servers or running multiple services; skip it when a managed platform already gives you reliable deploys.

What is the difference between CI and CD?

CI (continuous integration) is the automatic checking of every code change: install, lint, test, build. CD (continuous delivery or deployment) takes a passing build and ships it, either automatically or with a one-click approval. Together they turn a push into a tested, consistent release with no manual server steps.

How do zero-downtime deploys actually work?

The new version starts up alongside the old one. A health check confirms the new version is genuinely serving requests. Only then does traffic shift over, and the old version is retired. Because the old version keeps serving until the new one is ready, users never hit a down site, and a new version that fails its health check simply never receives traffic.

Do I need Kubernetes?

Almost certainly not at first. Kubernetes is built for complex, multi-service systems at scale and carries real operational overhead. A single app or an early product is better served by a managed platform or a simple container deploy. Adopt Kubernetes only when your scale and complexity genuinely demand it, and you have the team to run it.

How often should we deploy?

As often as you safely can. The point of a good pipeline is that small, frequent deploys are low-risk, because each change is tiny and easy to roll back. Teams with solid CI/CD deploy several times a day without drama. Batching a month of changes into one big scary release is the riskier path.

Honest summary

Reliable deployment is mostly about removing humans from the risky parts. Docker makes the environment identical everywhere, CI/CD turns a push into a tested release, and health-checked rolling deploys mean users never see downtime. You do not need Kubernetes to get this, a clean pipeline plus a managed host gets most businesses there with far less overhead. Add a rollback, keep secrets out of the code, automate migrations, and deploys stop being scary.

If your deploys are manual and nerve-wracking, or you are setting up a new app and want it done right, the cost calculator gives a rough estimate, or send us a WhatsApp message with your stack and we will suggest the simplest reliable setup.

Deploying by hand and holding your breath? We set up calm, zero-downtime deploys in Noida and Gurgaon: Docker where it helps, CI/CD on GitHub Actions, health-checked rolling releases, automated migrations, and one-command rollback, on Node.js and Laravel, without the Kubernetes overkill. → Set up reliable deploys

How to Build a SaaS MVP in India 2026: Cost, Stack, and Timeline

Ravi Rai — Tue, 23 Jun 2026 05:13:27 +0000

Most SaaS first versions do not fail because the idea was wrong. They fail because the founder spent six months and a pile of money building every feature they could imagine, launched to silence, and ran out of road before learning whether anyone would actually pay. The whole point of an MVP is to find that out cheaply and fast, before you bet the farm.

An MVP, a minimum viable product, is the smallest version of your product that delivers the core value and lets real users (and their wallets) tell you if you are onto something. This is the founder-honest guide to building one in India in 2026: what to include and what to ruthlessly cut, the stack we reach for, what it really costs in rupees, how long it takes, and the mistakes that kill MVPs before they get a chance.

What an MVP actually is (and is not)

An MVP is not a cheap, half-broken version of the full product. It is a complete, polished version of the ONE thing that matters, with everything else left out. If your idea is invoicing software, the MVP creates and sends an invoice cleanly. It does not also do inventory, payroll, a mobile app, and ten integrations. Those are v2, earned with revenue and real feedback.

Two ways founders get this wrong: building too much (so it ships late and over budget), or building too little and too rough (so users cannot tell if the real thing would be good). The MVP is narrow but finished: do one job, do it well, and make it easy to start.

Decide the one thing it must do

Before any code, name the core loop: the single sequence a user repeats to get value. For a CRM it is add a lead, move it through stages, close it. For a booking tool it is list availability, take a booking, get paid. Everything that is not part of that loop is a candidate to cut from v1. The discipline of cutting is what keeps an MVP an MVP. If a feature does not help prove the core value, it waits.

What every SaaS MVP needs under the hood

Even a narrow MVP needs a real foundation, because these are the parts you cannot bolt on cleanly later:

Authentication and accounts. Sign-up, login, password reset, and ideally passkeys. This is table stakes.
The core feature, done well. The one job from your core loop, polished.
Multi-tenant basics. Each customer's data isolated from the next. Get this right early; see our multi-tenant SaaS guide.
Payments. If people pay, wire it in from day one with Razorpay done reliably. Charging is the truest signal of product-market fit.
A simple dashboard. Where the user does the core loop and sees their data.
Transactional email and notifications. Welcome, reset, and the key in-product alerts.

Notice what is missing: admin panels with fifty settings, analytics dashboards, role hierarchies, and integrations. Add those when a paying customer asks.

The stack we use, and why

For an MVP you want a stack that is fast to build in, cheap to run, and able to scale if the product works, so you are not forced into a rewrite the moment you get traction. What we reach for:

Frontend: Next.js and React, for a fast, modern UI and good SEO on the marketing pages.
Backend: Node.js or Laravel, both let us move quickly and scale later.
Database: PostgreSQL, reliable and scales a long way before you need anything exotic.
Payments: Razorpay for India, with Stripe added when you sell abroad.
Hosting: a managed cloud platform with a CDN, so it is fast and you are not babysitting servers.

This is a boring, proven stack on purpose. The interesting part of an MVP should be your product, not the infrastructure.

Real INR cost and timeline

Honest ranges. Final cost depends on how complex the core feature is and how much you insist on building before launch.

Lean MVP: ₹1.5L to ₹4L, 4 to 8 weeks

Auth, one core feature done well, basic multi-tenant, payments, a simple dashboard, and a marketing page. Enough to put in front of real users and start charging. Right for a focused single-loop product.

Standard MVP: ₹4L to ₹9L, 8 to 16 weeks

Everything above plus a richer core feature set, a couple of integrations, an admin view, email automation, and more polish. Right when the product needs more than one screen to prove its value.

Funded / complex MVP: ₹9L+, 16 weeks and up

Heavier products: complex workflows, real-time features, multiple user roles, deeper integrations, or strict compliance. Still scoped as an MVP, just a bigger core. Plan a maintenance and iteration retainer on top, because an MVP that works is the start, not the finish.

Build custom, or use no-code?

Be honest about your stage. No-code tools (Bubble, Glide, and similar) are genuinely good for validating an idea fast and cheap when your logic is simple and you have no budget yet. Use them to get the first few users and proof. The limits show up when you need real performance, custom logic, deep integrations, or you simply cannot afford the per-user pricing as you grow. Custom code is the right call when the product is the business and you need to own it. Many founders start no-code to validate, then rebuild custom once it is real, and that is a perfectly sensible path.

The mistakes that sink MVPs

Building too much before launch. The number-one killer. Every extra feature delays the only thing that matters: real user feedback.
No payments. A free pilot tells you people like free things. Charging tells you if you have a business.
Over-engineering for scale you do not have. You do not need Kubernetes and microservices for your first 100 users. Ship simple, scale when forced.
Ignoring onboarding. If a new user cannot reach the core value in their first session, your conversion dies regardless of how good the product is.
Building before talking to users. The cheapest feature to cut is the one you never build because a customer told you they did not want it.

How we build SaaS MVPs

We build MVPs the way we wish more founders did: scope hard to one core loop, build it properly on a stack that scales, wire in auth, multi-tenant data, and payments from the start, and ship in weeks, not quarters. We would rather launch something narrow and real that you can charge for than a broad, unfinished product that never gets tested. Then we iterate with you based on what actual users do, on a retainer if you want ongoing development. It is the same engineering we put into our own products like our MultiVendor CRM.

Common questions about building a SaaS MVP

How much does it cost to build a SaaS MVP in India?

A lean but real MVP (auth, one core feature, multi-tenant, payments, a simple dashboard) typically runs ₹1.5L to ₹4L and ships in 4 to 8 weeks. A standard MVP with more features and integrations runs ₹4L to ₹9L. Complex or funded products start around ₹9L. The biggest variable is how much you insist on building before launch, so scope tightly.

How long does it take to build an MVP?

A focused MVP can ship in 4 to 8 weeks. The timeline blows out when scope creeps, so the fastest way to launch sooner is to cut features to v2, not to add developers. We work in weekly sprints with a demo each week so you see it taking shape and can steer.

Should I build my MVP with no-code or custom code?

No-code is great for validating a simple idea fast and cheap before you have budget or proof. Move to custom when you need real performance, custom logic, deep integrations, or you are hitting no-code's per-user pricing and limits. Starting no-code and rebuilding custom once the idea is proven is a common, sensible path.

What should I leave out of the first version?

Anything that is not part of your core loop: extra modules, admin settings nobody asked for, analytics dashboards, mobile apps, and integrations beyond the one or two that are essential. If a feature does not help prove that people will pay for the core value, it waits for v2.

Do I really need payments in the MVP?

If your plan is to charge, yes. The single clearest signal of product-market fit is someone paying you. A free pilot only proves people like free. Wiring in Razorpay from the start means your MVP can validate willingness to pay, not just interest.

Honest summary

A SaaS MVP is not a smaller, worse product. It is the one thing that matters, built well, with everything else cut to v2. Name your core loop, build auth, multi-tenant data, and payments on a boring proven stack, ship in weeks, and let paying users tell you what to build next. The founders who win are the ones who launch narrow and learn fast, not the ones who polish in private for a year.

If you have a SaaS idea and want it built right, the cost calculator gives a rough starting estimate, or send us a WhatsApp message with what you want to build and we will reply within 24 hours with a scoped plan and an INR range.

Have a SaaS idea? We build MVPs in Noida and Gurgaon, scoped to one core loop and shipped in weeks: auth, multi-tenant data, Razorpay payments, and a clean dashboard on Next.js and Node.js or Laravel. Launch narrow, charge early, iterate with real users. → Scope your SaaS MVP

Website Speed & Core Web Vitals in India 2026: Why Your Site Is Slow and How to Fix It

Ravi Rai — Mon, 22 Jun 2026 08:59:00 +0000

Speed is the most underrated thing about a website. It is invisible when it is good and brutal when it is bad: a visitor lands, the page hangs for a few seconds, and they are gone before they ever saw what you offer. They will not email you to say the site was slow. They just leave, and you never know it happened.

In India this matters more than almost anywhere. Most of your visitors arrive on a mid-range Android phone, over a mobile network that is sometimes 4G and sometimes a bar and a half in a lift. A site that feels fine on your office WiFi and your laptop can be painfully slow for the customer you actually want. This is the practical guide to website speed and Core Web Vitals in 2026: what the metrics mean, why sites are slow, and what actually fixes them.

Why speed is money, and rankings

Two reasons to care. First, conversions: study after study shows that as a page gets slower, more people abandon it, and the drop is steepest in the first few seconds. A faster site does not just feel nicer, it produces more enquiries and sales from the same traffic. Second, SEO: Google uses page experience, including Core Web Vitals, as a ranking signal. It is not the biggest factor (relevance and links matter more), but when two pages are otherwise close, the faster one wins, and a slow site can be held back across the board.

The three Core Web Vitals, in plain English

Google boils site speed down to three numbers, measured on real visitors:

LCP (Largest Contentful Paint): how long until the biggest thing on screen (usually the hero image or headline) has loaded. Good is under 2.5 seconds. This is your 'does it feel fast to load' number.
INP (Interaction to Next Paint): how quickly the page responds when someone taps or clicks. Good is under 200 milliseconds. This replaced the old FID metric in 2024 and measures 'does it feel responsive'.
CLS (Cumulative Layout Shift): how much the page jumps around as it loads (the classic 'you go to tap a button and an ad pushes it down'). Good is under 0.1. This is your 'does it feel stable' number.

You want all three in the green, measured on mobile, because mobile is where your visitors and Google both look first.

Why your site is slow: the usual culprits

Huge, unoptimised images. The single most common cause. A 4MB photo straight off a phone or a stock site, shown at thumbnail size, has to download in full first. Images should be compressed, correctly sized, and served as WebP or AVIF.
Too much JavaScript. Heavy themes, page builders, and a pile of plugins ship megabytes of script the browser has to download and run before the page is usable. This is the biggest INP killer.
No caching or CDN. If every visitor fetches everything fresh from a single server far away, the site is slow for anyone not next to that server. A CDN serves files from close to the user.
Cheap, overloaded hosting. A ₹150-a-month shared plan with a thousand other sites on the same box will be slow under any real traffic.
Render-blocking resources. Fonts and stylesheets that the browser must load before it can show anything delay the whole page.
Layout shift from ads, fonts, and images without dimensions. When elements load late without reserved space, everything jumps, which wrecks CLS.
Too many third-party scripts. Chat widgets, analytics, pixels, and embeds each add weight and can each slow things down.

How to actually fix it

Fix images first. It is the highest-return change. Compress, resize to the dimensions actually shown, serve WebP or AVIF, and lazy-load anything below the fold. Always set width and height so nothing shifts.
Cut and defer JavaScript. Remove plugins you do not need, defer non-critical scripts, and avoid heavy page builders. Less script means faster loads and a better INP.
Put a CDN in front of the site. Cloudflare, or the CDN built into modern hosts like Vercel, serves your content from close to the user. This alone can transform load times across India.
Host on something fast. A decent VPS, managed cloud, or a platform like Vercel beats the cheapest shared hosting by a wide margin. See our web hosting guide.
Reserve space to stop layout shift. Give images and ads fixed dimensions, and load fonts with font-display: swap plus a sensible fallback so text does not jump.
Trim third-party scripts. Keep the ones that earn their weight, load them late, and drop the rest.
Render smart. Static or server-rendered pages (what frameworks like Next.js do well) send ready-to-show HTML instead of making the browser build the page from scratch, which is a big LCP win.

The India angle: test like your customer, not like you

The trap is judging your site on a fast laptop and good WiFi. Your customer is on a phone on mobile data. Test that way: open the site on a real mid-range phone on 4G, or use the throttling option in your browser's dev tools to simulate a slower network and a slower CPU. A site that loads in one second for you might take six for them, and six seconds is where most people give up. Hosting and CDN choices that keep content inside India also shave real milliseconds for Indian visitors.

How to measure it

Two kinds of data, both useful:

Lab tests (PageSpeed Insights, Lighthouse in Chrome): run a page on demand and get a score plus specific fixes. Great for diagnosing, but it is a simulated single run.
Field data (the Core Web Vitals report in Google Search Console, and the CrUX data inside PageSpeed Insights): this is from real visitors over time, and it is what Google actually uses for ranking. Trust the field data for the verdict, the lab data for the to-do list.

Start at PageSpeed Insights, run your homepage and a key landing page on mobile, and work down the list of opportunities it gives you.

How we build fast sites

Speed is not a thing we bolt on at the end, it is how we build from the start. We default to static or server-rendered Next.js, optimise and lazy-load images, ship as little JavaScript as possible, reserve space so nothing shifts, and serve everything through a CDN. The result is sites that sit in the green on Core Web Vitals on a real phone, which helps both SEO and the conversion rate at the same time. When we rebuild a slow site, the speed jump is usually the first thing the client notices.

Common questions about website speed

What is a good website loading time?

Aim for the largest content to appear within about 2.5 seconds on a mobile connection (the LCP target), the page to respond to taps within 200 milliseconds (INP), and almost no layout shifting (CLS under 0.1). If your hero loads in under 2.5 seconds on a mid-range phone on 4G, you are in good shape.

Does website speed really affect Google ranking?

Yes, through Core Web Vitals, but it is one signal among many. Relevance and backlinks matter more. Speed rarely vaults a weak page to the top on its own, but a slow site is a quiet drag on everything, and between two similar pages the faster one tends to win. It also strongly affects conversions, which matters regardless of ranking.

What is the single biggest cause of a slow website?

Unoptimised images, by a distance. Large photos that are not compressed or correctly sized are the most common reason pages are slow, and fixing them is usually the fastest, highest-return improvement you can make.

My PageSpeed score is low but the site feels fine to me. Does it matter?

Probably yes, because it does not feel fine to your visitors. You are testing on a fast device and network; they are not. Check the field data in Search Console (real users) rather than your own impression, and test on a throttled mobile connection to see what they actually experience.

Will switching hosting fix my speed?

It helps, but it is rarely the whole answer. Fast hosting plus a CDN removes the server bottleneck, but if the page itself ships huge images and heavy JavaScript, it will still be slow. Fix the page and the hosting together for the real win.

Honest summary

Website speed is quiet money. A slow site loses visitors before they convert and gives Google a reason to rank you lower, and in India the gap between your fast laptop and your customer's phone makes it worse than you think. The fixes are well understood: optimise images, cut and defer JavaScript, use a CDN and decent hosting, reserve space to stop layout shift, and render static or server-side. Measure with PageSpeed Insights and the Search Console Core Web Vitals report, and fix the biggest items first.

If your site is slow and you want it fast, the cost calculator gives a rough estimate for a rebuild or a speed pass, or send us a WhatsApp message with your URL and we will tell you honestly what is dragging it down.

Is your website slow on mobile? We build and rebuild sites that sit in the green on Core Web Vitals in Noida and Gurgaon: optimised images, minimal JavaScript, CDN delivery, and static or server-rendered Next.js. Faster site, better SEO, more enquiries. → Get a website speed audit

Website Builder vs Custom Website in India 2026: An Honest Decision Guide

Ravi Rai — Sun, 21 Jun 2026 13:13:21 +0000

Every founder building their first proper website hits this fork: use a drag-and-drop builder like Wix, Squarespace, GoDaddy, or Shopify, or pay someone to build a custom site. The internet is full of absolute answers ('builders are toys', 'custom is a waste of money') and both are wrong. The honest answer depends entirely on where your business is right now.

This is a no-spin decision guide for Indian businesses in 2026: what each option really is, when a builder is genuinely the smart choice, when you have outgrown it, the real cost over three years, and the migration path between them. We build custom sites for a living, so the easy move would be to tell you to always go custom. We will not, because it is not true.

If you specifically want the AI-builder angle (Wix AI, Framer, Lovable), we covered that in AI website builders vs hiring a developer. This piece is the broader builder-versus-custom call.

What each option actually is

A website builder (Wix, Squarespace, GoDaddy Website Builder, Shopify for stores, Webflow for designers) gives you templates and a visual editor. You pay a monthly fee, you do not touch code, and hosting is included. A custom website is built for you in code (often WordPress for content sites, or Next.js and React for apps and high-performance sites), hosted wherever you choose, and shaped entirely around your needs. One is rented and standardised; the other is owned and bespoke.

When a website builder is genuinely the right call

Builders are not toys. For the right situation they are the smart, cheap, fast choice. Pick a builder when:

You are validating an idea. You need something live this week to test demand, not a six-week build.
It is a simple brochure site. A few pages covering who you are, what you do, and how to contact you. No complex features.
Your budget is genuinely tiny. A few hundred rupees a month beats having no site at all.
You will maintain it yourself. You are happy editing it and do not want to depend on a developer for every small change.
Time to launch beats everything else. A festival, an event, or a hard deadline is coming.

If that is you, use a builder, do it well, and revisit custom when the business has grown. Spending ₹1L on a custom site to validate an unproven idea is the wrong call.

When you have outgrown a builder

Builders hit a ceiling, and you feel it as friction. Go custom when:

You need features the builder does not allow. Custom booking logic, a customer portal, a specific workflow. Builders stop at their menu of options.
Performance and SEO are holding you back. Builder sites carry bloat, and on a competitive search term a fast custom site has the edge.
You pay for add-ons every month. The builder fee plus a stack of paid plugins or apps quietly grows past what a custom build would have cost.
You need real integrations. Your CRM, ERP, payment flows, WhatsApp, or GST invoicing, which builders handle clumsily or not at all.
You want to own your site and data. Not rent it from a platform that can change pricing or rules whenever it likes.
The site is core to revenue. When the website is the business (a store, a SaaS, a marketplace), you cannot afford the builder's limits.

The real cost over three years

Founders compare the upfront price and stop there. Compare the three-year total instead. Rough 2026 ranges:

Builder: ₹500 to ₹2,500 a month for the plan, plus paid apps or plugins, plus transaction fees on some platforms. Call it ₹15,000 to ₹60,000+ a year, every year, forever. Over three years that is roughly ₹45,000 to ₹2L, and you still do not own it.
Custom: a larger upfront build (a simple custom site from ₹25,000 to ₹60,000, more for bigger ones) plus modest hosting (₹3,000 to ₹15,000 a year) and optional maintenance. The upfront is higher, the ongoing is far lower, and it is yours.

The crossover is real: plenty of businesses that stayed on a builder for three years have paid more than a custom site would have cost, and have nothing to keep at the end. See our website cost guide for the detailed numbers.

Ownership and lock-in

This is the part nobody mentions at signup. On a builder you rent. Your site lives inside their platform in their proprietary format. If they raise prices, change terms, or you simply want to leave, you usually cannot take the actual site with you, you rebuild it. A custom site is an asset you own: the code, the content, and the data, hosted anywhere. For a business that plans to be around in five years, ownership matters more than the first year's convenience.

SEO and performance

Modern builders rank fine for low-competition terms, so ignore anyone who claims builders 'cannot do SEO'. But on competitive terms the details decide it, and custom gives you full control: clean code, fast Core Web Vitals on a Next.js build, proper schema, and no platform bloat. If organic search is a real channel for you, custom has headroom a builder does not, and it pairs with real SEO work in a way a locked-down builder cannot.

The honest decision in one line

Use a builder if your site is simple, your budget is tight, and you are validating or just need a presence. Go custom when the site is core to revenue, you need features or integrations a builder cannot give, or the monthly fees and lock-in have started to cost you more than ownership would. Most businesses should start on a builder and graduate to custom once the business is real, which is exactly the migration path below.

The migration path

These are not enemies, they are stages. The sensible path for many Indian businesses: launch on a builder to validate cheaply, grow, and when the limits start hurting (features, fees, SEO, ownership) move to a custom build you own. When you migrate, the goal is to keep your URLs, redirect old pages so you do not lose any ranking you earned, and carry your content over cleanly. A good developer plans the migration so you upgrade without going backwards.

How we help

We build custom websites and stores (on Next.js and React, WordPress for content sites, or Shopify when a store fits), and we migrate businesses off builders once they have outgrown them. But we will tell you honestly when a builder is still right for where you are, because selling you a custom build you do not need yet is a bad way to start a relationship. Flat INR quotes, a written scope, and a site you own at the end.

Common questions

Is a website builder bad for SEO?

No, that is a myth. Modern builders can rank for low to medium competition terms if the basics are done well. The difference shows on competitive terms, where a fast, clean custom site with full control over performance, schema, and structure has an edge a locked-down builder cannot match. If SEO is a serious channel for you, custom has more headroom.

Is a builder cheaper than a custom site?

Cheaper to start, often more expensive over time. A builder is a monthly fee plus paid apps, forever, and you never own it. A custom site costs more upfront but far less per year, and it is an asset you keep. Over three years many builder users have paid more than a custom build would have cost. Compare the three-year total, not the signup price.

Should a small business in India just use Wix or Shopify?

If you are validating, on a tight budget, and need a simple site fast, yes, a builder is a smart start. If your site is core to revenue, needs custom features or integrations (CRM, GST, WhatsApp), or you want to own it and rank competitively, a custom build is the better investment. Many businesses start on a builder and move to custom once the business is real.

Can I move from a website builder to a custom site later?

Yes, and it is common. The key is doing the migration properly: keep your URL structure or set up 301 redirects so you do not lose search rankings, carry your content over cleanly, and launch without downtime. A developer who has done migrations will plan this so you upgrade without losing the ground you gained.

Do I actually own my website on a builder?

Not really. You rent space on the platform, and your site is in their proprietary format. If you leave or they change terms, you typically cannot export the real site, you rebuild it elsewhere. A custom site is fully yours: the code, content, and data, hosted wherever you choose. For a business planning for the long term, that ownership is a genuine advantage.

Honest summary

Website builder versus custom is not good versus bad, it is the right tool for the right stage. Builders win on speed, low upfront cost, and simplicity, which is perfect for validating or for a simple presence. Custom wins on ownership, performance, features, integrations, and long-term cost, which becomes essential once the site is core to your business. Start where you are, and upgrade when the limits start costing you more than the move would.

Not sure which stage you are at? The cost calculator gives a quick estimate, or send us a WhatsApp message with what you are building and where you are now, and we will give you an honest answer, even if that answer is to stay on the builder for now.

On a builder and feeling the limits, or starting fresh and unsure which way to go? We build custom websites and stores in Noida, and we migrate businesses off builders cleanly while keeping your rankings. Flat INR quotes, and honest advice on whether you even need custom yet. → Get an honest recommendation

Razorpay Webhooks Done Right (2026): Signature Verification, Idempotency, and Reconciliation

Ravi Rai — Sat, 20 Jun 2026 08:21:25 +0000

Almost every payment bug we get called in to fix has the same shape: the checkout works fine in testing, money moves, and then weeks later the founder notices orders that were paid but never fulfilled, or customers charged twice, or a refund that never reversed. The checkout was never the problem. The problem is what happens after the payment, in the webhook.

Razorpay (like every serious gateway) tells your server about payments through webhooks: server-to-server HTTP calls that fire when a payment is captured, fails, or is refunded. Get the webhook handling right and payments are boringly reliable. Get it wrong and money quietly goes missing. This is the developer-honest guide to doing it right: verifying the signature correctly, making the handler idempotent, and reconciling so nothing slips through. The basics of the Razorpay integration are covered elsewhere; this is the reliability layer on top.

Why the client-side callback is not enough

When a payment finishes, Razorpay Checkout calls a handler in the browser, and it is tempting to mark the order paid right there. Do not rely on that alone. The browser is the least reliable place in the whole flow: the customer closes the tab, the network drops, the phone dies, or the redirect just gets lost. The money still moved, but your client-side handler never ran, so your database thinks the order is unpaid.

The webhook is the source of truth. It comes from Razorpay's servers to yours, independent of the customer's browser, so it arrives even when the user vanishes after paying. Treat the client callback as a nice-to-have for UX, and the webhook (plus a server-side verify) as the real record of what happened.

How Razorpay webhooks work

You register a webhook URL in the Razorpay dashboard and pick the events you care about. When one happens, Razorpay sends an HTTP POST to that URL with a JSON body describing the event, and signs it so you can prove it really came from Razorpay. Your job is to verify that signature, act on the event exactly once, and respond quickly. Everything below is about those three things.

1. Verify the signature, on the raw body

Every webhook carries an X-Razorpay-Signature header. You verify it by computing an HMAC SHA256 of the request body using the webhook secret you set when creating the webhook, then comparing it to the header value with a constant-time comparison. If they do not match, reject the request, because anyone can POST to a public URL.

Here is the gotcha that breaks the most integrations: you must hash the exact raw request body, the bytes Razorpay sent. If your framework parses the JSON and you re-stringify it to hash, the whitespace and key order change, the hash changes, and verification fails for every webhook. In Express, capture the raw body (for example with a raw body parser on that route). In Laravel, use the raw request content, not the parsed array. This one detail is responsible for more 'webhooks are failing' tickets than anything else.

Note that this webhook secret is different from the signature you verify on the client-side payment callback, which is an HMAC of order_id + payment_id using your API key secret. Two different checks for two different moments. Keep them straight.

2. Make the handler idempotent

Webhooks are delivered at least once, not exactly once. Razorpay retries if your endpoint is slow, times out, or returns a non-2xx, and you will sometimes receive the same event two or three times. If your handler is not idempotent, those retries double-fulfill the order, send two confirmation emails, or credit a wallet twice.

The fix is to dedupe. Record the event id (Razorpay sends one) or the payment id plus event type in a processed-events table, inside the same database transaction as the work you do. Before acting, check whether you have already processed it; if so, return 200 and do nothing. Idempotency is not optional for money code, it is the difference between reliable and quietly broken.

3. Acknowledge fast, process asynchronously

Razorpay expects a quick 2xx. If you do heavy work inline (generate an invoice, call other APIs, send WhatsApp and email) the request can time out, Razorpay marks it failed, and retries, which is how you get duplicates. The reliable pattern is: verify the signature, persist the raw event, return 200 immediately, and do the real work in a background job off a queue. Your endpoint should be fast and dumb; the worker does the thinking.

4. Confirm the payment server-side

When a webhook says a payment succeeded, the well-built flow still confirms it against Razorpay before releasing anything valuable. Fetch the payment or order from the Payments API and check the status and amount match what you expect for that order. This protects you from spoofed or stale events and from edge cases like a payment that was authorized but not captured. Verify, then fulfill.

5. Reconcile so nothing slips through

Even with all of the above, a webhook can occasionally be missed (your server was down, a deploy dropped a request). So do not depend on webhooks as your only signal. Run a reconciliation job that periodically lists recent payments from the Razorpay API and compares them to your database, flagging any payment Razorpay knows about that your system marked unpaid, and vice versa. At month end, the gateway settlement report, your orders, and your payouts should all agree. Reconciliation is the safety net that catches the rare miss before a customer does.

The events that actually matter

You do not need to handle every event. The ones that carry real meaning for most businesses:

payment.captured (or order.paid): money is actually in. This is your fulfil-the-order trigger.
payment.failed: the attempt failed. Useful for analytics and for nudging the customer to retry.
payment.authorized: authorized but not yet captured. Only relevant if you use manual capture.
refund.processed and refund.created: reverse the order, the commission, and any tax you counted.
subscription.charged and related events: for recurring billing, each cycle's success or failure.
payout events (RazorpayX): if you pay vendors out, track the payout lifecycle here.

Razorpay changes and adds events over time, so confirm the exact names and payloads against their current documentation before you ship.

The bugs we see most often

Signature checked on the parsed body. Re-stringified JSON never matches. Hash the raw bytes.
No idempotency. Retries double-fulfill. Dedupe by event id in a transaction.
Trusting the browser callback only. Payments go missing when the user closes the tab. The webhook is the source of truth.
Slow handler. Inline heavy work causes timeouts, retries, and duplicates. Queue it.
Money stored as floats. Rounding silently loses paise. Store amounts as integers in paise.
Ignoring refunds and disputes. The money goes out but your books never reflect it.
No raw-payload log. When something breaks at 11pm you have nothing to debug. Log every raw event.

How we build payment flows

Because this is money code, we treat it like the rest of a billing system: amounts stored as integers in paise, every webhook signature-verified on the raw body, every handler idempotent and backed by a queue, and a full log of every raw event so any payment can be traced end to end. We build it on Laravel or Node.js, pair it with reconciliation against the Razorpay API, and wire it straight into invoicing and GST e-invoicing. It is the same payment core that sits under our MultiVendor CRM and billing builds.

Common questions about Razorpay webhooks

Why is my Razorpay webhook signature verification failing?

Almost always because you are hashing the parsed-and-re-stringified JSON instead of the raw request body. Capture the exact raw bytes Razorpay sent and compute the HMAC SHA256 of those with your webhook secret. Also confirm you are using the webhook secret (set on the webhook), not your API key secret, and that you compare with a constant-time function.

Do I still need webhooks if I verify the payment on the client callback?

Yes. The client callback is unreliable because the browser can close, lose network, or never fire. The webhook arrives from Razorpay's servers regardless, so it is the only dependable way to know a payment succeeded. Use the callback for instant UX and the webhook as the source of truth.

How do I stop duplicate webhook processing?

Make the handler idempotent. Store each processed event id (or payment id plus event type) and check it before acting, within the same database transaction as the work. Webhooks are delivered at least once, so retries are normal and your code has to expect repeats.

What if Razorpay never sends the webhook?

It is rare but it happens, usually when your server was briefly down. That is why you also run reconciliation: a scheduled job that pulls recent payments from the Razorpay API and compares them with your database, so any missed payment is caught and fixed automatically instead of becoming an angry customer.

Should I capture payments automatically or manually?

Auto-capture is simplest and right for most stores: the payment is captured immediately on success. Use manual capture only when you need to verify something (stock, fraud checks) before taking the money, and then handle the authorized state and capture step explicitly. Either way, fulfil only after you confirm the captured status server-side.

Honest summary

Razorpay checkout is the easy 20 percent. The reliable 80 percent is the webhook: verify the signature on the raw body, make the handler idempotent, acknowledge fast and process on a queue, treat the webhook as the source of truth, and reconcile against the API so nothing is ever silently lost. Do those five things and your payments stop being a source of late-night surprises.

If you are integrating payments, or you suspect orders are slipping through, the cost calculator gives a rough estimate for a build, or send us a WhatsApp message with your stack and what you are seeing, and we will reply within 24 hours.

Payments slipping through, or building a new checkout? We build reliable Razorpay flows in Noida on Laravel and Node.js: raw-body signature verification, idempotent webhooks, queues, reconciliation, refunds, and GST invoicing, wired into your billing and CRM. → Scope a payments build

Passkeys in 2026: How Passwordless Login Actually Works (and Why You Should Add It)

Ravi Rai — Fri, 19 Jun 2026 06:37:00 +0000

Passwords are the worst part of every app. Users reuse them, forget them, get phished, and your support inbox fills with reset requests. In India there is an extra tax on top: SMS OTP, which costs money per message, gets delayed, and fails on weak signal. Passkeys fix all of it.

Passkeys are the passwordless standard built on WebAuthn, now supported by every major browser and operating system. Instead of a shared secret, each account gets a public and private key pair. Your server stores only the public key; the private key never leaves the user's device. Login becomes a biometric tap, and it is phishing-proof by design. This is the developer-honest guide to how they work, what changes on your server, the gotchas, and when to add them.

We build authentication into the web apps and SaaS we ship, usually on Node.js or Laravel backends with Next.js and React front ends, so the notes below come from shipping it, not just reading the spec.

What a passkey actually is

A passkey is a cryptographic key pair tied to one website. When a user registers, their device generates the pair. The private key stays locked on the device, in the secure enclave, TPM, or a password manager, and is unlocked with a fingerprint, face, or device PIN. The public key goes to your server. Nobody, including you, ever sees the private key.

Two flavours exist. Synced passkeys (Apple iCloud Keychain, Google Password Manager, 1Password) sync across a user's devices, so a new phone still has them. Device-bound passkeys (a hardware key like a YubiKey) stay on one device. Both are built on the same open standards: WebAuthn from the W3C, and FIDO2 underneath.

Why passkeys beat passwords and OTP

Phishing-resistant. The signature a passkey produces is bound to your exact domain. A fake look-alike site cannot get a usable signature, so phishing simply does not work.
No shared secret. There is no password to steal. A database dump contains only public keys, which are useless to an attacker.
No reuse. Each passkey is unique to your site, so a breach somewhere else cannot touch your users.
No SMS OTP. Passkeys remove the per-message cost and the 'I did not get the code' support tickets that come with OTP, which is a real saving in India.
Faster. A biometric tap beats typing a password and waiting for a code to arrive.

The two ceremonies: registration and login

WebAuthn has exactly two flows. Get these right and the rest is detail.

Registration (attestation)

The user is signing up or adding a passkey to an existing account. Your server generates a random challenge and sends it with your rpId (your domain). The browser calls navigator.credentials.create(), the device generates a key pair, and the user confirms with their biometric or PIN. The browser returns the new public key and a credential ID, and your server stores them against that user.

Login (assertion)

Your server generates a fresh random challenge. The browser calls navigator.credentials.get(), the device finds the matching private key, and the user confirms with their biometric. The device signs the challenge, and your server verifies the signature with the stored public key, checks that the challenge is the one it issued, that the origin and rpId match, and that the sign counter advanced. If all of that passes, they are logged in.

What changes on your server

For passkey users you stop storing a password hash and start storing, per credential:

Credential ID. The handle that identifies this specific key.
The public key. Used to verify every future login signature.
The sign counter. A number that increments each use. If it ever goes backwards, that signals a cloned key, and you can block it.
The user handle and rpId. So you know which user and which domain the credential belongs to.

On each login you verify four things: the signature matches the stored public key, the challenge is the single-use one you issued, the origin and rpId match your domain, and the sign counter moved forward. Do not hand-roll the cryptography. On Node we use SimpleWebAuthn; Laravel and most stacks have a mature WebAuthn package. The library handles the crypto so you handle the storage and the flow.

The gotchas that trip people up

rpId and origin must match exactly. A passkey registered on www.yoursite.com will not work on yoursite.com. Decide your canonical domain first, then register against it.
Challenges must be random, server-generated, and single-use. Reusing a challenge breaks the entire security model. Generate one per attempt and throw it away after.
Always keep a fallback. Not every user or device has passkeys yet, and people borrow devices. Offer passkeys alongside password or an email magic link, and let users register more than one passkey.
Account recovery is the hard part. If a user loses every device, you need a recovery path: a backup email magic link, a second passkey, or one-time recovery codes. Synced passkeys reduce this, but plan for it before launch.
Conditional UI (autofill) is the good UX. The passkey should appear in the login field's autofill prompt. It needs the autocomplete='webauthn' attribute and a slightly different call, and it is worth the effort.

When to add passkeys, and when to wait

Add them when account security genuinely matters (fintech, SaaS, dashboards, anything with payments or sensitive data), when you are paying for SMS OTP at scale and want that cost gone, or when password-reset tickets are eating your support time. Those are the cases where passkeys pay for themselves quickly.

Wait, or at least do not rush, when you have a tiny user base with no sensitive data and the added auth surface buys little, or when you do not yet have a fallback and recovery plan. Passkeys are additive: you can ship them next to passwords and migrate users over time, which is exactly how we recommend rolling them out. There is no need for a risky big-bang swap.

How we add passkeys to a product

We add passkeys as an additive layer, never a big-bang replacement. The shape on a Node.js backend: a credentials table (credential ID, public key, sign counter, user handle), four endpoints (begin and finish registration, begin and finish login) wired through SimpleWebAuthn, conditional-UI autofill on the Next.js login form, and a clean fallback to the existing login. On Laravel it is the same shape with a WebAuthn package. We keep password and email login working, let users add multiple passkeys, and build a recovery path before launch. It drops straight into a SaaS or CRM login without disrupting existing users.

Common questions about passkeys

Do passkeys replace passwords completely?

Eventually, but roll them out additively. Offer passkeys alongside passwords so users without them, or on a borrowed device, can still log in. As adoption grows you can nudge everyone to passkeys and retire passwords. A hard cut-over on day one is risky and unnecessary.

What happens if a user loses their phone?

With synced passkeys (Apple iCloud Keychain, Google Password Manager, 1Password) the passkey syncs to their other devices and to a new phone, so losing one device is not a lockout. For device-bound passkeys or single-device users you need a recovery path: a backup email magic link, a second registered passkey, or one-time recovery codes. Plan recovery before you launch.

Are passkeys actually phishing-proof?

Yes, by design. The signature a passkey produces is cryptographically bound to your exact domain. A fake site at a look-alike domain cannot get a usable signature, because the browser refuses to use the passkey on the wrong origin. That is the single biggest security win over passwords and OTP, both of which a convincing phishing page can capture.

Do passkeys work across browsers and devices?

Support is now universal across current Chrome, Safari, Edge, and Firefox, and across iOS, Android, macOS, and Windows. Synced passkeys move between a user's devices in the same ecosystem, and cross-ecosystem login is handled by scanning a QR code with the phone that holds the passkey. For practically every user in 2026, it just works.

Will passkeys reduce our SMS OTP costs?

Significantly, if OTP is your current login or second factor. Every passkey login is one less SMS, which in India is a real per-message cost plus the delivery failures and support tickets OTP brings. Many teams add passkeys specifically to cut the OTP bill and the 'I did not get the code' complaints.

How long does it take to add passkeys to an existing app?

For a typical web app with email and password login, a clean passkey integration is usually 1 to 3 weeks: the credentials table, the four WebAuthn endpoints, the front-end calls with autofill, a recovery path, and testing across devices. Most of the time goes into recovery and cross-device testing, not the happy path.

Honest summary

Passkeys are the first genuinely better replacement for the password: phishing-resistant by design, nothing for attackers to steal, no SMS OTP, and a one-tap login. They are built on WebAuthn, supported everywhere, and you add them additively without breaking existing logins. The hard part is not the cryptography, a library handles that. It is the boring but critical pieces: matching rpId to your canonical domain, single-use challenges, a fallback, and a real account-recovery path.

If you run a SaaS, a fintech product, or any app where a breach or an OTP bill hurts, passkeys are worth adding now. The cost calculator gives a rough estimate, or send us a WhatsApp message with your stack and login setup and we will reply within 24 hours with a plan.

Want passwordless login that kills phishing and SMS OTP costs? We add passkeys (WebAuthn) to web apps and SaaS in Noida on Node.js and Laravel, additively, with a proper recovery path and cross-device testing. It drops into your existing login without disrupting users. → Add passkeys to your app

AI Website Builders vs Hiring a Developer in India 2026: The Honest Take

Ravi Rai — Thu, 18 Jun 2026 07:02:30 +0000

Every week now a founder asks me some version of the same question: AI can build a website in two minutes, so why would I pay a developer? It is a fair question. In 2026 the AI website builders are genuinely impressive. Wix AI, Framer AI, Hostinger AI, Lovable, v0, and a dozen others will take a prompt and hand you a real, decent-looking site before your chai gets cold.

So here is the honest answer, from someone who builds websites for a living and uses AI tools every day to build them faster: AI builders are great for some things and quietly terrible for others. The trick is knowing which situation you are in before you commit. This guide breaks down what they are genuinely good at, where they fall apart, the hidden costs, and exactly when each option is the right call for an Indian business in 2026.

We are not anti-AI. We use AI coding tools daily, it is part of how we ship fast (more on that in how AI actually changes development). This is not a case of 'AI bad, hire humans'. It is about matching the tool to the job.

What AI website builders are genuinely good at

Speed. A simple site in minutes, not weeks. For a quick online presence, nothing is faster.
Cost. Often free to start, then a small monthly fee. No upfront build cost.
Simple, brochure-style sites. A few pages about your business, services, and contact. They handle this well.
Validating an idea. You want to test whether anyone cares before investing. A builder gets you live cheaply.
Zero budget, some time. If you can spend a weekend instead of money, a builder is a real option.

Where AI builders quietly fall apart

Custom logic and integrations. The moment you need Razorpay with GST invoices, a WhatsApp flow, a booking system, or a custom CRM, builders hit a wall or charge for clunky plugins.
Real e-commerce. Beyond a basic catalog you need control over checkout, payments, shipping, and tax that builders do not give you. For stores, Shopify or a custom build is a different league.
SEO that actually ranks. Builders produce bloated, generic markup and slower pages. For a young site fighting to rank, technical SEO and speed matter, and that is where builders are weakest.
Performance at scale. Fine for 5 pages. At 50 pages with real traffic, the cracks show: slow loads and poor Core Web Vitals.
You do not own it. Most builders lock you in. You cannot export clean code and leave; you rent your site forever.
Everything looks the same. AI builders pull from the same templates, so your site ends up looking like everyone else's.

The hidden costs of a 'free' AI builder

Free is rarely free. The real costs show up later:

Monthly rent forever. The free tier has ads and a builder subdomain. A real domain and decent features mean a subscription you pay for as long as the site exists.
Lock-in. When you outgrow it, you usually cannot migrate the code. You rebuild from scratch and pay twice.
Your time. 'AI builds it in minutes' is the demo. Making it actually good, the content, images, structure, and fixing what AI got wrong, is hours of your time, and your time is not free.
Transaction and feature fees. Payments, bookings, and apps often carry per-transaction fees or paid add-ons that add up.

When an AI builder is the right call

Be honest about where you are. A builder is genuinely the smart choice when:

You are pre-revenue and testing whether an idea has demand.
You need something live this week on a near-zero budget.
It is a simple brochure site, a few pages, no custom features.
You are fine rebuilding properly later once the business proves out.

There is no shame in starting on a builder. Plenty of real businesses began that way. The mistake is staying on one after you have clearly outgrown it.

When you actually need a developer

You need custom features or integrations: payments with GST, WhatsApp, a CRM, bookings, or ERP.
You are running real e-commerce or a web app, not a brochure.
SEO and ranking matter, so you need fast, clean, crawlable pages.
You want to own your code and data, with no lock-in.
Your brand needs to look distinct, not like a template.
The site has to scale: more pages, more traffic, more features over time.

If two or more of these are true, a builder will cost you more in the long run than a developer would have cost upfront.

The practical middle path

For most Indian founders the smart sequence is simple: start cheap to validate, invest once it works. Use a builder or a low-cost site to get live and test demand. The day the business is real, customers are coming, you need features, you are fighting for rankings, move to a custom build you own. We use AI to make that custom build faster and cheaper than it used to be, so the gap between 'builder' and 'real site' is smaller than it was two years ago.

And if you already have a builder site that is holding you back, you often do not need to start from zero. See when a site needs a rebuild versus a tune-up.

What each option costs in India, 2026

AI website builder: ₹0 to start, then roughly ₹400 to ₹2,000 per month for a custom domain and decent features, plus your time. Forever.
Simple custom site: a one-time build from around ₹15-40K that you own, with no monthly rent beyond cheap hosting.
Custom site or web app with features: ₹50K and up depending on what it does. Use the cost calculator for a rough number.

The honest framing: a builder is cheaper this month, a custom site is usually cheaper over two or three years once you factor in rent, lock-in, rebuilds, and lost SEO.

Common questions

Are AI website builders good enough in 2026?

For a simple brochure site or to validate an idea, yes, they are genuinely good and fast. For real e-commerce, custom features, integrations like Razorpay with GST, or a site that needs to rank well and scale, they fall short. Match the tool to the job: a builder for simple and temporary, a developer for custom and lasting.

Will an AI-built website rank on Google?

It can get indexed, but ranking competitively is harder. Builders tend to produce slower, heavier pages with generic markup, and ranking depends on speed, clean structure, and content. For a young Indian site fighting to rank, those weaknesses matter. A properly built site gives you far more control over the technical SEO that actually moves rankings.

Can I move from an AI builder to a custom site later?

Usually you rebuild rather than migrate, because most builders lock you in and do not let you export clean code. Your content and assets carry over; the site itself is built fresh. That is why starting on a builder is fine for testing, but plan to rebuild once the business is real, and budget for it.

Is it cheaper to use a builder or hire a developer?

A builder is cheaper this month. A custom site is often cheaper over two to three years, once you add up the monthly subscription, transaction fees, the eventual rebuild, and the SEO and conversions you lose on a slower, generic site. Cheap upfront is not the same as cheap overall.

Do you use AI to build websites?

Yes, every day. AI tools make us faster and let us pass lower prices on. The difference is that we use AI as a tool inside real engineering, with proper architecture, integrations, performance, and ownership, rather than handing you whatever a builder spits out. The result is a custom site, built faster.

Honest summary

AI website builders are a real, useful tool in 2026, not a threat to good developers and not a scam. For a simple site, a tight budget, or testing an idea, use one without guilt. For real e-commerce, custom features, ownership, and rankings, you need a developer, and the gap in cost has shrunk because good developers now use AI too. The expensive mistake is using a builder for a job it cannot do, then paying twice to fix it.

Not sure which camp you are in? Tell us what you are trying to build and your budget, send a WhatsApp message or get a quote, and we will tell you honestly whether a builder is fine or whether you actually need a developer. We will not upsell you a custom build you do not need.

Wondering whether an AI builder is enough or you need a real developer? We will give you an honest answer in one message, no upsell. Custom websites, e-commerce, and web apps, built in Noida with flat INR pricing, and yes, built faster because we use AI too. → Get an honest recommendation