Online store
A storefront that is fed by the same catalogue you already keep
Most store builders ask you to maintain a second product list — one for the shop floor and one for the internet, drifting apart a little more every week. Akkad's storefront reads the catalogue you already keep. Publish an item and it is on the site; change a price and the site has the new price; take the last one off the shelf and the site stops selling it. The building part is about how the store looks and behaves, not about re-typing what you sell.
Every organisation gets a subdomain of its own — a lowercase name you claim, checked live for availability and screened against a reserved list so the platform's own names can never be taken. That subdomain is the address of your store from the moment you publish it, and it keeps working after you attach a domain you bought yourself.
The storefront is one multi-tenant application rather than a copy per merchant. It works out which store to serve from the incoming host: a name under akkad.io resolves to a subdomain, anything else resolves to a custom domain, and a first path segment that is not a known route and contains no dot resolves to a sub-website. That single piece of routing is what lets one deployment serve a subdomain, a purchased domain and several storefronts under the same business without any of them knowing about the others.
01
One catalogue, many storefronts
A business is not always one shop. A wholesale front and a retail front, a seasonal microsite, a separate site per brand — these are different storefronts over the same stock, and Akkad treats them that way.
One main site, any number of others
Exactly one website is the main one and is served at the bare subdomain. Every other carries a slug of up to 50 characters and is served at your subdomain followed by that slug. Slugs are unique within the business and screened against the same reserved list. The main site cannot be deleted while it is the only one you have.
Each one configured independently
Template, style, colours, language, banners, announcement bar, checkout form, pixel IDs and feature toggles are all per site. Two storefronts on the same catalogue can look and behave nothing alike.
Per-category visibility, per site
Each site carries its own visibility flag and sort order for every category. A wholesale front can show the categories a retail front hides, and the ordering of the category rail is a per-site decision rather than a global one.
Publishing is yours alone
A new site starts unpublished. The publish switch belongs to the owner and is never touched by the system — not on a downgrade, not on an expiry, not on any automated process.
Orders know where they came from
Every order records both its source and which storefront produced it, so a business running four sites can tell them apart in reporting rather than seeing one undifferentiated pile of online orders.
The catalogue stays single
There is no second product list to maintain. Stock, prices, variants, pack sizes and images are the ones already in your catalogue, and a sale on the site moves the same number a sale at the counter moves.
02
Five templates, four presets, six controls
A template decides the shape of the store — how items are laid out, how categories are reached, what the header does. There are five, and they are genuinely different designs rather than colour variations of one layout.
Style is a second, separate axis. A preset changes the temperament of whichever template you chose: how categories are drawn, how hard the edges are, how much air sits between things. Underneath the presets are six individual controls, each of which you can override on its own when the preset is right about five things and wrong about the sixth.
- The template and the style preset are chosen independently — any of the five with any of the four.
- Presets are a starting point, not a lock: every one of the six controls remains individually settable.
- Colours, logo shape and language sit outside both axes and apply to whatever combination you land on.
03
The five templates
Pick by how your customers actually shop. A restaurant menu, a fashion feed and a considered catalogue are not the same browsing problem.
| Template | Character |
|---|---|
| Classic | A category rail with a compact all-items teaser row, then stacked merchandising sections running down the page. |
| Menu | Category tabs over a vertical list of item rows, with a sticky cart bar and a slide-up cart panel. Built for ordering rather than browsing. |
| Catalog | The same engine as Menu rendered as a product grid with quick-add cards. |
| Trendy | Marketplace-style. A dense two-row sticky header with inline search and category tabs, feed chips for new arrivals, deals and best sellers, portrait cards, and rank lines reading “#N Best Seller” — the top three per category and the top ten overall. |
| Lumen | Calm and editorial. A full-bleed square showcase hero behind a transparent app bar, an edge-to-edge grid with a shopper-facing sort dropdown and a grid-density toggle, row-by-row reveal on scroll, and infinite scroll at twenty items a page. Categories live in the drawer rather than in tabs, and both sort and density are mirrored into the URL so a filtered view can be shared. |
Classic's homepage is a merchant-ordered subset of four sections: new arrivals and items on sale and best sellers at fifteen items each, and featured items at ten, each carrying its own badge. You choose which ones appear and in what order.
04
The six style controls
The presets — Default, Clean, Visual and Compact — set all six at once. Default keeps the template's own look, Clean prefers text chips and quiet surfaces, Visual prefers image categories and richer surfaces, Compact tightens spacing for fast browsing. Any single control can then be overridden.
| Control | Options |
|---|---|
| Category style | Image cards, image circles, image squares, text pills, compact tabs |
| Corner style | Soft, rounded, pill |
| Surface style | Flat, outlined, soft shadow |
| Section header style | Simple, badge, divider, highlighted |
| Header style | Plain, bordered, tinted, floating |
| Density | Comfortable, compact |
05
Your own domain, with certificates handled
Attaching a domain you own is four states and one DNS record. There is no certificate to buy, upload, or remember to renew.
- 1
Enter the domain
It must begin with www. Addresses under akkad.io are rejected, and a domain can only ever be claimed by one business. The site stays reachable on its subdomain throughout, so nothing goes dark while you set this up.
- 2
Point a CNAME at stores.akkad.io
One record at your registrar. The backend resolves the CNAME itself to confirm it points where it should, which is why the state is called pending DNS — it is waiting on your registrar, not on us.
- 3
The certificate is issued on demand
Once DNS verifies, the domain moves to SSL pending and an immediate HTTPS warm-up request is made against it, which triggers issuance. The web tier asks the backend before issuing anything, and only domains already in SSL pending or active are allowed — so nobody can point a CNAME at us and have a certificate minted for a domain we have never heard of.
- 4
Active — or a state that tells you why not
A background job re-checks every SSL-pending domain every five minutes and finishes the job when propagation is slow. After a set number of attempts the domain moves to an error state rather than sitting in limbo, so a typo in a DNS record surfaces as a problem you can act on.
What happens if you fall below your plan's site limit
If a business has more published sites than its plan covers — after a downgrade, or when a subscription lapses — the oldest sites within the limit stay live and the rest return a temporary-unavailable page. The published flag is never flipped by the system. Re-subscribing brings back exactly the same site, with its template, colours, banners and category ordering intact, rather than an empty shell you have to rebuild.
06
Language, script and type
The storefront is not an English site with translations bolted on. Direction, typography and the shape of the layout are all part of the same decision.
Fourteen storefront languages
The thirteen languages the apps carry, plus Kurdish Sorani, which exists on the storefront specifically because shoppers ask for it. Language is set per site, so two storefronts under one business can serve different audiences.
Right-to-left as a first-class layout
Arabic, Kurdish Sorani, Persian and Urdu render right-to-left throughout — not mirrored as an afterthought, but as the direction the layout was written to support.
Fonts served from the store itself
Per-script families are self-hosted: Almarai for Arabic, Vazirmatn for Persian and Urdu, Inter for Latin and Cyrillic. No runtime request to a font host, which means no third-party dependency on first paint and no text reflowing once the font arrives.
Brand colour, applied consistently
A primary and secondary colour flow through buttons, the announcement strip, text-rendered capsule banners and the browser theme colour on mobile.
Logo shape as a setting
Circle, rounded or wide — chosen to match how your logo was actually drawn, rather than forcing every mark into the same crop.
Policy pages included
Privacy, terms, shipping, returns and an FAQ have their own routes and their own content, so the pages a payment provider or an ad platform expects to find are already there.
07
Cart and checkout
The part where a browse becomes money. Everything here is priced by the server, because the browser is a place a customer can edit.
Server-side repricing at order time
The cart shows a preview; the server recomputes the authoritative total when the order is created. Items, shipping rules, discount rules, promo code, tax and cash rounding are all recalculated from your live configuration. Amounts sent by the client are never trusted.
Variants and pack sizes in the cart
A line can carry a variant and a pack size — “Box of 12” prices per pack, with the quantity meaning the number of packs. The server refuses a pack that does not belong to the exact item and variant on the line.
A checkout form you build
The fields shown, which are required, their order and their labels are yours to set. A business that delivers by courier asks for different things than one that ships by post, and the form should say so.
The carrier's real address tree
When a courier integration is connected, the city and region pickers are populated from that carrier's own lists. The address a customer picks is an address the courier recognises, which is where most delivery failures actually start.
Saved information and phone validation
Returning customers get their details back. Where the business is set to Iraq, phone numbers are validated against the real local format rather than a generic length check.
Double submissions cost nothing
Every checkout carries a client-generated request identifier. A retried submit — lost response, impatient second tap — returns the original order rather than creating a second one or deducting stock twice.
Favourites
On by default. A heart on every card, a favourites page of its own, and the list kept locally so it survives without an account.
Order tracking without an account
A tracking page takes an order number and a phone number. A wrong number and a wrong phone return the same response, so the page cannot be used to discover whether an order exists.
08
Social proof you did not write
Reviews from people who actually received the item
A review section is only worth having if a shopper believes it. Akkad's reviews are written by verified purchasers only: to leave one, you must have a delivered order containing that specific item. Shipped is deliberately not enough — an order in transit is not yet an opinion about the product. One shopper gets one review per item, and the merchant's power over what is written is deliberately limited.
The merchant may hide and reply, but never delete
You can hide a review, unhide it, and reply to it once. You cannot delete it — only its author can. That asymmetry is the whole point: a review section a merchant can prune is a marketing section, not a review section.
Stars, text and up to three photos
One to five stars with optional body text and a maximum of three photos. The public list is paged ten at a time, newest first, with an average, a count and a full star distribution. When there are no reviews yet, nothing renders at all rather than an empty shell.
Emails never reach the public page
The merchant's own view of a review carries the shopper's email address so you can follow up. The public view never does. A shopper's own profile name takes precedence over the name their sign-in provider supplied.
The shopper always knows where they stand
Rather than a button that silently fails, the storefront asks the server whether this person can review this item and gets a specific answer: reviews are off, not signed in, already reviewed, not purchased, or go ahead.
09
The things a merchant actually adjusts
Small surfaces, each with a default chosen so the store is right before you touch anything.
Announcement bar
A thin brand-coloured strip above the header carrying a list of messages, animated as a typewriter, a slide, or held static. The server renders the first message in full, so it is readable before any script runs and visible to crawlers; the animation takes over after hydration. Under a reduced-motion preference it simply does not animate.
Promotional banners
Up to ten per site, each pointing at a category or an item. Dead links are neutralised on the server — a banner aimed at a deleted item, an unpublished one, or a category hidden on that site stops being tappable rather than sending a customer to a missing page.
Capsule banners
A slim pill strip below the categories, up to ten, either an uploaded image or text rendered in the store's own theme. Same targeting, same dead-link checking.
Side drawer
Slide-out navigation on every page: the first five categories with a link to the rest, order tracking, app install, policy pages and the customer account. On by default with no toggle, because a store without navigation is not a design choice.
Back button behaves like a back button
The hardware back button and the edge swipe close whatever drawer or sheet is open rather than leaving the site. Getting this wrong is one of the fastest ways to lose a mobile shopper, and it is easy to get wrong.
Out-of-stock and low-stock
Sold-out items are hidden by default and never leave the server at all. Turn them on and they appear badged and unbuyable — the purchase path checks stock regardless of any display setting. Low-stock flags are on by default and show how many are left once stock falls to five or fewer.
WhatsApp button
Off by default, and it only appears if you have actually added a WhatsApp link. On mobile it lifts itself above sticky bottom bars instead of sitting under the cart.
Search that survives a typo
A search overlay with debounced live results, and an inline header field in Trendy. The backend carries two tiers of typo correction and treats Arabic-Indic and Latin digits as the same thing, so a mistyped or differently-typed query still finds the item.
Browsing controls for the shopper
A sort control, a grid-density toggle in Lumen, a lightbox gallery, a variant selector with per-variant and per-attribute images, a trust strip and a contact section.
10
Installed on a phone like an app
A returning customer should not have to find you through a browser tab. The storefront installs to a home screen, and everything the phone needs to do that is generated per tenant.
The native prompt where it exists
On Chromium browsers the install button fires the browser's own install dialog — one tap, no instructions to read.
A real guide on iOS
Safari has no install prompt, so instead of a button that does nothing, iOS shoppers get a short Share to Add to Home Screen walkthrough. iPadOS reporting itself as a Mac is detected too, which is a common way this check goes wrong.
Hidden once installed
The install option disappears when the store is already on the home screen. On by default, and present in both the footer and the drawer.
A manifest per tenant
Generated on request with the store's name, a twelve-character short name, standalone display, the brand colour as the theme colour, and the correct language and text direction. Cached for five minutes.
Icons generated on the fly
192 and 512 pixel icons in both standard and maskable forms, a 180-pixel Apple touch icon and a 64-pixel favicon, all produced from your logo. Maskable matters: without it, Android crops your logo into its own shape and usually cuts something off.
Full-bleed, and correctly cache-busted
The icon pipeline fills the frame rather than leaving a white border. Icon URLs carry a version marker derived from the logo itself, so changing your logo changes the icon instead of leaving the old one cached on every device that ever visited.
11
Found, indexed, and hard to break
Multi-tenancy makes the ordinary SEO plumbing interesting, because there is no single site to describe. Every one of these is resolved from the host making the request.
A sitemap per host, built per request
The sitemap works out which store is being asked for, then lists the home page, the items page, every category and up to a hundred items — carrying the sub-website prefix where one applies. If a data fetch fails it degrades to the home URLs rather than returning an error, because a partial sitemap is worth far more to a crawler than a broken one.
Robots that point at the right sitemap
Also per host: browsing is allowed, the cart and checkout are disallowed, and the sitemap line points at that host's own sitemap rather than a shared one.
Link previews that look like a shop
Per-tenant title templates, a description from your store profile, the full icon set, and Open Graph and Twitter card metadata — using a large image card whenever a banner or logo exists. A link pasted into a chat is often the first impression, and a blank preview reads as a broken site.
Images handled on the way in
Uploads are compressed server-side, remote sources are allow-listed, and card and store imagery goes through shared components so sizing is consistent rather than per-page guesswork.
Rendered on the server first
Pages are server-rendered with data fetched in parallel; Lumen and Trendy add client-side infinite scroll and fetch categories lazily as they are needed. The first screen does not wait on JavaScript.
Motion is a preference, not a mandate
A reduced-motion preference is honoured throughout — the announcement bar stops animating, reveals stop revealing. Accessibility settings are instructions, not suggestions.
12
Questions
Do I have to maintain a separate product list for the store?
No. The storefront reads the catalogue you already keep. Publishing an item puts it on the site, and its price, stock, variants, pack sizes and images are the same records the rest of the system uses. There is nothing to sync and nothing to drift.
Can I use a domain I already own?
Yes. The domain must start with www, and you point a CNAME record at stores.akkad.io. Once that record resolves, the certificate is issued automatically and renewed without you doing anything. A background job re-checks pending domains every five minutes, so slow DNS propagation resolves itself.
What happens to my store if my subscription lapses?
Sites beyond what your plan covers return a temporary-unavailable page, oldest sites staying live first. Your published setting is never changed by the system, so re-subscribing restores exactly the site you had — the same template, colours, banners, category ordering and content.
Can I run more than one storefront on the same stock?
Yes, depending on your plan's site allowance. One site is the main one served at your bare subdomain; others are served under a slug. Each has its own template, style, language, banners, checkout form, pixels and per-category visibility, and orders record which site produced them.
Who can leave a review?
Only a signed-in shopper with a delivered order containing that item, once per item. You can hide a review or reply to it once, but you cannot delete it — only the author can. The public view never shows a reviewer's email address.
Does the store work if a shopper's connection is slow or JavaScript is blocked?
The pages are server-rendered, and the announcement bar's first message is rendered in full on the server specifically so it is readable and crawlable before any script runs. Animation and infinite scroll are enhancements layered on afterwards.
Related
Landing pages
One product, one page, one URL. Where to send ad traffic when a whole store is too much.
Growth and marketing
Pixels, server-side conversion events, catalogue sync and shopper accounts.
Sehen Sie es an Ihrem eigenen Katalog
Starten Sie mit dem passenden Tarif, importieren Sie Ihre Artikel aus einer Tabelle und haben Sie noch am selben Tag einen laufenden Shop, eine Theke und ein Auftragsbuch.
Kostenloser Tarif verfügbar. Zum Ausprobieren ist keine Karte nötig. Der Import bringt Ihren bestehenden Katalog mit.