Catalog and filters
Categories, filters and sorting are built around your goods, not the other way round. “By size” in a shoe shop and “by power” in a tool shop are different filters, and a template knows neither.
Services · 08
From a photo of the product on your desk to a shipping label the courier collects that evening. Catalog, cart, payment and delivery as one mechanism, not five separate services glued together.
Just write — I take it from there. Scoping your task costs nothing.
Sound familiar
None of them is about design. All three are about mechanics — and mechanics is what the rest of this page is.
A working demo you can click.
Mechanics
Anyone can build a shopfront now. The difference starts where the buyer taps Buy while you are still asleep. Here is what happens next — and what of it reaches you.
The buyer adds things and goes off to read more. The cart survives a page reload and a return the next day — that is where half the orders actually live.
Name, phone, pickup point — that is all. Every extra field costs orders, so there are exactly as many as the parcel needs to arrive.
The buyer picks the city and the pickup point from the carrier’s own list instead of typing it. A wrong address is the most expensive mistake a store makes: the parcel travels, comes back, and you pay for both legs.
Card now or cash on delivery — the buyer decides. A store that demands prepayment from a stranger loses a share of its orders silently, and you never get to see which ones.
The order lands in the admin and in your Telegram at the same moment. The buyer’s confirmation goes out on its own: that minute is when they decide whether this shop is real.
The label is created from the order card and its number goes back to the buyer in a message. Nobody retypes the address into the carrier’s console — that retyping is exactly where the typos come from.
A sold item leaves the shelf by itself. The worst conversation with a buyer starts with “sorry, that one is gone”: the money goes back, the person does not.
This is not a feature list. It is how the store runs at night while you sleep. Any step here can be dropped — but then somebody does it by hand, and that somebody is you.
What’s included
Categories, filters and sorting are built around your goods, not the other way round. “By size” in a shoe shop and “by power” in a tool shop are different filters, and a template knows neither.
Photos, description, specifications, availability, related items. People land on a product page straight from search, so it is a real page with its own address, not a popup over the catalog.
A cart that does not get lost and a form that needs no account. Promo code, order note, payment and delivery choice on one screen.
Card payments online and cash on delivery. The contract with the payment provider is in your name and the money goes straight to you — I have no access to it and want none.
City and pickup point from the carrier’s list, delivery cost, and a shipping label created from the order card. Self-pickup and your own courier are delivery options too, and they get set up as well.
Products, prices, stock, orders and statuses are changed by you, without me and without a developer. It is the part you will spend the most time in, and the part that usually gets built last.
Products loaded from a file instead of typed in, and a catalog feed for marketplaces and shopping ads. One catalog, not three copies that drift apart.
You can see where a buyer came from and at which step they left. Without it a store gets fixed blind: the button gets redesigned while the delivery step is what broke.
How it goes
What you sell, how many items, how you ship and take money today. Half an hour of typing instead of a call, and I already know where the bottleneck is.
From you: a link to whatever you sell from today
Categories, filters and the fields of a product page — on paper, before the first line of code. This is where it is decided whether a buyer finds their item in three taps, and redoing it after launch is expensive.
From you: your product list and what makes items differ
Design and markup, phone first. You look at live pages in your own browser rather than pictures of a mockup — the catalog is exactly where the difference shows.
From you: your notes in one list, not one at a time
Cart, payment, delivery, admin, import. Every part is checked with a real test order — from the button to the shipping label, not on trust.
From you: access to mail, payments and the carrier
We walk through the first real order together, on the live store. I show you the admin on your own products, not on a demo: add an item, change a price, close an order.
From you: nothing
Questions
I look first and answer after. If the builder handles your volume and stays out of the way, we leave it — patching is cheaper. Moving makes sense when you keep hitting the plan limits or waiting on support to change a single field.
The question is structure, not count. A hundred items with no filters is harder to search than a few thousand with the right categories. You give me the volume in the spec and the structure is built for it, not for an average case.
That is agreed separately. But nobody types a catalog in item by item: it is imported from a file, and after that you add new arrivals yourself in the admin — it takes a minute and needs no developer.
Yes, and plenty of stores do exactly that: cash on delivery first, cards later, once there are repeat buyers. The mechanics do not change — one part changes, and it drops in without rebuilding the rest.
They are different jobs and usually live side by side. A marketplace brings you someone else’s traffic and keeps a cut of the order along with the buyer’s contact. Your own store gives you a customer base and repeat sales, and the marketplace feed is exported from it in one file.
This is the most common reason a small store has to refund: the item left the shelf but the site still lists it. There are two answers and the choice is yours. Either the site owns the stock number and you mark offline sales in the admin. Or your own stock software owns it and the site reads from there — that is a bigger job, and it pays off once offline outsells the site.
«Gordey is that rare developer who asks about the business before the technology. We were building a large store, and he left room for growth from day one so we wouldn’t be rewriting it a year later. Pages open almost instantly now: 800 milliseconds became 120, and purchases went up by 18%.»
«At peak hours the store barely breathed — exactly when people are ready to buy. Gordey rebuilt what was underneath so heavy pages are prepared in advance. Load time dropped from 4,5 seconds to 0,8. Sales rose 22% in the first month. It turned out we were losing buyers on waiting alone.»
«We used to sell inside chats: a customer asks for photos, we send them, then we add it up together. Gordey built a shop right inside Telegram — a Mini App with nothing to install: bouquets on show, a cart that fills up, payment in one tap. More orders, less messaging.»
One message is enough: what you sell, how many items, and where the orders reach you now. Then a few questions from me, and I say what I take on and what I do not.