A page per product
Each item gets its own address — photograph, specification, sizes or variants, and price or enquire-for-price. One product can be sent on its own, which is the thing a catalogue in a feed cannot do.
CASE STUDY
Example buildWebsiteA Product Showcase You Can Send Anyone
Your catalogue lives on Instagram, and you cannot send that to a corporate buyer or a bank. This is the address that is actually yours.
- Type
- Static catalogue site
- Build time
- 4–6 weeks
- Running cost
- Domain + mailbox only
- Starts at
- ₹20,000*
This is an example build. Tavzuran is a new studio with no client work to show yet. This page describes how the project would be scoped and built — the same thinking you would get on a real one. Nothing here is a past client, and no number on this page is a result.
The price follows the feature list. The number above buys everything scoped on this page. Take features out and it comes down — the shortest route to a smaller number is a shorter list, and deciding what to drop is what the free call is for.
THE SITUATION
What's actually broken.
A small manufacturer, wholesaler or boutique sells real products and sells them well. The catalogue is an Instagram grid, a WhatsApp Business listing and a PDF price list that was current last year. For walk-in and regular customers this works completely.
It stops working the moment someone serious asks. A corporate buyer wants a link for their procurement file. A distributor wants to see the range before a meeting. A bank or an investor wants to look the business up. You can send an Instagram handle to a friend; sending it to a purchase officer reads as a business that has not got around to existing properly yet.
There is also the quieter loss. Nobody searching for what you make finds you, because a social profile does not answer a search the way a page about the product does. The business is invisible to everyone who is not already following it.
The catalogue only exists as Instagram posts and WhatsApp photos
A serious buyer asks for a website and there is nothing to send
Nobody finds the business by searching for what it sells
The price list is a PDF from last year, on someone's phone
VERSION ONE
What we'd build first.
Every item here earns its place by being something a real user would miss on day one.
A range that can be browsed
Products grouped the way you actually describe them, with filtering if there are enough of them to need it. A visitor should reach anything in the catalogue in two taps.
The credibility page
Who the business is, where it physically is, how long it has traded, registration and GST details, and a real photograph of the premises or the workshop. This is the page a buyer checks before replying, and leaving it vague costs more than a weak product page.
Enquiries that arrive somewhere
An enquiry button on every product that opens WhatsApp or email with the product already named, so the message says which item it is about. Sent to an address at your own domain, not a personal Gmail.
Findable
A page title and description per product, a sitemap, structured data so the product shows properly in search results, and image files small enough to load on a weak connection.
DELIBERATELY NOT IN V1
What we'd leave out.
Not because these are bad ideas. Because each one is designed better once the first version has told you something.
- A shopping cart and online payment. If you need to take money on the site, that is a different build and it is not static.
- Live stock counts. A static site cannot honestly claim a number that changes during the day.
- Customer accounts and order history, which need a database and a login — the two things this build deliberately does without.
UNDER THE HOOD
How it's put together.
- The site
- Plain HTML and CSS, generated from the product spreadsheet. No framework, because nothing here needs one and every dependency is a thing to update later.
- Content
- One spreadsheet of products, exported and built into the site. The owner edits a familiar tool rather than learning an admin panel.
- Hosting
- A static host on a free tier with HTTPS. The site is files; there is no server to keep patched and nothing to go down under load.
- Images
- Resized and compressed at build time into modern formats, with the dimensions declared so the page does not jump while it loads.
- A mailbox at your own domain, so enquiries arrive somewhere that matches the site.
HOW IT RUNS
Week by week.
-
01
Week 1
Product list and photography agreed. The spreadsheet structure is decided here, because everything else is generated from it.
-
02
Weeks 2–4
The catalogue, product pages and the credibility page built from real content, not placeholder text.
-
03
Weeks 5–6
Search details, enquiry routing, the domain and mailbox, and a walkthrough of updating the spreadsheet yourself.
THE HARD PART
Keeping it current without a login to forget
Every build has one problem that decides whether the rest of it matters. This is that problem, written out.
A static site is fast, costs nearly nothing to run and has no login screen for anyone to attack. The catch is the obvious one: if updating it means messaging a developer, it stops being updated. Within a year the prices are wrong, a discontinued item is still listed, and the owner has quietly gone back to sending photographs on WhatsApp.
So the products do not live in the page. They live in one spreadsheet — a column per field, a row per product — and the site is rebuilt from it. The owner edits the spreadsheet, which they already know how to do, and the catalogue updates. No admin panel, no password to reset, nothing to patch on a Tuesday because a plugin had a vulnerability.
That choice has a real cost and it should be said plainly: there is a short delay between the edit and the change appearing, and a typo in the spreadsheet can look odd on the page until it is corrected. In exchange you get a site with no database to breach, no login to compromise, and a hosting bill of nothing. For a catalogue that changes weekly rather than hourly, that is the right trade. For live stock counts it is the wrong one, and then this is not the build you want.
The second hard part is photography, and it is usually the thing that decides whether the site works. Twenty products shot against a bedsheet will undo every other decision on this list. The build assumes one consistent background, even light and the same crop on every item — which is a morning's work with a phone and a window, not a studio, but it has to actually happen.
BEFORE A PRICE EXISTS
What we'd ask you first.
A quote given without these answers is a guess. These are the questions that actually move the number.
- 01How many products, and how often do they change?
- 02Who would update it — you, or someone in the shop?
- 03Do prices go on the page, or is it enquire-for-price?
- 04What does a serious buyer ask you for that you cannot currently send?
- 05Do you have photographs you own, or only what is on the phone?
AFTERWARDS
How we'd know it worked.
Agreed before the build starts, so there is something to judge it against other than whether it looks nice.
- You can answer "do you have a website?" with a link instead of a handle.
- A buyer can be sent one product, not a feed to scroll.
- The business appears in a search for what it sells plus the city.
- Prices and products are still right six months later, because updating them is a spreadsheet edit.
BEFORE YOU START
Worth knowing.
This is the least expensive build on this list and the one with the lowest running cost — a domain and a mailbox, a few hundred rupees a month between them. What moves the price is the number of products, whether the photography exists already, and whether you want filtering or a plain list. If what you actually need is a cart and payments, say so early: that is a different build and pricing it as this one would be dishonest.
Websites and apps start at ₹20,000*. Final pricing depends on features and project scope. Third-party costs — cloud hosting, domains, external libraries, APIs, app-store fees and any other paid service — are billed separately and are not included.
KEEP LOOKING
Other example builds.
Mobile App
Restaurant Ordering App
Menu, cart, live order tracking and a simple kitchen dashboard for a multi-outlet restaurant.
Read the case study Web AppCoaching Management Platform
Batches, attendance, online tests and fee payments in one dashboard for students and staff.
Read the case study Web AppBusiness Automation Dashboard
Replaces daily spreadsheet work with automated reports, alerts and role-based access.
Read the case studyWant this built for your business?
Tell us what you're thinking. We'll figure out the next step together.
Free 20-min idea call · No obligation