DEV Community: Preciousky

What a Shopify store really costs in India in 2026 — including the fee only Indian sellers pay

Preciousky — Tue, 15 Sep 2026 05:31:16 +0000

Disclosure: I work at ZoopCoder, an Indian dev shop, and we sell a paid fixed-price Shopify setup. Every Shopify number below is Shopify's own published India price and is billed by Shopify, not by us — none of it reaches us. The one paid thing we sell is flagged clearly at the end. Verify the rates on Shopify's site before you plan around them; they move.

Every "how much does Shopify cost" article you will find is written for a merchant in the US, the UK or Australia. For an Indian seller, all of them are wrong in the same specific way, and it is not the subscription price.

Here is the actual arithmetic for India as at September 2026.

1. The subscription (Shopify's own India price list)

From shopify.com/in/pricing:

Plan	Pay monthly	Pay yearly
Basic	₹1,994/mo	₹1,499/mo
Grow	₹7,447/mo	₹5,599/mo
Advanced	₹30,164/mo	₹22,680/mo
Plus	from ₹1,75,000/mo	—

And, verbatim from the same page's FAQ: "There are no setup fees on any of our plans."

So the headline is ₹1,994 a month, or ₹17,988 a year if you commit annually. That is the number everyone quotes. It is also the number that matters least.

2. The thing that is different in India: Shopify Payments doesn't operate here

Shopify publishes a list of supported countries for Shopify Payments. As I write this it runs from Australia and Austria through to the UAE, the UK and the US — 40-odd countries.

India is not on it.

That has one direct consequence, which Shopify also states plainly in its pricing FAQ:

Third-party transaction fees may apply when you use a third-party payment provider (instead of Shopify Payments). The rate depends on your plan.

Put those two facts together and you get the India-specific outcome: every Indian Shopify store must use a third-party gateway — Razorpay, PayU, Cashfree, PhonePe — which means every Indian Shopify store pays Shopify's third-party transaction fee on every order. There is no configuration that avoids it, because the thing that would avoid it isn't available here.

A merchant in a supported country can switch that fee off by turning Shopify Payments on. You cannot. That is the asymmetry nobody's cost comparison mentions.

3. And then there's GST on the gateway fee

Second India-only line item, and an easy one to under-budget. A standard Razorpay/PayU/Cashfree account is around 2% per transaction on domestic cards — and 18% GST is charged on that fee, which makes the real rate about 2.36%.

On ₹50,00,000 of annual sales that's ₹1,18,000, not ₹1,00,000. An ₹18,000/year line that appears in exactly zero comparison tables published outside India.

One more, if you are GST-registered: Shopify bills its subscription from outside India, so the reverse charge mechanism applies — you pay the GST to the government yourself and claim it back. Net zero if you are registered, a real 18% if you are not. Ask your CA, not a blog post, about your own position.

4. So what does it actually cost to run?

Stack the three layers for a Basic-plan store:

Subscription: ₹1,994/mo (₹1,499/mo yearly)
Shopify's third-party transaction fee: a percentage of every order, unavoidable in India, rate depends on plan
Gateway + GST: ~2.36% of every order

The first number is fixed. The other two scale with your revenue — and that is the whole decision, because WooCommerce's cost structure is the opposite shape: nothing for the software, everything in hosting and maintenance labour, which stays roughly flat as sales grow.

Two lines with different slopes cross somewhere. We did that arithmetic at four revenue levels for the Indian market — including where the crossover actually sits and the case for not building a store at all below a certain volume — in what an e-commerce website costs in India.

The short version of that guide, so you don't have to click:

Under ~₹2 lakh/year in online sales: don't build a store. A WhatsApp Business catalogue and a payment link take an afternoon and cost nothing but the transaction fee.
~₹2 lakh to ~₹13 lakh/year: Shopify. The subscription plus its cut is cheaper than paying somebody in India to keep WooCommerce patched, and it is dramatically less work.
Above ~₹13 lakh/year: the lines cross and WooCommerce starts winning, because Shopify's percentage keeps climbing with your revenue and maintenance labour doesn't.

That recommendation sends most small sellers away from the larger project, which is the opposite of what an agency blog usually does. It is also just what the maths says.

5. What setup actually involves

A blank Shopify store does not sell. What it needs before it can take a rupee:

A theme customised enough not to look like a demo (free themes are fine; the licence for a paid one is yours to buy)
Products with real variants and collections, not a flat list
A gateway connected and KYC-approved — this is usually the long pole, not the design
Shipping zones, rates and COD, which in India is still a large share of orders
GST tax settings
Refund, privacy, shipping and terms pages — gateways ask for these during approval, and a missing shipping policy is a very common reason an Indian gateway application stalls
A real end-to-end test order before you announce anything

None of that is hard. All of it is fiddly, and the gateway approval step has a queue you don't control.

If you'd rather not, ZoopCoder does it as a fixed price: Shopify store setup — ₹14,999, 7-10 working days, up to 30 products, gateway connected, COD, shipping, GST, domain, policy pages and a live test order before handover. The Shopify plan stays on your own account and your own card — we work as staff on your store and that access can be removed the day we hand over.

The one-line summary

Shopify in India is ₹1,994/month plus a percentage you cannot switch off, because Shopify Payments doesn't operate here. Budget the percentage, not the subscription. Below about ₹13 lakh a year in sales, it's still the right platform for most sellers — it's just not as cheap as the international articles make it look.

Google Play's API 36 deadline has passed — what actually breaks when you upgrade

Preciousky — Tue, 15 Sep 2026 05:29:30 +0000

Disclosure: I work at ZoopCoder, an Indian dev shop, and we sell a paid fixed-price version of this upgrade. Everything below is from Google's own published documentation and is linked so you can check it. There are no fees in this post paid to us except the one clearly marked at the end — treat this as a commercially interested source and verify the dates yourself.

If you have an Android app in production and you have not shipped an update since August, there is a decent chance Play Console will refuse your next upload with this:

Your app must target Android 16 (API level 36) or higher.

That is not a bug and it is not your build tooling. It is Google Play's annual target API level requirement, and this year's step took effect on 31 August 2026.

Here is exactly what the rule says, what it blocks, how much time you have left, and — the part most posts skip — what actually breaks when you raise the number.

The rule, in Google's words

From Meet Google Play's target API level requirement:

Starting August 31 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play; except for Wear OS and Android Automotive OS apps, which must target Android 15 (API level 35) or higher, and Android TV and Android XR apps, which must target Android 14 (API level 34) or higher.

So:

Form factor	Minimum target API level
Phones / tablets / foldables	36 (Android 16)
Wear OS	35 (Android 15)
Android Automotive OS	35 (Android 15)
Android TV	34 (Android 14)
Android XR	34 (Android 14)

Two things people get wrong about this:

It applies to updates, not just new apps. A five-year-old app with a million installs cannot ship a one-line crash fix until its targetSdk goes to 36. The block is on the upload itself, in Play Console, before review.
There is a second, softer rule for apps you never touch again. Existing apps must target API 35 or higher "to remain available to new users on devices running Android OS higher than your app's target API level." An app left on API 34 doesn't vanish — it just quietly stops being installable by new users on current phones, which looks identical to your install rate dying for no reason.

The documented exception is narrow: "permanently private apps that are restricted to users in a specific organization and intended for internal distribution only."

You can buy time, once, until 1 November 2026

Also straight from that page:

If you need more time to update your app, you'll be able to request an extension to November 1, 2026. You'll be able to access your app's extension forms in Play Console later this year.

That is the whole reprieve. It is a one-off form inside Play Console, it moves your date to 1 November 2026, and it does not renew. If you are reading this and you're blocked, filing that is the first thing to do — then do the work, because the extension is not a plan.

What actually breaks (this is the real work)

Bumping targetSdk from 35 to 36 is one line. Everything after that line is the job. Four changes catch almost everybody, all documented in Behavior changes: Apps targeting Android 16:

1. The edge-to-edge opt-out is gone

Android 15 enforced edge-to-edge for apps targeting API 35, but you could escape with R.attr#windowOptOutEdgeToEdgeEnforcement = true. For apps targeting API 36, that attribute is deprecated and disabled on Android 16 devices — you cannot opt out any more.

Practical effect: your content now draws under the status bar and the navigation bar. Buttons end up under the gesture pill; headers end up under the clock. Nothing crashes, so CI stays green and the bug arrives via a screenshot from a user.

The fix is to apply window insets properly (Compose / Views) rather than to hunt for a new opt-out flag. There isn't one.

2. Predictive back is on by default — and `onBackPressed` is never called

This is the nastiest one, and it is the reason I am writing this post:

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back key at all, that interception silently stops running. The single most common casualty is the WebView wrapper pattern — the classic

@Override
public void onBackPressed() {
    if (webView.canGoBack()) webView.goBack();
    else super.onBackPressed();
}

— which is in a very large share of India's small-business apps. After the upgrade, back exits the app instead of going back a page, and it does so from the first screen the user ever presses back on.

Two options: migrate to the supported back navigation APIs, or set android:enableOnBackInvokedCallback="false" on <application> or the specific <activity> as a temporary opt-out while you migrate. Google's own wording for that flag is "temporarily opt out", and it is worth treating that word as load-bearing.

3. Orientation and aspect-ratio locks stop being honoured on big screens

For apps targeting Android 16 (API level 36), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp. Apps fill the entire display window, regardless of aspect ratio or a user's preferred orientation, and pillarboxing isn't used.

If you shipped screenOrientation="portrait" and assumed it would hold, it won't on a tablet, a foldable's inner screen, or desktop windowing. There is a per-activity manifest opt-out (PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY) and an application-level one, but the direction of travel is obvious and the escape hatches are explicitly transitional.

4. `elegantTextHeight` is deprecated and ignored — and this one is an India problem

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

Six of those ten scripts are Indian. If your app ships Tamil, Telugu, Kannada, Malayalam, Odia or Gujarati strings, your line heights move and tightly-packed layouts clip. Nobody in your QA group is going to catch that unless somebody is explicitly told to look at the regional-language build.

While you are in there: the 16 KB page size deadline

Different rule, same neighbourhood, and worth doing in the same sitting. From Support 16 KB page sizes:

To ensure your app works correctly on the latest versions of Android, all apps targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices on Google Play. Starting February 1, 2027, if your app updates don't support 16 KB memory page sizes, you won't be able to release these updates.

The good news, also from that page:

If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices.

So this only bites if you (or a dependency — think older video, ML, crypto, PDF or game SDKs) ship native .so files. Check your AAB's lib/arm64-v8a/ contents before you assume you're clear, because "a library I depend on has NDK code" is a much more common answer than "I wrote NDK code".

What this costs

Honest version: if it's a healthy modern project with maintained dependencies, this is a half-day for someone who has done it before, and you should just do it yourself using the links above. Nothing in this post is secret.

It gets expensive when the project is old: an unmaintained Gradle plugin, an AGP version that won't compile against API 36, a dependency that was abandoned three years ago, a Cordova shell. Then you are not doing a one-line bump, you are doing an archaeology project.

If you'd rather hand it over, ZoopCoder does this as a fixed-price job: target API 36 upgrade — ₹2,999, 2-4 working days, which covers the tooling update, the four behaviour changes above, a 16 KB check on native libraries, and a signed AAB. We quote separately (and say so up front) if the project turns out to need a rewrite rather than an upgrade — that is the honest failure mode of a fixed price on legacy code.

The wider point, which is worth more than the service: an Android app is not a thing you finish. Google and Apple move their requirements on their own calendar, not yours, and an app nobody touches for two years eventually fails a store requirement without anything about it having "broken". We put a yearly number on that in what website and app maintenance actually costs in India.

Do the extension form today if you're blocked. Then do the upgrade before 1 November.

WhatsApp Business Platform pricing in rupees — and the two things that change on 1 October 2026

Preciousky — Mon, 14 Sep 2026 22:31:50 +0000

Disclosure: I work on ZoopCoder, a small Indian dev shop that builds WhatsApp chatbots as a paid service. Every per-message rate below is Meta's, taken from Meta's own published rate card, and is billed by Meta directly to your WhatsApp Business account — none of it reaches us. The one paid thing we sell is at the end, clearly marked.

WhatsApp Business Platform pricing has changed twice in eighteen months and is about to change again in two weeks. Most of the "WhatsApp API pricing India" pages you will find are still describing the 2023 model. Here are the current numbers in rupees, straight off Meta's rate card, plus what actually lands on 1 October 2026.

Source for everything below: Meta's pricing documentation, last updated 10 September 2026, and the INR rate card CSV linked from it.

The model, in one paragraph

Until mid-2025 Meta charged per 24-hour conversation. Since 1 July 2025 it charges per template message delivered instead. You are charged when a template message is delivered; the rate depends on the template's category (marketing, utility, authentication) and the country calling code of the person receiving it. Free-form, non-template messages — the ordinary replies a bot or a human sends inside an open 24-hour customer service window — have not been charged since 1 November 2024.

That last sentence is the one with an expiry date on it. More below.

India rates today (effective 1 July 2026)

Per message delivered, in rupees, to an Indian (+91) number:

Template category	Rate per message	What it is
Marketing	₹0.8631	Promotions, offers, re-engagement, cart nudges
Utility	₹0.1150	Order confirmations, shipping updates, payment receipts
Authentication	₹0.1150	OTPs and login codes
Authentication-international	₹2.4971	Auth messages billed under the international rate
Service (free-form reply in an open 24h window)	not charged	…until 30 September 2026. See below

Two things jump out. Marketing is 7.5× the price of utility in India, and utility is so cheap — about eleven and a half paise — that order updates are effectively a rounding error. A store sending 2,000 shipping updates a month spends ₹230. A store blasting 5,000 marketing templates a month spends ₹4,315. Same channel, wildly different economics, and the difference is entirely which category your template is approved under.

What changes on 1 October 2026

Two changes, both of which make free things cost money.

1. Service messages start being charged. Those free-form replies inside an open 24-hour customer service window — everything a chatbot says back to a customer who messaged first — become chargeable at the same rate as utility and authentication in your market. In India that is ₹0.1150 per message.

There is a free tier, and it is per phone number, not per business: 1,000 service messages per business phone number per month, free. Meta only charges from the 1,001st service message delivered in a month. The allowance does not roll over — 1,000 in October, 1,000 in November, unused ones vanish. And note Meta's own warning: if you have no payment method on the account, your first 1,000 service messages each month still go out, but the 1,001st is simply not delivered. Add a payment method in Billing Hub before October if your volume is anywhere near the line.

2. Utility templates sent in reply to a user become chargeable again. Since 1 July 2025, a utility template delivered inside an open customer service window was free. From 1 October 2026 it is not.

India is not in Meta's list of markets whose marketing, utility or authentication rates change on 1 October 2026, so the ₹0.8631 / ₹0.1150 figures above should hold through the switchover. The new cost is the newly-chargeable categories, not a rate rise.

What that does to a real bill

Take a small Indian D2C store running a bot on one number. 2,000 people message in each month; the bot answers each with roughly three messages; the store also sends 2,000 shipping updates and one marketing blast to 5,000 opted-in contacts.

Line	Volume	Until 30 Sep 2026	From 1 Oct 2026
Bot replies (service messages)	6,000	₹0	(6,000 − 1,000 free) × ₹0.1150 = ₹575
Shipping updates (utility templates)	2,000	₹230	₹230
Marketing blast	5,000	₹4,315	₹4,315
Monthly total		₹4,545	₹5,120

So the October change costs this business ₹575 a month. Not existential — but it is the difference between "replies are free" and "replies are metered", and if you are running a high-volume support bot on one number, 50,000 service messages a month goes from ₹0 to about ₹5,635.

Three ways to keep the bill down

Let the customer start the conversation. A click-to-chat link, a WhatsApp button on your site, a QR code on the packaging. Replying inside an open window is ₹0.1150 a message and the first 1,000 are free; reaching out cold with a marketing template is ₹0.8631 every time.
Get the template category right. An order confirmation approved as marketing instead of utility costs you 7.5× for no reason. Write templates so they are unambiguously transactional, and challenge a miscategorisation rather than shrugging at it.
Watch the 1,000-message line per number. The free tier is per business phone number. If you genuinely run separate support and sales functions, separate numbers each get their own 1,000 — but do not split numbers purely to farm the allowance; you will pay for it in verification hassle and split chat history.

One thing worth saying about unofficial tools

There is a whole market of cheap "WhatsApp automation" tools that drive the consumer app rather than the Business Platform. They are cheaper because they are against WhatsApp's terms, and the failure mode is your business number getting banned with the chat history inside it. If WhatsApp is a real sales channel for you, the official API's per-message rupees-and-paise pricing is not the expensive option.

The paid option, stated plainly

ZoopCoder builds a chatbot on the official WhatsApp Business Platform — menus, up to 25 FAQ replies, lead capture into a Google Sheet, human handoff, up to 3 templates submitted for Meta approval — for a fixed ₹7,999, live in 7–10 working days, no monthly fee from us. It is here with the full scope. Meta's per-message charges above are yours and go to Meta; we do not mark them up and we do not resell them.

If you are costing a whole storefront rather than just the bot, the rest of the recurring lines are itemised in our e-commerce website cost guide for India.

Rates change quarterly. If you are reading this months from now, check Meta's rate card before quoting these numbers to anyone.

What it actually costs to publish an iPhone app on the App Store from India (2026 numbers)

Preciousky — Mon, 14 Sep 2026 22:30:51 +0000

Disclosure: I work on ZoopCoder, a small Indian dev shop that sells App Store submission as a paid fixed-price service. Every fee in this post is money paid to Apple, not to us, and I have linked Apple's own page for each one so you can check it. The single paid thing we sell is flagged at the very end — the rest of the post works fine if you ignore it.

Every few weeks someone asks me the same question in a slightly different form: "how much does it cost to put an app on the App Store?" The answers online are either American, or a year out of date, or quietly skip the part that actually costs money. So here are the 2026 numbers, in rupees, with sources.

1. The fee: US$99 a year, and the word year is the whole story

The Apple Developer Program is 99 USD per membership year, "in local currency where available" — so Apple bills you in rupees during enrolment. At ₹95.61 to the dollar (14 September 2026) that is about ₹9,500 a year.

Compare that to Google:

Store	What you pay	How often
Google Play	US$25 (about ₹2,400)	Once. Ever. One account, every app you ever ship
Apple App Store	US$99 (about ₹9,500)	Every year, for as long as you want the apps listed

That difference compounds. Three years on Google Play costs US$25. Three years on the App Store costs US$297.

And Apple's fee does not lapse quietly. When the membership expires, your apps are removed from the App Store. People who already installed the app keep their copy, but nobody new can download it and you cannot ship an update until you renew. If you are a solo dev with one free app and no revenue, budget that ₹9,500 as a permanent line, not a launch cost.

(Accredited educational institutions, government entities and qualifying non-profits can apply to Apple for a fee waiver. Most people reading this will not qualify.)

2. Individual or organization? Decide before you pay, not after

This one costs people days, and it is free to get right.

Individual enrolment needs your Apple Account with two-factor on, and a card. That is it. But your own legal name is shown as the seller on the App Store listing. For a personal project, fine. For anything you want to look like a company, not fine.

Organization enrolment shows your company name as the seller instead, and Apple requires rather more:

a D-U-N-S Number for the legal entity (free from Dun & Bradstreet, but requesting one takes days);
a legal entity that can contract with Apple — Apple explicitly does not accept DBAs, trade names or branches;
a work email on your organization's own domain — a Gmail address will not do;
a publicly working company website on that same domain. A domain-registrar parking page or a link to your Instagram gets rejected;
and the person enrolling must actually have authority to bind the company.

If you are an Indian private limited or LLP and do not yet have a D-U-N-S number, start that request first and do everything else while it processes. Switching from individual to organization later is a support ticket, not a checkbox.

3. Review takes a day. Rework takes a fortnight.

Apple's own number on the App Review page: "On average, 90% of submissions are reviewed in less than 24 hours."

That is genuinely fast — faster than Google Play's typical turnaround right now. The reason iOS launches feel slow is the other Apple statistic on that same page:

"On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness"

Guideline 2.1 is not a design judgement or a policy grey area. It is the boring stuff:

the app crashed on the reviewer's device;
placeholder content — lorem ipsum, a stock avatar, an empty tab — still in the build you submitted;
incomplete information: no demo account, so the reviewer hit your login screen and could not get past it;
broken links (a privacy policy URL that 404s will do it);
a screenshot showing an Android device, or UI that is not in the build.

Every one of those is checkable in twenty minutes before you submit. Each one you miss costs a full review cycle, and cycles are where the two weeks go.

The demo account is the single highest-value thing you can add. If your app has any sign-in at all, put a working username and password in the App Review notes, make sure the account has realistic data in it, and keep it alive until the app is approved. Reviewers do not sign up.

4. Guideline 4.2, and why website wrappers die on iOS

If your plan is "wrap our website in a WebView and ship it", read guideline 4.2 first. Apple says it plainly:

"Websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app."

Android will usually take that app. iOS will usually not. If you want the same web content on the App Store, it needs real native behaviour on top — push notifications, offline handling, native navigation, device features that a browser tab cannot offer. Plan that as build work, not as a conversion step.

5. The whole first-year bill, in rupees

For an Indian founder shipping one iPhone app, with a build that already exists:

What	Who charges it	Amount	How often
Apple Developer Program	Apple	US$99 (~₹9,500)	Every year
D-U-N-S number (org accounts)	Dun & Bradstreet	₹0	Once
Apple commission on in-app sales	Apple	15% under US$1M/yr revenue	Per sale
App Store submission, if you do it yourself	—	₹0 and a day or two of your time	Per app

Year one: about ₹9,500 plus your time. Year two onwards: about ₹9,500. There is no per-app charge and no submission fee — the recurring membership is the entire Apple bill until you start selling inside the app.

FX used throughout: ₹95.61 to the US dollar, 14 September 2026. Apple charges the rupee price shown at enrolment, which will not track the spot rate exactly.

6. When it is not worth it

Be honest with yourself about the ₹9,500 a year. If you are shipping a free app with no revenue model, no update plan and no users waiting for it, an iOS build is a subscription you will resent in month fourteen. Ship Android first — US$25, once, forever — see whether anyone wants the thing, and buy the Apple membership when there is a reason to.

7. The paid option, stated plainly

If you would rather not learn App Store Connect: ZoopCoder does the whole submission — app record, listing, App Privacy labels, age rating, export compliance, build upload, review notes and demo login — for a fixed ₹4,999, sent to Apple review in 2–3 working days. That is the service page, price and scope on it. The ₹4,999 is on top of Apple's US$99, not instead of it, and nobody outside Apple can promise you approval — treat anyone who does as a red flag.

If you are still costing the build itself, we keep an itemised breakdown at mobile app development cost in India, including the yearly fees both stores charge.

Corrections welcome — if Apple changes a number, tell me and I will fix the post.

What it actually costs to publish an Android app on Google Play from India (2026 numbers)

Preciousky — Mon, 14 Sep 2026 20:01:32 +0000

Disclosure: I work at ZoopCoder, an Indian development shop that sells a paid Play Store submission service. That price is at the bottom. Everything above it is the same thing I would tell you for free, and every fee in this post is paid to Google or Apple, not to us.

Someone asks "how much does it cost to publish an app on the Play Store" roughly every day. They get told "$25", they pay the $25, and then three weeks later they are still not live because of a rule nobody mentioned. Here are the real numbers as of September 2026, from doing this repeatedly for Indian clients.

1. The fee is US$25, once, and that is genuinely all of it

A Google Play developer account costs a one-time US$25 registration fee — about ₹2,400 on an Indian card at today's rate, plus whatever forex markup your bank adds. There is:

no annual renewal — you pay once and the account is yours;
no per-app charge — one account can hold as many apps as you want;
no charge to push updates.

This is the single biggest difference from Apple, which charges US$99 every year and delists your app if you stop paying. If you are choosing which platform to ship first on a tight budget, that asymmetry matters more than any development cost.

The one thing Google does take is a service fee of 15–30% on in-app purchases and subscriptions — 15% on the first US$1M of yearly earnings for most developers. If your app takes money for physical goods or services delivered outside the app, that fee does not apply.

2. The cost that is not money: the 14-day, 12-tester clock

This is the one that ruins launch dates.

If your developer account was registered as a personal account after 13 November 2023, Google will not give you production access until you have run a closed test with at least 12 testers who stay opted in continuously for 14 days.

Read that carefully, because each clause bites:

12 testers — real Google accounts that actually opt in. Not 12 email addresses you own.
14 continuous days — the clock starts when the test starts, not when you apply.
If testers drop below the threshold, the clock effectively restarts.

Organisation accounts (a registered company, D-U-N-S verified) are exempt from this entirely. If you are a registered company and you have a choice, register the developer account as the organisation on day one, not at the end of the project. It is free and it saves you two to three weeks.

Nobody can shorten this for you. Any service that offers to "provide testers" is offering you a policy violation — Google treats fake tester accounts as exactly that.

3. You cannot upload an APK, and you cannot target an old SDK

Two hard technical gates that catch people using app builders and free converters:

Requirement	Since	What it means
Android App Bundle (.aab)	August 2021 for new apps	A plain `.apk` will be rejected at upload.
Target API 36 (Android 16)	Current Play requirement	Building against an older `targetSdk` blocks the upload, not just new features.

If you exported your app from a free "website to app" tool, check both of these before you pay for anything else. A large share of those tools still emit an APK built against an older target API, and some do not let you supply your own signing key — which means you could never publish an update under your own account even if the first upload succeeded.

4. The five declarations that actually cause first rejections

The upload is the easy part. First submissions get bounced on paperwork far more often than on code:

Data safety form that does not match reality. You declare what the app collects and shares. If your app pulls the advertising ID or device identifiers through an SDK you forgot about, and the form says it collects nothing, that is a mismatch and a rejection.
Missing or unreachable privacy policy URL. It must be a live, public URL, on your own domain, reachable without a login.
Wrong target-audience answer. Answering "children" pulls in a whole extra set of Families policy requirements. Answering it carelessly is a policy problem, not a form problem.
App access credentials the reviewer cannot use. If any part of the app is behind a login, you must give a working demo account. Expired or 2FA-protected demo logins are a very common bounce.
Content rating questionnaire (IARC) answered inconsistently with what the app actually does.

None of these need a developer to fix. All of them need someone to actually read the app's behaviour instead of clicking through the form.

5. A realistic end-to-end budget (Indian solo founder, app already built)

Line item	Cost	Paid to	Frequency
Google Play developer account	US$25 (≈ ₹2,400)	Google	Once, forever
Privacy policy page	₹0 if you write it yourself	—	Once
Store listing copy + screenshots	₹0–₹5,000	Designer, or yourself	Once
Console submission work	₹0 if you do it yourself	—	Per app
Apple, if you also want iOS	US$99 (≈ ₹9,500)	Apple	Every year

So: an Android-only launch for an app that already exists can genuinely cost you one payment of about ₹2,400 and a fortnight of waiting. That is the honest answer, and it is why I think "how much does it cost to publish an app" is usually the wrong question — the expensive parts are the app and the fourteen days, not the fee.

6. Where we fit, since I said I'd be upfront

If you would rather not spend an evening inside Play Console:

ZoopCoder submits an app to Google Play for a fixed ₹1,999 — store listing, IARC content rating, Data safety form, target audience, app access declarations, the release itself, and the first round of Google's review feedback. Typically sent for review within 1–2 working days of getting the files. Details and scope: https://zoopcoder.com/services/play-store-app-publishing.php
If what you are publishing is an existing website, we build it into a signed, Play-ready AAB targeting API 36 for a fixed ₹4,999: https://zoopcoder.com/services/website-to-android-app.php

The US$25 is still yours to pay to Google, the app is published under your account, and nobody — us included — can guarantee that Google approves it. Anyone who tells you otherwise is selling you something they do not control.

If the part you are actually worried about is the calendar rather than the console, we wrote up where the tester window fits into a real Android launch plan here: https://zoopcoder.com/guides/how-long-to-build-app-website-india.php

Numbers checked September 2026. If Google has changed a threshold since, the Play Console policy pages win over this post — tell me in the comments and I will correct it.

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