The brief: what a kirana shop actually needs online

Nine modules of pieces. From here you build one thing.

This is where the course changes character. Up to now each lesson taught a technique. From here the lessons build a working shop, each on top of the last, and the difficulty stops being "how does this feature work" and becomes "what should this do".

The shop

Sharma General Stores is a kirana shop in Wagholi, Pune. Two hundred square feet, about six hundred product lines, three staff including the owner.

Orders currently arrive by WhatsApp: a customer sends a list, somebody reads it, packs it, and phones back with a total. It works, and it does not scale past the owner's attention.

What they want: customers ordering online, delivery in the same area they already deliver to, and the owner able to manage it from a phone between serving people in the shop.

What they do not want: anything that needs a laptop, a training course, or a monthly fee that exceeds what it earns.

That last constraint shapes more decisions than it looks.

The brief

Customers can:

• Browse products by category
• Search by name or brand
• See price, unit and whether something is in stock
• Add to a cart that survives closing the browser
• Choose a delivery address and a time slot
• Pay online, or choose cash on delivery
• See their orders and each order's status

The shop owner can:

• Add, edit and deactivate products and their variants
• Update prices and stock
• See incoming orders and move them through packing and delivery
• See what sold this week

The system must:

• Never sell stock it does not have
• Never charge a price different from the one shown
• Work on a cheap Android phone on a patchy connection
• Be findable in Google for "kirana delivery Wagholi" and similar
• Handle a customer closing the tab mid-checkout without losing or duplicating anything

What is out of scope, deliberately

Naming this is part of the work.

Multiple shops. One shop, one catalogue, one stock number. Multi-tenancy is a large change and this brief does not need it.

Delivery routing and driver tracking. Orders get a status. Where the delivery person physically is, is not modelled.

Loyalty points, referrals, subscriptions. All reasonable later.

Weight-adjusted pricing. A kilo of tomatoes that weighs 1.05kg is charged as a kilo. Real shops handle this and it complicates orders considerably.

Returns and refunds beyond cancellation. An order can be cancelled before dispatch. Anything after that is a phone call.

Inventory purchasing. What the shop buys from its own suppliers.

Write the exclusions down and show them to whoever wrote the brief. Half the disagreements on a project are about something one side assumed was included. An hour spent listing what you are not building prevents a much longer conversation later.

The constraints that actually shape it

Three, and each drives real decisions.

Most customers are on a mid-range Android on mobile data. So: server rendering, small JavaScript bundles, images sized properly, and an interface that works at 320px. This is why module 3 spent so long on the server/client split.

The owner manages it on a phone, standing up, between customers. So: the admin is not a desktop-first data grid. It is a few screens with large tap targets, and the most common action — marking an order packed — is one tap.

Search traffic is the realistic route to customers. They are competing with BigBasket and Blinkit, who have budgets. What a local shop can win is "kirana delivery near me" and specific product searches. So: server-rendered product pages, real URLs, structured data, a generated sitemap. Module 3's SEO lesson was not decoration.

The hard parts

Four, and they are the reason this project is worth building.

Stock at checkout. Two customers, one packet of atta. Module 6 built the mechanism; module 12 applies it to a real checkout where a cart has six items and any of them might have run out.

Price changes mid-cart. A customer adds atta at ₹285, the owner raises it to ₹295, and the customer checks out an hour later. Which price applies? There is a right answer and it is not "whichever the code happens to use".

The customer closing the tab. Mid-checkout, after payment, between the payment succeeding and your server hearing about it. Module 14.

Orders are a state machine. Placed, packed, out for delivery, delivered, cancelled. Not every transition is legal, and "cancelled" after "delivered" is a bug that costs money.

None of these are technology problems. They are questions about how a shop should behave, and the code follows from the answer. That is what makes this a real brief rather than an exercise.

How the next six modules go

Module	Builds
10	planning — this module
11	catalogue and search
12	cart and checkout
13	orders and the admin area
14	payments
15	testing
16	deployment

Each ends with something that runs. Do not skip ahead — module 12 assumes the catalogue exists, and reading about a cart you have not built teaches considerably less than building one.

Before you write any code

The next three lessons turn this brief into user stories, a data model and a set of architecture decisions. That is roughly two hours before the first line, and it is the right order.

The Python capstone made the same argument at a smaller scale. Here it matters more, because the decisions are bigger and the cost of changing your mind at module 14 is a great deal higher than at module 10.

Check your work

Why write down what is out of scope: half the disagreements on a project are about something one side assumed was included.

The three constraints, and what each drives: cheap Android on mobile data drives server rendering and small bundles; the owner managing on a phone drives a simple, large-target admin; search being the route to customers drives real URLs, structured data and a sitemap.

Why the four hard parts are not technology problems: each is a question about how a shop should behave. The code follows from the answer, not the other way round.

Why one shop and not many: multi-tenancy is a substantial change to every query and this brief does not need it.

Why weight-adjusted pricing is excluded: it complicates orders considerably for a case the shop can handle by rounding.

Practice

Before the next lesson, write down:

1. Every screen a customer needs, and every screen the owner needs. Keep them separate.
2. For each of the four hard parts, your first instinct at how to handle it. You will revise these — the point is to have an opinion before being told.
3. Three more things you would exclude from scope, and why.
4. One thing in the brief you find ambiguous. Decide how you will resolve it and write the decision down.
5. The price-change question: a customer adds an item at ₹285 and checks out after the price rises to ₹295. What should happen, and why? Consider the customer's expectation, the shop's margin, and what is simplest to explain.

Question 5 has no single right answer, and having a defensible one is the skill.

Next: turning the brief into user stories.