What ₹20,000 buys you — and what it doesn't

Websites and apps here start at ₹20,000. Starting prices are close to meaningless unless someone tells you what changes them, so this is that explanation.

What that number is

It is the floor for a genuinely small, genuinely useful first version: one clear job, a handful of screens, a database, a deployment, and a person who read every line before it went live. The first-website build in the case studies is the honest shape of it, and every case study quotes its own starting price against its own timeline.

What pushes it up

• Payments. Money means reconciliation, refunds, failed-payment states and a testing burden that non-payment features never have.
• Offline support. A mobile app that has to work without signal is roughly twice the work of one that doesn't. Sync conflicts are their own project.
• Roles and permissions. Two user types is a little work. Five, with overlapping rules about who sees which numbers, is a lot.
• Integrations. Anything that has to talk to a system you already own is priced after I have seen that system's documentation, never before.
• Migrating existing data. Old data is always messier than anyone remembers. This is frequently the most underestimated line in a project.

What brings it down

The same list read backwards. A starting price is quoted against a scope, so the scope is the lever you actually hold, and it is worth pulling before you negotiate on anything else.

• Fewer user types. Every role is a set of rules about who sees what, and each one has to be tested against all the others.
• Take payments out of version one. Collect on delivery, or by a payment link you send by hand, and find out whether people want the thing before paying for the machinery that charges them.
• A browser instead of two app stores. A web app that works well on a phone costs a fraction of the same idea shipped to Apple and Google, and it never waits on a reviewer.
• Drop offline support. If your users are rarely without signal, this one decision can halve a mobile build.
• Start with the data you have. Keeping the old system read-only and starting clean avoids the migration, which is the line most often underestimated.
• Fewer screens. The report that would be nice to have, the second dashboard, the settings page nobody has asked for — each one is real money.

None of that is about building something worse. It is about finding out whether the idea works before paying for the version that assumes it does. I would rather quote a smaller project you actually want than a larger one you talked yourself into.

What is never included

Third-party costs are billed to you, by those third parties, at whatever they charge. I do not mark them up, and I do not absorb them:

• Cloud hosting and databases.
• Domain registration and renewal.
• Apple's ₹8,000-ish yearly developer fee and Google's one-time Play Console fee, if you are publishing apps.
• Payment gateway commission on every transaction.
• SMS and WhatsApp message costs — small individually, real at volume.
• Any paid API or library the project needs.

For a small build these usually land somewhere between a few hundred and a few thousand rupees a month. I will give you an estimate before we start, and I would rather over-estimate it.

The question worth asking

Not "how much is an app?" — nobody can answer that honestly. Ask instead: what is the smallest version of this that would be worth paying for, and what would that cost? That question has a real answer, and getting to it is what the free call is for.

If a quote arrives without questions attached to it, it is a guess wearing a suit.

A worked example

Take the first-website build from the case studies — a real shape rather than an abstraction. Roughly where the effort goes:

• Days one to five: the decisions. What the page says and who it is for, the domain registered in your name, and the accounts put in your hands. No code yet. This is the part that prevents the expensive mistakes.
• Days six to fourteen: the build. The page itself, the words, photographs sized so they load on mobile data, your links in one place, and email at your own domain.
• Days fifteen to twenty-one: live. Bio links switched over, Google set up, and a walk-through so you can edit it without calling anyone.

That is the shape that starts at ₹20,000. Ask instead for a page per product, enquiries routed per item, or a bookable calendar behind it, and it is a different number — not because anyone is being greedy, but because each of those adds rules that have to be modelled and tested.

Fixed price or by the hour?

I quote fixed prices for well-defined work, and I am straightforward about why that is not generosity. A fixed price transfers risk to me, so it includes a margin for the risk. If the work is genuinely well-understood, that margin is small and you get certainty cheaply.

Where a fixed price goes wrong is when the scope is not actually known. Then one of two things happens: the price carries a large buffer you pay for whether or not it is needed, or it does not, and the project quietly turns into a negotiation about what was implied. Neither is good for either side.

So for exploratory work — integrating with a system nobody has documented, or a first version where the requirements are genuinely still forming — I would rather work in short, priced blocks with a decision point at the end of each. You can stop after any of them.

What a change costs mid-project

Changes are normal and I am not going to pretend otherwise. What varies enormously is when they arrive.

• During the first week — usually free. Nothing is built yet; we are still deciding what to build.
• During the build, in an area not yet started — small. Reordering work is cheap.
• During the build, in something already finished — the real cost of the change, plus retesting what it touches.
• A change to the data model, after there is live data — the most expensive kind by a distance, because existing records have to be migrated and the migration has to be right the first time.

That last line is why I push so hard on getting the data model right in week one, and why I will spend an unglamorous afternoon on it while you are keen to see screens.

How to compare two quotes honestly

A cheaper number is not a cheaper project. Before comparing, make both sides answer the same four questions.

1. What exactly is included, written as a list you could tick off?
2. What third-party costs will I be billed for, by whom, and roughly how much per month?
3. What happens after launch — is any fixing included, and for how long?
4. Who owns the code and the accounts, in writing?

Two quotes that look ₹15,000 apart routinely turn out to be for different projects entirely. Ask these and the gap usually explains itself, in one direction or the other.