Custom e-commerce development in Athens: what you are actually buying

Ask five companies in Athens for a proposal for an online store and all five will call what they offer custom. None of them is lying. The word simply covers several different products, and a buyer comparing proposals is usually comparing the price of one against the price of another without knowing it.

The first is a rented platform with a designed theme. The look is yours; everything underneath — the checkout, the data model, what the platform will and will not allow — belongs to the platform, and the Greek requirements arrive as apps. The second is an open-source platform installed on your own server with a custom theme and a set of plugins. You have more control and more responsibility, and the store is as healthy as the least maintained plugin in it. The third is a store written for one business from the database up. It does exactly what the brief asked, and then, unless someone keeps writing it, it starts to age on launch day.

We have written about the first two elsewhere, and about why the third decays. This piece is about what a buyer should actually be paying for when they hire a custom e-commerce development agency in Athens, whichever of those shapes the agency proposes.

Start with the catalogue, because it decides more than the design does. A store is a set of products described in a way that customers can search, filter and compare. If the description of each product is a paragraph of text, nothing can be filtered and nothing can become a page of its own. If it is a set of structured fields — brand, size, colour, material, SPF, movement, water resistance, whatever this catalogue is actually chosen by — then filters, comparison and search landing pages all come from the same data. When we moved Rellas Jewellery, the spec tables of 1,134 watches and rings were turned into structured fields with one consistent spelling for each value; around 4,600 landing pages were then generated from those specifications rather than written by hand. That work does not appear in a screenshot of the homepage, and it is most of what makes a large catalogue findable.

Then the checkout, which is where the store meets the money and the law. In Greece that means cards with instalments, wallets, bank transfer, cash on delivery with its legal limits, an invoice that asks for a tax number only when the customer wants an invoice, VAT that may differ from product to product, and shipping rules that reflect how the business actually ships. At Topharmakeio.gr the checkout shows each VAT rate separately, as a pharmacy receipt does, and shipping is worked out from each product's weight, with free collection from any of the three pharmacies. None of that is exotic. All of it has to be decided by someone who asked, rather than inherited from a default.

Third, the dashboard your people use every day. Customers see the storefront for a few minutes; the staff live in the back office for eight hours. Ask to see the screen where an order is changed, a product is added, a discount is scheduled and a wholesale customer is approved. At SIDEMILE, retail riders, partner shops and wholesale buyers are served from one catalogue, with trade prices applied automatically once a reseller is approved — managed from the store's own dashboard without a developer. If every one of those tasks needs an email to the agency, you have bought a website and a dependency.

Fourth, the data and what happens to it on the way in. Most stores in Athens are not being built from nothing; they are replacing an older one. The customers, their addresses, the past orders and the search positions the old addresses have earned are assets of the business, and a proposal that does not say exactly how each one is moved is a proposal that intends to start again. Ask which records are imported, whether order numbers are kept, and what happens to every old URL Google knows.

Fifth, being found. A store is now read by two audiences that do not click: search engines and AI assistants. Both need the product, the price, the availability and the business itself described in structured data, server-rendered so that nothing has to run before it can be read. Pages for real combinations in the catalogue — a brand within a category, a price range, a specification — are what answer the specific searches people type. That is engineering, not an SEO plugin.

Last, and the question proposals answer least clearly: who maintains the engine. Payment providers change their APIs, couriers change their formats, tax rules change their deadlines. Someone has to update the store when that happens. On a rented platform it is the platform and each app vendor, separately. On open source it is whoever you pay to keep the plugins compatible. On a store written once, it is nobody until something breaks. Our answer is NEXTCOMMERCE: the storefront is designed for one brand and belongs to it, while the engine underneath is written and maintained by us and shared by every store on it, so a fix lands for every store at once.

Which gives a short list of questions worth putting to any agency, including us. How will our catalogue be structured, and can we see the fields? Which payment methods, and who holds the merchant accounts? Which records are migrated, and do order numbers survive? What happens to every old address? Can our team do the daily work without you? Who updates the store when a provider changes its API, and is that written down? What do we own, and how would we leave?

And the honest limit, because it changes the answer for some readers. A shop with a small catalogue, one courier and no wholesale is usually better served by a rented platform, and a custom e-commerce development agency in Athens that says otherwise is selling its own preference. Custom earns its cost when the store has become an operation: a moving catalogue, several channels, and stock and accounts that have to agree with what the website says.