Case study · Ecommerce / Retail
The half of an online store that costs the money
The storefront is the easy part. What makes ecommerce cost three times a brochure site is everything the customer never sees.
CraftKart
Ecommerce / Retail · 12–20 days · ₹28,000–₹60,000
Go and use the buildThe admin panel is the actual product
The storefront is a few days of work.
Payments go through Razorpay rather than anything custom
Razorpay handles UPI, cards, netbanking and wallets, and — critically — means card details never touch the store's own servers.
The situation
What goes wrong here
Small sellers on marketplaces lose a meaningful slice of every sale to commission, and — more importantly — never learn who bought from them. The customer belongs to the marketplace. Building an own-brand store is the obvious response, and it is a genuinely bigger project than most sellers are told.
The gap between expectation and quote is almost always about the same misunderstanding: the seller is picturing the shop, and the quote is mostly for the machinery behind it. A brochure website ends when the visitor clicks 'contact'. A store has to keep going — take money reliably, know what is in stock, record what was ordered, and let the owner run all of that without calling a developer.
The decisions
Every one of these had a cost
A decision with no trade-off is a feature list. Each of these names what was given up, because that is the part a client needs to agree with before the project starts — not after.
- 01
The admin panel is the actual product
The storefront is a few days of work. The system that lets an owner add a product, change a price, mark something out of stock, see what was ordered and mark it dispatched — that is the majority of the build, and it is what determines whether the store is still running in a year. A store the owner cannot update is a store that dies at its first price change.
What it cost
It is most of the cost and the customer never sees it, which makes it the hardest part of the quote to justify and the worst possible place to cut. Cutting it is how a seller ends up paying a developer for every price change.
- 02
Payments go through Razorpay rather than anything custom
Razorpay handles UPI, cards, netbanking and wallets, and — critically — means card details never touch the store's own servers. Building anything custom here would mean inheriting a compliance burden and a fraud surface for no benefit whatsoever.
What it cost
A per-transaction fee and a dependency on a third party. Both are correct trades: the fee is far smaller than marketplace commission, and the dependency is on the part nobody should be building themselves.
- 03
A real database, because a store has state
Stock levels, orders and their status are facts that change and have to survive. This is the point where a project genuinely needs PostgreSQL rather than data in the codebase, and it is the clearest technical line between a website and a web application.
What it cost
Hosting is no longer free, and there is a database to back up and maintain. This is where a maintenance plan stops being optional and starts being the difference between a store and a liability.
- 04
Order tracking, because the alternative is a phone call per order
Without it every dispatched order generates at least one 'where is my parcel' message. At thirty orders a week that is the owner's evening. A status the customer can check themselves pays for itself almost immediately.
What it cost
More surface to build and to keep accurate — statuses have to actually be updated, or the tracking page becomes a liar and generates the calls it was meant to prevent.
In the build
- Product catalogue with categories
- Cart and checkout
- Payment gateway integration
- Order tracking for customers
- Admin panel for products, stock and orders
Built with
- Next.js
- PostgreSQL
- Razorpay
You provide
- Product photographs and details
- Pricing and stock counts
- Payment and UPI details for gateway setup
- Logo and brand colours
Nothing starts until the scope, timeline and price are agreed in writing.
Measured
How this build actually performs
Taken from the finished build under throttled conditions, not from a score card. All six concept builds share a foundation, so they share these numbers.
Chromium at 412×915, 4× CPU throttling, 1.6 Mbps with 150 ms latency, cold cache — a mid-range Android phone on a typical Indian mobile network, not a developer's laptop. Includes the analytics the live site loads. Measured 2026-09-08.
- Largest contentful paint
- 1.58–2.16s
- When the main content is actually on screen. Google treats anything under 2.5s as good.
- Cumulative layout shift
- 0
- Nothing moves after it appears — no mis-taps caused by a button jumping.
- JavaScript over the wire
- 429 kB
- Compressed, as actually sent — 259 kB of site code plus 170 kB of Google Analytics.
- Total page weight
- ~613 kB
- Everything: markup, styles, fonts, scripts and analytics.
Honestly
What this is and isn’t
The public demo is the storefront half only — catalogue, cart and checkout flow, with invented products. It does not process real payments and its admin panel is not exposed publicly, for obvious reasons. The point of this study is the part you cannot see in the demo, which is also the part that determines the price.