DEV Community: Preciousky

The four things a website rebuild does not inherit: a migration runbook (India, 2026)

Preciousky — Wed, 29 Jul 2026 17:24:01 +0000

Disclosure: I work on delivery at ZoopCoder, a web and app development agency in India. Rebuilds are our higher-value work, so I have a commercial interest in you concluding "rebuild" — which is why this post is mostly about how to avoid needing one, and it publishes the number that argues against my own side.

Most "should we rebuild?" arguments happen on the wrong axis. People argue about the stack. The thing that actually decides the price, the timeline and the risk is what survives the move.

A redesign inherits everything for free, because nothing moves. A rebuild inherits nothing for free. That gap — not the framework, not the design hours — is where the entire cost difference lives, and it is why a rebuild quote with a big total and no migration lines is a quote for a different project.

Here is the runbook I wish more Indian rebuild quotes were written against.

First: does it even need to be a rebuild?

Three switches. Run them line by line down the change list, not on the project as a whole. One yes anywhere on a line puts that line into rebuild territory.

The platform changes. Builder → WordPress, WordPress → custom, one framework → another. Also: the platform is abandoned, or nobody has the code.
The site must start remembering something it does not store today. Logins, orders, uploaded files, a consent record, roles.
The URL structure changes. Addresses change, sections merge or split, new domain, language prefix.

Zero yeses across the whole list means it is a redesign, whatever anyone is calling it. This matters more than it sounds: it is common for eleven items out of twelve to be pure redesign and exactly one item — usually "let customers log in" — to be the only thing flipping a switch. That item can very often be carved out and scoped separately later, at a fifth of the price today.

Indian bands, 2026, for calibration:

Work	Band
Restyle a brochure site, same pages, same URLs	₹25,000–₹50,000
Restyle a WordPress site	₹35,000–₹75,000
"It is slow" — measure first	₹0–₹15,000 in most cases
Rebuild off a closed builder onto WordPress	₹35,000–₹75,000 + content carry
Rebuild that adds logins, roles or payments	₹1,00,000+

The four inheritances

Inheritance	Redesign	Rebuild	Reversible?
URLs	Kept, free	Lost by default	No, in practice
Content	Kept, free	Re-entered page by page	Yes, expensively
Data	Untouched	Mapped migration	No
Accounts	Untouched	Must be transferred	Yes, slowly

1. URLs — the 301 map is a deliverable, not a task

Ask for it as a file, before you sign. Every existing URL on the left, its destination on the right.

Building the left column properly means unioning three sources, because none of them is complete on its own:

sitemap.xml — what the CMS thinks exists.
Search Console → Pages → the indexed list — what Google actually has.
The access log — what real traffic hits. On an old site this is where the surprises are: PDFs, old campaign landing pages, /index.php-style paths, an /amp/ variant nobody remembers shipping.

# distinct paths real traffic actually requested, most-hit first
awk '{print $7}' /var/log/nginx/access.log \
  | sed 's/?.*//' | sort | uniq -c | sort -rn | head -200

Rules that save you later: map to the closest equivalent page, never blanket-redirect everything to / (Google treats a mass redirect to the homepage as a soft 404 and you keep none of it), chain nothing more than one hop, and publish the map with the new site rather than a week after. Then watch crawl errors weekly for a month — the map is never complete on day one, and the log tells you what you missed.

This is the line most often absent from an Indian rebuild quote, and it is the one whose absence is invisible until traffic drops.

2. Content — decide who types it in, in writing

"We will migrate the content" is not a scope line, it is an ambiguity. Page-by-page re-entry is real hours and it is the item most often silently handed back to the client mid-project, which is also the single biggest cause of a slipped date. Put the answer in the document: who types it in, you or me?

3. Data — the only irreversible one

Not "we will move the data". The line should read: export → field map → import → reconcile row counts → spot-check N records together.

-- run on both databases after the import; the numbers must match
SELECT 'enquiries' AS t, COUNT(*), MAX(created_at) FROM enquiries
UNION ALL SELECT 'orders', COUNT(*), MAX(created_at) FROM orders
UNION ALL SELECT 'users',  COUNT(*), MAX(created_at) FROM users;

Then the cheapest insurance in the whole project: keep the old database live and read-only for 90 days after cutover, on a staging address. It costs almost nothing and it is the difference between an inconvenience and a catastrophe. Silent truncation of a TEXT column into a VARCHAR(255), timezone drift on created_at, dropped rows where a NOT NULL was added — none of these announce themselves, and all of them are recoverable if the source is still there.

Watch the encoding too. A lot of older Indian WordPress installs are utf8 (3-byte) rather than utf8mb4, so anything with an emoji or certain Indic sequences will silently mangle on the way into a stricter target.

4. Accounts — not technical work, and the usual reason it stalls

Registrar, hosting panel, DNS, analytics, Search Console, payment gateway, repository, and any transactional email or SMS sender. None of this is engineering. All of it is other people's queues — registrar transfers and gateway KYC in India routinely take a week each — and it is the single most common reason a rebuild sits stalled for three weeks with the code already finished.

Start it in week one, with every account created in the client's name and the developer added as a user. Not zipped up and handed over at the end.

Two more worth naming: keep the existing GA4 and Search Console properties rather than creating new ones — history is free to keep and impossible to recreate — and annotate the cutover date so that six months later you can tell a rebuild effect from a seasonal one.

Two dates that belong in the plan, not in the retro

3 October. If the client capitalises the rebuild as software, it is depreciated at 40% WDV rather than deducted, and the second proviso to section 32(1) of the Income-tax Act halves depreciation where an asset is put to use for under 180 days in the year. In an ordinary Indian financial year, 3 October is the last day that still completes 180. On ₹1,50,000 that is ₹60,000 of year-one depreciation if you go live on 3 October and ₹30,000 if you go live on 4 October. Same code, same invoice, one calendar day. A redesign treated as revenue expenditure under section 37 is usually deductible in full and is unaffected — in CIT v. Indian Visit.com (P.) Ltd. the Delhi High Court held website spend produces no accretion to fixed capital. Classification follows what was actually done, never the noun on the invoice. (General information, not tax advice — worth an hour of the client's CA.)

13 May 2027. The DPDP Act 2023's substantive obligations on ordinary Indian data fiduciaries are set to apply from this date under the rules notified in November 2025. What it asks for is structural: a plain-language itemised notice available in English or any Eighth Schedule language at the user's option, consent as a specific affirmative action, withdrawal as easy as giving, and erasure afterwards. In schema terms that is somewhere to write a consent record, something to match a withdrawal against, and a delete path — plus the retention rule that makes the delete meaningful. If you are rebuilding anyway, build it once now instead of retrofitting in eighteen months. Treat the date as a planning date; the phasing has moved before.

The number that argues against my own business

A redesign that keeps the platform, the content and the URLs typically costs between a third and a fifth of a rebuild of the same site, and carries almost none of its risk. If the switch test comes back all-off — and "it looks dated and it is slow" comes back all-off — the honest answer is a redesign.

Especially "it is slow". On small Indian business sites that is almost always one of three cheap things, in this order: uncompressed images straight off a phone, oversubscribed shared hosting, and plugin bloat. Measure, fix those, measure again. A rebuild will certainly produce a fast site; so would ₹8,000 and a Saturday, and only one of those bills arrives twice.

And "we want better SEO" is backwards. A rebuild is the most reliable way to lose rankings, because it changes URLs. Rebuild for what the site must do, never for what you hope a search engine will do afterwards.

Full version with both price tables, the three-switch matrix and the tax breakdown: Should you redesign your website or rebuild it? (India, 2026)

The agency premium in India is 20% or 42% - and it depends on your GST registration, not their price

Preciousky — Fri, 24 Jul 2026 10:34:56 +0000

Disclosure: I work at ZoopCoder, a small development agency in India. So the whole point of this post is a number that argues against hiring us — 42% — and it is the number our own industry never prints.

The rule first, because it is the only part most people need

In India in 2026, hire a freelancer if the project is under roughly ₹1,00,000, has a scope you can write on one page, and could survive a two-week pause. Hire an agency once it crosses ₹1,00,000, needs more than one skill set, or has a launch date you cannot move.

That is it. Everything else here is the arithmetic behind it, plus one statutory fact that changes the answer for about half the people reading this.

The exclusive fact: the agency premium is 20% or 42%, and it depends on YOUR registration, not their price

Every freelancer-vs-agency comparison you will read compares sticker prices. In India the sticker price is not the price, because of one asymmetry that nobody puts in the table.

Most Indian freelancers bill without GST — under the ₹20 lakh services turnover threshold they are not required to register. Every agency bills with 18% GST. If you are a GST-registered business, that 18% is input tax credit: you pay it and you reclaim it. If you are not registered, it is money you never see again.

Take a ₹1,00,000 freelance quote against a ₹1,20,000 agency quote for the same scope:

Your situation	Freelancer (no GST)	Agency ₹1,20,000 + 18% GST	Real gap
GST-registered business	₹1,00,000 real cost	₹1,41,600 paid, ₹21,600 reclaimed as ITC → ₹1,20,000 real cost	20%
Not GST-registered	₹1,00,000 real cost	₹1,41,600 paid, nothing reclaimable → ₹1,41,600 real cost	42%

Same two vendors. Same quotes. The premium is either 20% or 42% purely because of a fact about you.

If you are a registered company, the tax is a wash and the agency decision is a straight question of whether continuity is worth a fifth more. If you are a proprietor, an individual founder, a doctor building a clinic site, a small trust — you are in the 42% row, and the agency is genuinely around 40% more expensive than the quote makes it look. That is a real argument for hiring a freelancer and I would rather you heard it from an agency than found it on the invoice.

(General information, not tax advice. Confirm your own position with your CA.)

The second statutory fact runs the other way: Section 194J

If you are a business paying for development services, you are generally required to deduct TDS before paying — commonly 10% under Section 194J for professional and technical services — and deposit it against the vendor's PAN.

An agency does this every month and issues the invoice correctly. A first-time freelancer frequently does not know the rule, has not budgeted for it, and then reads the 10% you correctly withheld as you short-paying them. It is a small administrative thing that sours a genuinely large number of otherwise fine projects.

Ask, in writing, before the first payment: are you registered for GST, and do you account for TDS under 194J? Two sentences, and it removes the two most common payment fights in Indian software work.

The rate bands, briefly

	Freelancer	Small agency	Mid-size / enterprise
Typical rate	₹400 – ₹1,200 / hr	₹800 – ₹2,000 / hr	₹1,500 – ₹6,000 / hr
People on your project	One	Designer + dev(s) + QA	Team + dedicated PM + BA
If they vanish	Project stops — there is no bench	Someone else picks it up	Contractually guaranteed cover
Recourse	Often just a chat thread	Written scope, fixed price, milestones	MSA, SLA, indemnity
GST on the invoice	Often none (below ₹20L turnover)	18%, reclaimable if registered	18%, reclaimable if registered

So the same 8-screen app is roughly ₹60,000–₹1,50,000 freelance versus ₹1,00,000–₹3,00,000 at a small agency. A 40–100% premium that buys exactly one thing: continuity. A freelancer is a single point of failure; an agency is a contract, a team, and somebody still answering the phone in month seven.

Where the freelancer advantage disappears — and it is not where people expect

The interesting part of pricing the same project both ways is what happens at the top of the range, not the bottom:

Business website, 5–10 pages — ₹15,000–₹35,000 freelance vs ₹25,000–₹50,000 agency. The freelancer is genuinely close to half price. Take it.
Simple Flutter app — ₹35,000–₹80,000 vs ₹50,000–₹1,00,000. Still a real saving.
Medium app, logins + payments — ₹80,000–₹2,00,000 vs ₹1,00,000–₹2,50,000. The bands are starting to overlap.
SaaS MVP — ₹1,50,000–₹6,00,000 vs ₹1,50,000–₹5,00,000. The bands have fully overlapped.

At ₹25,000 a freelancer is half the price. At ₹5,00,000 there is no price advantage left at all, because a solo developer building a SaaS MVP has to sub-contract the design, the DevOps and the QA they cannot do themselves — and the coordination cost of that lands on you, unpaid and unmanaged. You end up as the project manager of an agency you accidentally assembled, at agency prices, with none of the accountability.

When an agency is the wrong buy — written by an agency

An agency that claims to be right for every project is telling you about its sales targets, not your project. Cases where hiring one of us is a waste of your money:

A one-to-five page site under ₹25,000. There is nothing for a team to coordinate. Our overhead is pure dead weight at this size.
A single well-defined change to something that exists. Add a gateway. Fix a form. Migrate a host. One skill, one person, one week.
You already have a technical co-founder or in-house lead. You already own the thing you would be buying. Buy hands, not a team.
Ongoing small changes after launch. Once a product is built, documented and handed over, a retained freelancer at ₹15,000–₹30,000/month out-values most agency support plans. Agency to build, freelancer to maintain, is genuinely the smartest hybrid I know.

And the mirror image, where a freelancer is a mistake rather than a saving: a launch date you cannot move; work needing design + backend + mobile + DevOps simultaneously; anything holding money or personal data; anything a regulator or a client depends on; and — the quiet killer — any build where you personally cannot judge whether the output is good. Managing a freelancer well requires you to be able to evaluate the work. If you cannot, you are not saving 42%. You are buying an unmeasurable risk at a discount.

The failure mode that actually costs money

Bad freelance projects almost never fail because the code was bad. They fail because the person stopped replying. One human being has one life: illness, a full-time offer, a better client, burnout.

And the loss is not the money already paid. The loss is the half-finished, undocumented codebase. Picking up someone else's abandoned project typically runs 30–50% more than building from scratch, because the next developer has to read and trust code they did not write before they can safely change a line. Many will refuse and quote you for a rebuild instead. That is how an ₹80,000 saving becomes a ₹1,80,000 bill and four lost months.

What to actually do

Work out which GST row you are in before you compare quotes. It moves the real gap from 20% to 42%.
Ask both candidates, in writing: GST registration status, and TDS/194J handling.
Under ₹1,00,000 with a one-page scope → freelancer.
Over ₹1,00,000, or multi-skill, or a fixed launch date → agency.
After launch → retained freelancer, almost always.

The long version of this, with the full price-both-ways table and our own published rates rather than a competitor's range, is here: https://zoopcoder.com/guides/freelancer-vs-agency-india.php — and our actual prices, which you can check the table against, are at https://zoopcoder.com/pricing.php

I run an agency. If the 42% row is you and the project is small, hire the freelancer.

Paying for your code does not mean you own it: what section 19 of India's Copyright Act silently does to your contract

Preciousky — Thu, 23 Jul 2026 10:34:08 +0000

I run ZoopCoder, an Indian development agency. Everything below argues against my own commercial interest — by default, the code my team writes for you belongs to us, and I am about to explain exactly how to take it. Check every section number against the bare Act before you rely on it.

The rule

Paying for a build does not transfer copyright in India. Only a signed assignment does — and if that assignment does not state a duration and a territory, the statute quietly rewrites it to five years, India only.

That is not a drafting opinion. It is sections 17, 19(5) and 19(6) of the Copyright Act, 1957, and it is the single most expensive thing Indian founders do not know about their own software.

The exclusive fact: the clause that expires

Almost every Indian development contract I have seen contains a sentence like:

"All intellectual property created under this agreement shall belong to the Client."

Read literally against the statute, that sentence can give you five years of Indian rights in your own product, and then it lapses back to the developer.

s.19(1) — an assignment of copyright is valid only if it is in writing, signed by the assignor. A quotation email, an invoice marked "full and final", a WhatsApp "yes bhai it's all yours" — none of these are assignments.
s.19(2) — the assignment must identify the work and specify the rights assigned, the duration and the territorial extent.
s.19(5) — if the duration is not stated, the assignment is deemed to be for five years.
s.19(6) — if the territorial extent is not stated, it is presumed to extend only to India.

So the fix costs you nine words. Write "for the full term of copyright" and "worldwide" into the same sentence, and both statutory defaults disappear. Leave them out and you have bought a lease, not the thing.

Why the default is not what buyers assume

Under s.17, the first owner of copyright is the author — the person who wrote it. The one common case that flips automatically is a work made by your own salaried employee in the course of employment under a contract of service.

An agency or a freelancer works under a contract for service. That is outside the rule. The copyright stays with them until they assign it in writing.

How the code got written	Who owns it by default	What you must sign to change it
Your own salaried employee, in the course of their duties	You (the company)	Nothing — but keep an IP clause for work done outside duties
A freelancer you paid per milestone	The freelancer	A written, signed assignment under s.19
An Indian agency	The agency	A s.19 assignment plus a warranty that its own staff's rights sit with it
An offshore/foreign vendor	Follows the contract and its governing law, which may not be Indian law at all	Assignment + an enforceable governing-law and jurisdiction clause
An intern or a friend, unpaid	Them	A signed assignment — and do it while they still like you
Written substantially by an AI assistant	Unsettled. Indian copyright is built around a human author and no Indian court has decided it	Drafting that works either way: a right-to-assign warranty + an indemnity, not a confident answer

The label on the paper does not decide the employee question either. Courts look at control, integration and the substance of the relationship — calling someone a consultant while treating them as staff is decided on the facts, not the letterhead.

Handover is not ownership

This is the most common misunderstanding in Indian software buying, and it survives because both words feel like the end of the project.

Handover is a delivery event. You receive files.
Assignment is a legal transfer. You receive rights.

You can hold a complete copy of the source, on your own server, in your own GitHub org, and still not own the copyright in it — which means your developer can lawfully reuse the same code for your competitor, and you cannot lawfully licence it to anyone.

Three more things a handover is not: it is not a warranty that the code is original rather than copied; it is not a transfer of the third-party licences inside it; and it is not the author's moral rights, which under s.57 stay with the author no matter who owns the copyright. That last one is why "we own absolutely everything" is never literally true.

Put assignment and handover in the contract as two separate obligations, because they are two separate things.

The number that argues against us

Here is the honest cost table, and note that every "before" figure is zero. Ownership is free to agree and expensive to retrofit — which means the leverage is entirely yours right up until you pay the first instalment, and entirely ours afterwards.

Situation	Cost to fix before the build	Cost to fix after
No assignment signed, developer cooperative	₹0 — one clause in the proposal	A deed of assignment: goodwill or a small fee, plus a lawyer's time
No assignment signed, relationship broken down	₹0	Whatever they decide your need is worth — you negotiate from zero leverage
Assignment silent on duration and territory	₹0 — two phrases in one sentence	A fresh signed deed, at the moment you can least wait: mid-diligence or mid-raise
Domain, hosting or Play Console in the developer's name	₹0 — register them yourself	Transfer processes measured in weeks, with a listing you cannot update meanwhile
Undisclosed copyleft component in a commercial product	₹0 — ask for the component list	Replacing it, or complying with its licence, after you have shipped

And if the developer cannot be found or will not sign, the only clean exit is a rebuild. In our experience that costs 60–80% of the original build — you are re-paying for work that already exists and that you already paid for once.

What to do, in order

Decide it before the first instalment, not at handover. Put the assignment in the same document as the price and make the first payment conditional on it being signed. A developer who will not sign an assignment at quotation stage has just told you something useful for free.
Write the four things s.19 requires — writing + signature, the work identified, the rights, the duration ("full term of copyright"), the territory ("worldwide"). Describe the work widely: source code, designs, databases, documentation, and anything created during the engagement.
List the handover separately: repository with full commit history, environment and config files, deployment credentials, design source files, database schema, build pipeline.
Register the accounts in your own name from day one — domain, DNS, hosting, Play Console, App Store Connect, payment gateway. This is the cheapest control you will ever buy and the one most often skipped because the developer offers to "handle it".
Ask for the third-party component list before launch, not after. A copyleft library inside a commercial product carries obligations no assignment clause can override.

The one clause we would refuse

For completeness and against interest: an assignment that also demands we hand over our internal framework, boilerplate and reusable libraries — the pre-existing code that predates your project and is used across every client. No agency can honestly sign that away, and one that does is either lying to you or lying to its other clients.

The correct shape is: you own everything created for you; we grant you a perpetual, irrevocable, worldwide licence to the pre-existing components embedded in your build. If a vendor cannot articulate that distinction, that is your signal — not the price.

I am not a lawyer and this is not legal advice — it is what an agency wishes clients would ask for. Read the Act, or have a lawyer draft the clause; either costs less than the rebuild.

The long version, with the full clause checklist and the position if you have already built and signed nothing, is here: Who owns your website or app code in India. Our pricing is public at zoopcoder.com/pricing.php, including what we charge to build with the assignment already signed — which is the same as without it, because it should be.

Your first developer is statutorily your cheapest one: the in-house vs agency arithmetic in India

Preciousky — Wed, 22 Jul 2026 01:41:25 +0000

Disclosure: I work at ZoopCoder, an Indian development agency. That means I have an obvious commercial interest in you buying agency hours instead of hiring. I have tried to write this so you can check every number yourself, including the ones that argue against us — there is a section near the end that tells you when to stop paying us. Every rupee figure here comes off our own published pricing page or off public statute, and I have said which is which.

Every "in-house developer vs agency" post I have read compares an hourly rate to a monthly salary and calls it analysis. That comparison is wrong in two specific, checkable ways, and both of them are things Indian founders discover after they have signed the offer letter.

Here is the short version, then the arithmetic.

The rule: it is not the rate, it is the utilisation

Hire in-house once you can honestly forecast more than about 900 hours of development work a year — roughly 18 hours a week, every week, for twelve months. Below that, an agency is cheaper.

Why 900:

A developer on a ₹8,00,000 CTC costs about ₹10,50,000 a year once hardware, software seats, recruitment and statutory contributions are counted.
That same person returns roughly 215 productive working days — not 365, and not 250. (365 − 104 weekend days − 10 public holidays − ~21 days of leave.)
₹10,50,000 at ₹1,200 an hour — the middle of our published ₹800–₹2,000/hr band — buys about 875 hours, or ~110 working days of agency time.

So the crossover is not "who is cheaper per hour". At ~215 days versus ~110 days, the employee is obviously cheaper per unit of work — if you have the work. The whole question is whether you can keep one person busy all year. Most companies I talk to, when they actually write the list down, land somewhere between 300 and 600 hours.

Development work per year	~Hours/week	Agency @ ₹1,200/hr	In-house (₹8L CTC, loaded)	Cheaper
120 hrs	~2.5	₹1,44,000	₹10,50,000	Agency
300 hrs	~6	₹3,60,000	₹10,50,000	Agency
600 hrs	~12	₹7,20,000	₹10,50,000	Agency
~875 hrs	~18	₹10,50,000	₹10,50,000	Line ball
1,200 hrs	~25	₹14,40,000	₹10,50,000	In-house
1,720 hrs (full year)	~36	₹20,64,000	₹10,50,000	In-house

Notice what that table does to the usual argument. Below the line it is not close. Above the line it is not close either. Almost nobody is actually near the crossover — people just never compute which side they are on.

The fact nobody models: your statutory cost is a function of your headcount, not their salary

This is the part I have genuinely never seen in an Indian cost article, and I think it is because most of them are structurally copied from US pieces where the equivalent thresholds work differently.

In India, the three big employer-side obligations are triggered by the size of your establishment, not by what you pay the person:

Obligation	Employer-side cost (indicative)	Headcount trigger
EPF	~12% of wages	20 employees
ESI	~3.25% of wages	10 employees
Gratuity	accrues ~4.81% of wages	10 employees

Read that column again. It means:

Your first developer is usually your statutorily cheapest one.

A five-person company hiring its first developer typically owes none of the three. The identical hire, same salary, same laptop, made by a twelve-person company carries ESI and gratuity. At twenty employees it carries EPF too. Same human, same offer letter, materially different annual cost — and the variable is the size of the company doing the hiring.

Practical consequence: if you are a 9-person company thinking about your tenth and eleventh hires, the marginal cost of hire #10 is not one salary. It is one salary plus a step-change in the cost of everyone already on the payroll. That is a real cliff and it belongs in the model.

Caveats, because this is statute and statute moves: these are the thresholds as they stand at the time of writing, voluntary coverage below the thresholds is possible and some companies choose it, and the Labour Codes redefine "wages" in a way that raises PF and gratuity where the new definition applies. Confirm your own position with your CA before you budget off this. I am an engineer at an agency, not your accountant.

The second asymmetry: GST cuts the other way

The agency invoice carries 18% GST. Whether that is a real cost depends entirely on one thing:

You are GST-registered: you reclaim the whole 18% as input tax credit. The agency's headline price is the real price. This comparison is a straight cash comparison.
You are not registered (proprietor, small trust, startup below the threshold): that 18% is unrecoverable. A salary carries no GST at all, because employment is outside the scope of GST.

On ₹10,50,000 of agency work that is about ₹1,89,000 of unrecoverable tax. It moves the crossover from ~875 hours down to ~742 hours a year — from about 18 hours a week to about 15.

So the honest rule has a branch in it:

GST-registered → hire in-house above ~18 hrs/week of real work.
Not GST-registered → hire in-house above ~15 hrs/week.

What the money comparison completely misses

Cost is the easy axis. These are the ones that actually decide it:

	In-house developer	Small agency
Time to first line of code	30–90 days (notice period + ramp)	days
Cost when work goes quiet	full salary	₹0
Failure mode	resignation — one person holds every credential and every undocumented decision	being busy — your urgent Tuesday bug competes with someone else's urgent Tuesday bug
Recovery from that failure	2–3 months to rehire and re-ramp	escalate, or leave
Breadth	one person's stack	a bench, but rented
Availability	yours all day	shared

I want to be straight about the second column, because it is the thing agencies do not put on their websites: an agency has other clients. If your product needs someone reachable within the hour on a normal Tuesday, an employee is genuinely better and no amount of cost arithmetic changes that. Pick the failure you can survive — a two-week wait for attention, or a two-month wait for a replacement.

When you should fire us and hire someone

Under LAW-of-not-wasting-your-money, here is the honest list. If any of these is true, stop retaining an agency:

You ship changes more than weekly. The per-request overhead of a contract relationship eats the savings.
Software is the product, not a support function for the product. Then the codebase is your company and it should not live in a vendor's head.
You need a developer on customer calls — reading the actual bug report, in the actual meeting, unfiltered.
Your retainer is already above roughly ₹85,000/month. That is a salary. Pay it as one.

That last one is the number that argues against us most directly, so here it is stated plainly: a fully-utilised in-house developer works out to roughly ₹491–₹641 per productive hour (₹10,50,000 over 215 days), which is below the bottom of our own quoted ₹800–₹2,000/hr band. If you can keep them busy, they win on price. We are not cheaper than a busy employee and I am not going to pretend otherwise. We are cheaper than an idle one, and most first hires are partly idle.

The pattern that usually wins

For a company with a live product, the cheapest correct answer is usually neither/both: agency builds v1 on a fixed-price contract, then one in-house developer takes over day-to-day, and the agency is retained only for bursts the employee cannot absorb — a payments migration, an app-store rewrite, a security review.

That only works if you own the code from day one. Whichever side you pick, insist on the same terms: the repository lives in an account you own, source code is assigned to you in writing, credentials are in your password manager and not someone's laptop, and there is a written handover obligation.

Full working — the 9-line loaded-cost breakdown, the statutory table with the "does it hit a ₹8L developer" column, and the 12-row comparison — is on the guide this post is drawn from: In-House Developer vs Agency in India (2026).

If you disagree with the 900-hour threshold I would genuinely like to hear the counter-case in the comments — the input I am least sure of is the ₹1,200/hr midpoint, since that varies a lot by city and by stack.

React Native vs Flutter in India: the build cost is identical, the year-two hiring cost is not

Preciousky — Mon, 20 Jul 2026 13:04:35 +0000

Disclosure: I work at ZoopCoder, a small development agency in India. We build in both React Native and Flutter, and our internal default is Flutter — so discount everything below accordingly. I've linked our own pricing at the end so you can check whether I'm quoting real numbers or marketing ones.

I've watched this argument happen in maybe forty client kickoffs now, and it almost always gets decided on the wrong axis. Someone brings a comparison table full of rendering-engine details, someone else says "Flutter will be cheaper," and the actual cost driver never comes up.

So here is the uncomfortable version, with our real published numbers.

The build cost is identical, and I'll show you our own price list to prove it

This is the part agencies avoid publishing because it removes a sales lever. Here is what we charge for the same scope in each framework:

What you're building	React Native	Flutter	What actually moves the price
Simple app, 4–8 screens, no login	₹50,000 – ₹1,00,000	₹50,000 – ₹1,00,000	Screen count, how custom the design is
Medium app, logins + payments	₹1,00,000 – ₹2,50,000	₹1,00,000 – ₹2,50,000	The backend and the payment gateway
Marketplace / on-demand	₹2,50,000+	₹2,50,000+	User roles, live tracking, payouts
Backend hosting, monthly	₹3,000 – ₹25,000	₹3,000 – ₹25,000	Users and data — framework irrelevant
Maintenance, monthly	₹5,000 – ₹30,000	₹5,000 – ₹30,000	OS releases, store policy changes

The columns are the same on purpose. What consumes an app budget is screen design, API integration, the payment gateway, testing on real low-end Indian Android devices, and getting through store review. Every one of those costs the same in Dart as it does in TypeScript.

If a vendor quotes you meaningfully cheaper "because Flutter," they are discounting to win the job and will find the money back somewhere. That's worth saying plainly even though it's a sentence that costs us work.

So what does the framework actually decide? Your year-two hiring cost

The rule we use internally:

Pick Flutter if the app is under about ₹2,50,000 and its job is screens, forms, lists and payments. Pick React Native if you already run a React or Next.js web product, or if you plan to hire an in-house mobile developer in India within twelve months.

That second clause is the one that matters and the one nobody prices. React Native recruits out of the enormous Indian JavaScript pool — the same pool your web hiring already draws from. Dart is a separate specialism with much thinner local supply, so you wait longer and pay more for equivalent seniority.

Note what is not on that list: code sharing with your React website. You do not share code. You share the language, the tooling, the state patterns, the reviewers and the hiring pipeline. That distinction has cost founders real money when they budgeted for the first and got the second.

The thing that makes "which one builds faster" irrelevant

Framework comparisons argue about build speed in days. Your launch date is decided by something almost no RN-vs-Flutter article mentions.

If you publish under a personal Google Play developer account opened after November 2023, Google requires a closed test with at least 12 testers opted in continuously for 14 days before you can even apply for production access.

Not 12 downloads. Twelve people opted in and staying opted in, for a fortnight, before the application is even accepted. Apple review then adds its own days on the other platform.

That is a two-to-three week gate that is completely indifferent to your framework, your agency, and your code quality. A framework choice that saves three developer-days cannot save you a fortnight of Google's clock.

Two practical consequences:

Put the store gate in the plan before anyone argues about compile times.
Start recruiting your 12 testers while the app is still being built. Staff, friends, early customers, a WhatsApp group. For a small business with no existing user base this is a genuinely hard requirement, and in our experience it is the single most common reason a first app launches later than promised.

An organisation-type developer account is exempt from the 12-tester rule, which is often reason enough to register one properly.

Cross-platform means one codebase, not one machine

iOS release builds must be compiled and signed on macOS — in React Native and in Flutter alike. Neither framework removes Apple's requirement. Add the Apple Developer Program (99 USD/yr) and Google Play's one-time 25 USD, and if nobody on the project owns a Mac you are paying for hardware or a cloud build service on top of the quote.

Ask any vendor, in writing, whether iOS build and signing infrastructure sits inside their price. It is the most common surprise line in an Indian cross-platform budget, and choosing the other framework does not avoid it.

Where we tell clients to overrule our own Flutter default

We prefer Flutter. An agency that recommends the same framework to every client is describing its own comfort, not your project. The cases where we say React Native against our own preference:

You already run a React or Next.js web product. Strongest tie-breaker on the list; wins on its own.
You'll hire an in-house mobile developer in India within a year. Hire-ability beats everything on the feature table.
A vendor SDK you depend on ships React Native support first. Some payment, KYC, chat and analytics providers still maintain an official RN package and leave Flutter to the community. One missing official SDK becomes weeks of native bridging. Listing every SDK your app needs and checking both takes about an hour and has reversed the decision on real projects of ours.
Install size is a real constraint. Flutter adds roughly 4–8 MB. For most apps that's noise. Selling into price-sensitive markets on entry-level Android phones with tight storage, it can be conversion.

And the mirror image — we hold the Flutter line for heavily animated, design-led apps, anything that must look pixel-identical across devices, and a first app at a company with no existing JavaScript team.

What getting it wrong costs

Switching frameworks later is not a migration, it's a rewrite. Budget 60–80% of the original build: every screen built again from scratch, while the backend, API, design and product decisions carry over. On a ₹2,00,000 app that's ₹1,20,000–₹1,60,000 to arrive exactly where you already were, feature for feature, with nothing new to show a customer.

Which is why the protective move matters more than the choice: keep business logic on the server, not in the app. Anything that lives on your backend survives a framework change untouched.

The full version of this — the buyer-facing comparison table, both price columns, and the store-gate detail — is on our site: React Native vs Flutter in India (2026). Our actual price list is at zoopcoder.com/pricing.php if you want to check the numbers above against what we publish.

Third-party figures (Apple/Google fees, Play Console policy) are accurate as of July 2026 and do move — verify against the console before you rely on them.

Nobody can quote you a per-page website rate in India, and the reason is worth Rs 75,000

Preciousky — Sun, 19 Jul 2026 10:37:23 +0000

Disclosure up front: I work at ZoopCoder, an Indian web development agency. We sell website builds, so read this knowing what I sell. Every rupee figure below is either our own published price or clearly labelled as a market rate you should verify yourself.

Indian clients ask for a per-page rate constantly. "We need 12 pages, what's your rate per page?" It is a completely reasonable question and it has no useful answer, and I want to show the arithmetic rather than just assert that.

The same page count, three very different numbers

Here is an 8-page site, built three ways, at our published prices:

Build	Price (INR)	Per page
8-page brochure site (static content, contact form)	25,000 – 50,000	3,100 – 6,250
8-page WordPress/CMS (client edits content)	35,000 – 75,000	4,400 – 9,400
8-screen custom web app (user logins)	1,00,000+	12,500+

Identical page count. Roughly a 4x spread on the per-page number. A rate quoted before anyone knows what the pages do is going to be wrong in one direction or the other — and in my experience it is usually wrong in the direction that ends in an awkward conversation three weeks in.

The cliff is not pages. It is state.

The reason the per-page frame breaks is that it measures the wrong unit.

A brochure page is a pure function of nothing. Same bytes for every visitor. You can cache it at the edge forever and the server never thinks. Adding the 9th, 10th and 20th brochure page is close to linear and genuinely cheap — a few thousand rupees each, mostly content and layout work.

The moment you add a login, every page becomes a function of who is asking. And that one change drags in a pile of work that is invisible on every wireframe:

accounts, sessions, password reset, email verification
authorization — not "is this user logged in" but "is this user allowed to see this specific record"
a database of user-owned data, with migrations
the negative case: never leaking user A's data to user B
and the tests for all of the above, because this is the layer where a bug is a breach, not a typo

None of that shows up as a page. None of it is design. All of it has to be built, and more importantly, tested. That is where the money between 75,000 and 1,00,000+ actually goes.

So the price cliff in the Indian market sits right about there — and it is a cliff of statefulness, not of page count. This is why "we'll just add a small login area" is the single most expensive sentence a client can say in a kickoff call. It is not a small addition. It is a different category of software.

The practical version, including the part that costs us money

If your site has no login, do not buy a web app. If nobody can name a single thing on the site that requires a user to sign in, you are buying a brochure site, and a brochure site in India costs 25,000 – 75,000 depending on whether you want to edit the content yourself. We see people quoted 1,50,000+ for exactly this. If that is your project, you do not need us at that price — and honestly you may not need an agency at all.

If your site does have logins, be suspicious of a 40,000 quote. Either the scope has not been understood and the number will move, or someone is going to skip the authorization work, which is the part you cannot see and cannot easily check on delivery.

The costs the per-page number hides entirely

Whatever you build, the build price is not the annual price:

Item	Cost
Domain	800 – 1,500 / year
Hosting (most business sites)	3,000 – 15,000 / year
Maintenance plan (optional)	3,000 – 15,000 / month

That last row is genuinely optional and I want to be clear about it, because we sell those plans. A small brochure site that nobody logs into often does not need a monthly plan at all. A stateful app with user data and a payment flow does — not for the "content updates" bullet, but because dependency and security patches on a system holding user records are not something you skip.

Full by-type cost breakdown, with the tables: https://zoopcoder.com/website-development-cost-in-india.php

If you price web work in India differently — particularly if you have found a per-page model that holds up on stateful builds — I would genuinely like to hear it, because I have not.

Shopify Payments doesn't operate in India - here's what that actually costs you

Preciousky — Sat, 18 Jul 2026 10:36:26 +0000

Disclosure: I work at ZoopCoder, an Indian development agency that builds e-commerce stores. So I sell the thing this post is about. Every number below is either our own published price or a third-party rate you can verify yourself, and I have flagged which is which. There is a section near the end on when you should not build a store at all.

If you are picking a platform for an Indian store and you have been reading cost comparisons written for a US audience, one line item is missing from all of them, and it is large enough to change the answer.

Shopify Payments does not operate in India

Shopify has its own in-house payment processor, Shopify Payments. In markets where it operates, using it means Shopify charges you no transaction fee — you pay the card rate and nothing else.

It is not available in India. So an Indian merchant has to connect a third-party gateway — Razorpay, PayU, Cashfree. And when you process through a third-party gateway, Shopify charges an additional transaction fee on every order:

Shopify plan	Third-party gateway fee
Basic	2%
Grow	1%
Advanced	0.6%

That is on top of what your gateway already charges. A standard Razorpay account is about 2% on domestic cards. So:

An Indian store on Shopify Basic can pay roughly 4% on a card order, where a merchant in a Shopify Payments country pays about 2%.

Scale that. On ₹50,00,000 of annual sales, the extra 2% is ₹1,00,000 a year — which is more than the cost of building the store in the first place (a standard store is ₹40,000–₹90,000; that is ZoopCoder's published price).

(Shopify's India plan prices and Razorpay's rates are third-party figures, checked July 2026. They move. Verify before you plan around them.)

The crossover, with the working shown

The usual framing is "Shopify costs money, WooCommerce is free." That is not the comparison. The platforms bill you in different currencies: Shopify takes a fixed subscription plus a percentage of sales; WooCommerce takes ₹0 for software but requires hosting and continuous security maintenance, which is priced in labour.

So Shopify's cost grows with revenue and WooCommerce's stays roughly flat. The lines cross.

Annual online sales	Shopify	WooCommerce	Cheaper
₹5,00,000	~₹31,200 (Basic ₹21,200 + 2% fee ₹10,000)	~₹42,000 (hosting ₹6,000 + ₹3,000/mo plan)	Shopify
₹15,00,000	~₹51,200 (Basic ₹21,200 + 2% fee ₹30,000)	~₹48,000 (hosting ₹12,000 + ₹3,000/mo plan)	WooCommerce, just
₹50,00,000	~₹1,21,200 (Basic ₹21,200 + 2% fee ₹1,00,000)	~₹1,21,000 (hosting ₹25,000 + ₹8,000/mo plan)	A dead heat
₹1,00,00,000	~₹1,79,300 (Grow ₹79,300 + 1% fee ₹1,00,000)	~₹1,36,000 (hosting ₹40,000 + ₹8,000/mo plan)	WooCommerce

You can derive the crossover directly. Shopify Basic is ₹21,200 a year including GST, plus 2% of sales. A ₹4,000/month WooCommerce arrangement is ₹48,000 flat. Set them equal:

21,200 + 0.02S = 48,000
0.02S          = 26,800
S              = 13,40,000

Below about ₹13.4 lakh a year, Shopify is cheaper. Above it, WooCommerce is — assuming you pay somebody to maintain the WooCommerce store rather than doing it yourself. If you genuinely do your own updates and backups, WooCommerce wins everywhere and this whole table collapses. Be honest with yourself about which of those you are, because an unmaintained WooCommerce store is a security incident on a timer.

A second crossover nobody publishes

The instinct when the 2% fee starts to sting is to upgrade to Grow to get it down to 1%. Check the arithmetic first.

Grow costs roughly ₹58,000/year more than Basic and saves you 1% of sales. Upgrading pays for itself only when 1% of sales exceeds ₹58,000 — that is ₹58,00,000 in annual sales.

Below that, staying on Basic and paying the higher percentage is cheaper. The plan comparison page will not frame it that way.

The UPI thing everybody gets wrong

"UPI has zero MDR" is true and is constantly misread.

Zero MDR is a regulatory cap on the merchant discount rate — the interchange the banks would take. That genuinely is nil.

Your payment gateway is a separate business. It charges a platform/technology fee for the dashboard, reconciliation, refunds and settlement — commonly around 2%, plus 18% GST on the fee itself.

Zero MDR means the bank takes nothing. It does not mean your gateway takes nothing. If you have a low-margin catalogue and you modelled UPI orders as free, your unit economics are wrong. Read your gateway's pricing page for the specific line item.

While we are here, the full picture:

Payment method	Typical merchant cost	What people get wrong
UPI	MDR zero by regulation; gateway platform fee commonly ~2% + 18% GST on the fee	Zero MDR means the bank takes nothing
Domestic cards	~2% on a standard Razorpay-type account	Rates are negotiable at volume — ask once you are past a few lakh a month
Netbanking	Similar to cards, bank-dependent	Success rates vary by bank far more than the fee does; a failed payment costs the whole order
International cards	Roughly double domestic	Do not model foreign sales at the domestic rate
Cash on delivery	No gateway fee, but COD handling + full two-way shipping on every refusal	The most expensive method in this table, and it looks like the cheapest

The costs that are not the platform

Platform choice is the argument everybody has. It is rarely the biggest number. What actually shows up:

Product photography — ₹150–₹800 per product. Avoidable only if you shoot it yourself, and it will look like you shot it yourself.
Catalogue data entry — descriptions, variants, weights, HSN codes. Several days per few hundred SKUs. Not avoidable. Someone does it: you, or someone you pay.
Paid apps and plugins — ₹1,000–₹10,000/month if you install them. Entirely avoidable. Install nothing until a real problem demands it.
Returns and RTO on COD — two-way shipping plus packaging on every refused order. Reducible with partial-prepaid, not avoidable.
Domain + SSL — ₹800–₹1,500/year. Never pay for a basic SSL certificate; Let's Encrypt is free and fine.

When you should not build a store

I said I'd get here. We build e-commerce stores for a living, so weigh this accordingly — but these are real:

You have fewer than about ten SKUs and no repeat customers. A WhatsApp catalogue and a payment link will outperform a store, at roughly zero cost.
You have not sold the product anywhere yet. Sell thirty units through Instagram DMs first. If you cannot sell thirty by hand, a checkout page is not the constraint.
Your margin cannot absorb ~2% plus shipping plus returns. Some catalogues genuinely cannot. Find that out on a spreadsheet, not after the build.
Your volume is already almost entirely on Amazon or Flipkart and you are happy. A own-brand store is a marketing project, not a technical one; the site is the easy part.
Nobody will own the catalogue. A store with stale stock and wrong prices is worse than no store.

Summary

Shopify Payments does not operate in India, so Indian merchants pay Shopify an extra 2%/1%/0.6% (Basic/Grow/Advanced) on top of the gateway's ~2%.
Around ₹13.4 lakh in annual sales, WooCommerce becomes cheaper than Shopify Basic — if you are paying someone to maintain it.
Upgrading Basic → Grow does not pay for itself until about ₹58 lakh in annual sales.
Zero MDR on UPI caps the bank's cut, not your gateway's.
Build cost in India: ₹40,000–₹2,50,000 for the overwhelming majority of stores. Running cost: ₹31,000–₹1,36,000/year excluding gateway percentages.

Full breakdown with the build-price bands by store type, the timelines, and the FAQ: How much does an e-commerce website cost in India? (2026)

Our published price list, if you want to check the numbers I quoted for our own work: zoopcoder.com/pricing.php

Your website mostly keeps working. Your app decays on someone else's calendar.

Preciousky — Fri, 17 Jul 2026 10:42:49 +0000

Disclosure: I work with ZoopCoder, an Indian development agency that sells maintenance plans. So take the sales-shaped parts with appropriate salt — but every number below is published, checkable, and I've included the cases where you should buy nothing at all.

There's an asymmetry in maintenance that almost no quote explains, and it catches technical founders as often as non-technical ones:

A website left alone mostly keeps working. An app left alone stops being installable.

Same neglect, completely different outcome. Nothing in your code changed in either case. The difference is whose calendar the decay runs on — and once you see it that way, "do I need a maintenance plan?" stops being one question and becomes two.

The website case: decay is mostly optional

A static brochure site — no logins, no payments, no database, no plugins — has almost nothing to rot. Renew the domain, keep hosting paid, and it will serve the same HTML in 2028 that it serves today. Let's Encrypt renews the certificate itself.

So the honest floor for keeping a small site alive in India is not a monthly retainer. It's this:

Item	Typical cost per year (India, 2026)	Actually required?
Domain renewal (.com / .in)	₹800 – ₹1,500	Yes, always
Shared hosting	₹2,000 – ₹6,000	Enough for a brochure or small WordPress site
VPS / cloud hosting	₹6,000 – ₹30,000	Only for custom apps, real traffic, or live orders
SSL certificate	₹0	Free via Let's Encrypt. Never pay for a basic cert
Business email	₹0 – ₹2,000 / user	Optional
Floor — small business site	₹3,000 – ₹8,000 / year	Domain + shared hosting. That's the whole bill
Floor — custom app on a VPS	₹7,000 – ₹32,000 / year	Domain + a real server

₹3,000–₹8,000 per year is the floor. Compare that to a maintenance plan at ₹3,000–₹15,000+ per month and you can see why the distinction matters: those two numbers differ by more than an order of magnitude, and plenty of quotes blur them together deliberately.

The moment the site has moving parts, the maths flips hard. A WordPress or WooCommerce install is a live security exposure — an unpatched one is the single most common way Indian small-business sites get defaced, and cleaning up one hack costs more than a year of a basic plan. But that's a conditional cost driven by what you built, not an inevitability.

The app case: decay runs on Google's and Apple's calendar

Apps carry two costs websites don't, and one of them has teeth:

Cost	Amount	What happens if you stop paying
Google Play Console	$25 one-time (~₹2,200)	Nothing. There is no renewal — pay once, ever
Apple Developer Program	$99 per year (~₹8,700)	Your app is removed from the App Store

(Rupee figures are approximate and move with the exchange rate — the fees themselves are set in USD. Verify current fees with Google and Apple directly.)

But the fees aren't the interesting part. This is:

Google and Apple raise their minimum SDK, privacy and permission requirements on their own schedule, not yours.

An app left untouched for two years will eventually fail a store requirement and stop being installable — even though nothing about it broke, no dependency rotted, and you changed nothing. You didn't incur technical debt. The platform moved the floor underneath a binary that was, by every local measure, fine.

That's a genuinely different failure mode from "the code got old", and it's why "it's finished, we can stop paying" is a reasonable thing to say about a brochure site and a dangerous thing to say about an app. The website's clock is yours. The app's clock belongs to two companies in California who have never heard of you.

What plans actually cost, and where they sit in the Indian market

These are our published plans, not an illustrative example:

Plan	Per month	Year one (11 mo)	Right for
Post-launch support	₹0 (first 30 days)	—	Included with every project
Basic	₹3,000	₹33,000	Brochure sites, small WordPress sites
Professional	₹8,000	₹88,000	E-commerce, lead-gen, anything with live orders
Enterprise	₹15,000+	₹1,65,000+	SaaS, CRM, ERP, business-critical platforms

Year one multiplies by 11, not 12, because the first 30 days post-launch are included — you're not paying a retainer during the month you're most likely to need one.

Add the floor to the plan and you get the real number: a small WordPress site on Basic is about ₹39,000 in year one (₹33,000 + ~₹6,000 renewals) and ~₹42,000/year after. A busy store on Professional is about ₹95,000 in year one. A SaaS on Enterprise starts near ₹1,90,000/year. Those are the numbers to budget — not the plan price alone.

For market context: published Indian agency rates in 2026 run ~₹1,500/month for a basic site to ₹50,000+/month for enterprise platforms, with e-commerce typically ₹10,000–₹20,000/month. Our Professional tier at ₹8,000 sits below that band. I'd rather say that plainly than pretend we're the cheapest at every tier — we aren't, and the Enterprise "+" is real, because scope sets the number and an SLA costs what it costs.

The percentage trap, briefly

Many Indian agencies quote an AMC as 15–20% of build cost per year. It sounds principled. It's the wrong shape.

Maintenance effort is driven by how often the thing changes, how much custom code it carries, and how much traffic and risk it handles. Your build price is none of those — it's a number from the past. So it fails in both directions:

Scenario	Build cost	AMC at 18%	What the work is worth	Result
Expensive site, barely changes	₹5,00,000	₹90,000/yr	Renewals + a few hours	You overpay, forever
Cheap build, became a busy store	₹40,000	₹7,200/yr	Live orders, monitoring, fast response	You're underserved, and won't be told

Row two is the dangerous one. ₹7,200/year is ₹600/month. Nobody monitors a live store for ₹600 a month. What you bought is the word maintenance, and you'll discover what it didn't include on the day something breaks.

When to buy nothing

We sell these plans, so hold me to this: a maintenance plan is a service you choose to buy, not a bill you automatically owe. Skip it if all of these hold:

The site is static — no logins, no payments, no database, no plugins.
It changes fewer than three or four times a year, and only text and images.
No revenue depends on it being up this hour.
Someone can email a developer when it breaks.

In that case: renew domain and hosting for ₹3,000–₹8,000/year and buy ad-hoc hours when you need them. Four small changes a year bought as hours will almost always beat ₹36,000 of retainer.

Buy the plan if it runs a plugin ecosystem, takes payments, stores customer data, carries leads or orders, or is something people log into to do their job. The dividing line isn't the size of your business or what you paid to build the thing — it's whether it has moving parts, and whether money flows through it. And if it's an app, remember the clock isn't yours.

The one clause that matters more than the price

Make sure you own the code, the domain and the hosting account. If you can leave, a maintenance plan is a service you're choosing. If you can't, it isn't a plan — it's rent on something you already bought. Check which one you're being offered before you compare prices, because that single fact determines whether the price means anything at all.

Full breakdown with the year-one arithmetic, the renewal floor and the market comparison: How much does website maintenance cost in India? · Plans are published at zoopcoder.com/pricing.php.

The build is not the bill: what a SaaS MVP actually costs in year one (India, 2026)

Preciousky — Thu, 16 Jul 2026 11:48:47 +0000

Every SaaS cost estimate I read quotes one number: the build. ₹1,50,000 to ₹5,00,000 for an MVP in India, 10 to 24 weeks, thanks for reading.

That number is real. It is also not the bill.

A website is a one-time purchase that then sits there. A SaaS is a running process with a monthly invoice attached, and the gap between those two facts is where first products die. Not in the build. In month four, when the card on the hosting account declines.

Here is the year-one arithmetic, in actual rupees, for a small Indian SaaS.

What year one costs on top of the build

Running cost	Typical year one	What actually drives it
Cloud hosting	₹18,000 – ₹96,000	₹1,500–₹8,000/month. An early SaaS rarely needs more than one small server plus a managed database
Domain + SSL	₹1,000 – ₹3,000	Domain renewal. SSL is free via Let's Encrypt — never pay for a basic cert
Transactional email / SMS	₹6,000 – ₹36,000	₹500–₹3,000/month. Signup, reset, invoices. Scales with users, not features
Maintenance & updates	₹33,000 – ₹1,65,000	₹3,000–₹15,000/month × 11
Payment gateway	~2% of revenue	Not fixed — you only pay when a customer pays you
Year-one total (excl. gateway)	₹58,000 – ₹3,00,000	On top of the ₹1,50,000–₹5,00,000 build

Run it honestly and the headline changes:

A lean ₹1,50,000 MVP is really about ₹2,10,000 in year one.
A ₹5,00,000 build on a full maintenance plan is closer to ₹8,00,000.

If your entire budget is the build number, you have funded a launch, not a product.

Why the infra line is not optional the way founders think it is

The instinct is to treat hosting as the thing you cut. It is the smallest line on the table and the one that looks most like someone else's markup. But it is the only line that is load-bearing for the thing you actually sold: uptime.

A brochure site being down for an hour is embarrassing. A SaaS being down for an hour loses customers permanently, because the customer's work stopped. That asymmetry is the entire reason a SaaS costs more than a website with the same screen count, and it shows up everywhere in the codebase:

Accounts, roles, permissions. Signup, login, reset, sessions, and rules about who may see what. Every rule is a thing to build and a thing to test.
Data isolation between tenants. Customer A must never see customer B's rows. This shapes your schema on day one and it is the one bug you genuinely cannot ship.
Subscriptions and billing. Recurring payments, failed cards, upgrades, refunds, GST invoices. Billing is a product in its own right, and it is where "two more weeks" comes from.
An admin console. You will need to fix customer accounts by hand in month one. It is a second application, and it is why scope quietly doubles.
Uptime and backups. See above.

None of that is visible to the user. All of it is why the number is what it is.

Where the build calendar actually goes

Same split as any medium project: roughly 10% discovery, 20% design, 45% development, 15% testing, 10% deployment.

Only about 45% of what you pay for is someone writing product code. That is not padding — it is the reason fixing scope early saves more money than any negotiation over the hourly rate ever will. You cannot rate-negotiate your way out of a discovery phase you skipped.

The five things to cut, with numbers

The fastest way to bring a ₹4,00,000 quote to ₹2,00,000 is not a cheaper developer. It is deleting the things that do not answer the only question an MVP exists to answer: will anyone pay for this?

Feature	Verdict	Roughly what it adds	Do this instead
Mobile app alongside web	Cut	₹50,000 – ₹1,50,000	A responsive web app reaches every user on day one
Custom analytics dashboard	Cut	₹40,000 – ₹1,00,000	CSV export + a spreadsheet answers the same questions at ten users
SSO / SAML	Cut	₹30,000 – ₹80,000	Email + Google login. Build SSO when an enterprise buyer asks and pays
Multiple pricing tiers	Cut	₹30,000 – ₹70,000	Launch with one price. You don't yet know what anyone will pay
Public API	Cut	₹40,000 – ₹1,00,000	Nobody integrates with a product that has no users

Cut all five and a mid-band quote drops by roughly ₹1,90,000 to ₹5,00,000 of scope. Not one of them makes the product more likely to find a paying customer. Every one of them can ship in phase two, with revenue, once you know which ones customers actually ask for.

The uncomfortable part

Some of you should not build this yet. Specifically, if:

You haven't spoken to ten potential users. Not friends — people with the problem and a budget. Costs ₹0 and a fortnight, and it changes the scope of most products.
A spreadsheet and an existing tool could fake it. Run the workflow manually for three to five paying customers first. If they won't pay for it done by hand, they won't pay for it automated. If they will, you now have revenue, real requirements, and a cheaper build.
You need revenue within three months. An MVP takes 10–24 weeks. The arithmetic does not work, and anyone who tells you otherwise is not being straight with you.
A no-code prototype could prove the workflow. Bubble, Glide or an Airtable flow can validate a single workflow for ₹0–₹30,000. They won't scale — that's fine, that isn't the job yet.

Writing the code is the fun part. It is also the part you should be most willing to postpone.

Disclosure: I work with ZoopCoder, an Indian dev agency, so treat the "when not to build" section knowing we'd be turning down that work. The ₹ bands above are our published prices, not an estimate — hosting/email/gateway figures are typical Indian market rates you should verify with each vendor. Full breakdown with the scope tiers and year-one table: How much does a SaaS MVP cost in India?

Why software build timelines slip in India (and coding is only ~45% of the calendar)

Preciousky — Wed, 15 Jul 2026 14:16:57 +0000

The uncomfortable truth about build timelines: coding is ~45% of the calendar

Every time someone asks "how long will it take to build this app?", the answer they expect is a coding estimate. But if you have shipped a few products, you know the calendar is dominated by everything around the code. Here is the breakdown we actually see on India-based builds, and why the estimate you were given keeps slipping.

The headline numbers (once the team is building)

Project type	Realistic timeline
Landing page	5-10 days
Business website	2-3 weeks
Ecommerce site	3-8 weeks
Simple app (few screens, 1-2 integrations)	4-6 weeks
Mid-complexity app (accounts, payments, admin)	8-16 weeks
SaaS MVP	10-24 weeks
Complex platform / marketplace	4-7 months

These assume a competent team is already onboarded. The "hire" and "spec" time sits before this clock starts.

Where the calendar actually goes

This is the part that surprises non-technical stakeholders. For a typical app, the phase split looks like:

Phase	Share of calendar
Discovery & specs	~10%
UI/UX design	~20%
Development (the "coding")	~45%
Testing & bug-fixing	~15%
Deployment & store review	~10%

Coding is under half the timeline. So when a vendor promises "your app in 3 weeks", the honest question is: which of these phases are you dropping? It is almost always testing — and you pay that debt back with interest in month two.

The real reason projects run late (it is not the developers)

In my experience the single biggest source of slippage on Indian projects is scope creep and slow client approvals, not slow engineering. Mid-build feature changes and multi-day sign-off delays on designs routinely add 2-8 weeks. That clock lives entirely on the client's side.

Things engineers can predict but clients rarely budget for:

Native iOS + Android in parallel is materially slower than one Flutter / React Native codebase.
App Store / Play review adds anywhere from a few days to a couple of weeks, and it is out of your hands.
India-specific integrations — Razorpay/PayU, Aadhaar/DigiLocker KYC, GST invoicing — tend to need extra compliance rounds that never show up in the naive estimate.

How to actually hit the estimate

Freeze scope before development starts. A locked spec is worth more than an extra developer.
Assign one decision-maker on the client side who can approve designs within a day.
Keep testing in the plan. If it is not a line item, it is not happening.
Sequence, don't parallelize blindly — a shared codebase beats two native teams for most products pre-scale.

Disclosure: I work with ZoopCoder, an India-based development agency, so treat the agency framing accordingly — I have tried to keep the phase math and timelines honest and vendor-neutral. We published the full version of this, with the timeline-and-price table by project type and a ranked list of what causes delays, here: How Long Does It Take to Build an App or Website in India?

The 30-40% cross-platform saving, in actual rupees (India, 2026)

Preciousky — Tue, 14 Jul 2026 10:52:48 +0000

Disclosure up front: I work at ZoopCoder, an Indian dev studio. The rupee figures below are the ones we publish on our own pricing page, shown next to the wider market band — including the tiers cheaper than us.

"Cross-platform saves you 30–40%" is repeated so often that it has stopped meaning anything. I want to put actual numbers under it, from the Indian market in 2026, and then argue about where the saving really comes from — because it is not where most people think.

The numbers first

Relative build cost, same app, same scope:

Approach	Relative cost	Choose it when
Flutter (one codebase)	Baseline — 100%	Most business, commerce, booking and content apps
React Native (one codebase)	~100%	You already have a React web team and want to share skills
Android native only	70–80%	India-only audience (Android ≈ 95% of the market here)
Native Android and native iOS	150–180%	Heavy hardware use, background processing, platform-specific features

In rupees, for a medium-complexity app (logins, payments, admin panel, two user roles), the cross-platform build lands at ₹1,00,000–₹2,50,000 at a small Indian agency, on an 8–14 week timeline. The two-native-codebases version of that same app is the 150–180% row.

Where the saving actually comes from

It is not mostly the UI layer. That is the intuition — "one widget tree instead of two" — and it is the smaller half.

The bigger half is everything that silently doubles when you have two codebases:

Test suites. Two of them. Every business rule asserted twice.
CI pipelines. Two build matrices, two signing setups, two flake surfaces.
Release trains. Two store submissions, two review rejections to argue with, two rollback plans.
Bug triage. Every bug now has a "does it repro on the other platform?" step before you can even file it.
OS updates. Android and iOS each ship a major version annually. Two codebases means you pay that tax twice, every year, forever.

That last point is why I think the 150–180% number understates native's true cost. The 150–180% is the build. The maintenance delta never ends — and in India that shows up as ₹5,000–₹30,000/month of maintenance that quietly becomes two streams instead of one.

When native is still the right call

I am not arguing Flutter always wins. Pay for native when the app's core value depends on the platform:

Heavy device hardware (camera pipelines, sensors, Bluetooth peripherals)
Serious background processing
Platform-specific features you'd otherwise be fighting a plugin to reach

If you are writing a business, commerce, booking or content app, though, you are usually paying the native premium for nothing — and paying it again every year.

The costs the framework choice doesn't change

Whatever you pick, these don't move, and they're the ones that catch first-time app owners:

Google Play Console: $25, one-time
Apple Developer Program: $99/year — stop paying and the app is delisted
Backend hosting: ₹3,000–₹25,000/month, scaling with active users
Maintenance: ₹5,000–₹30,000/month — an unmaintained app breaks in roughly 12–18 months

Budget for these on day one, or you have built something with an expiry date and not noticed.

Full breakdown — cost by complexity, by app type (brochure → fintech), vendor rate bands from freelancer to enterprise, and timelines: https://zoopcoder.com/guides/mobile-app-development-cost-in-india.php

If you think the 150–180% figure is wrong for your stack, I'd genuinely like to hear it — that number is the one I'm least certain generalises.