Browse and search
The header carries a search box with a category filter on every page. The menu below it goes straight to multigrain flours, cold-pressed oils, order tracking, the Organic Insights articles, and deals and gifts.
CASE
STUDY
STUDY
SadaPure: the best Next.js ecommerce store in Pakistan, built by Ozairwebs
SadaPure sells stone-ground atta, single-grain flours, and cold-pressed oils to customers across Pakistan. We wrote the storefront and the admin dashboard ourselves, so the shop does what the business needs and carries nothing it doesn't need.
Project details
Visit sadapure.com| Client | SadaPure |
|---|---|
| Industry | Organic food and personal care retail |
| Market | Pakistan, nationwide delivery |
| Project type | B2C e-commerce store |
| Platform | Custom Next.js store with its own CMS dashboard |
| Technology |
|
| What we delivered |
|
| Live website | sadapure.com |
The short answer
What is SadaPure, and who built it?
SadaPure is an online store based in Lahore. It sells multigrain atta, single-grain flours, and cold-pressed oils, and it delivers anywhere in Pakistan. Ozairwebs built all of it: the Next.js storefront, the MySQL data model, and the private dashboard that the SadaPure team opens every day to run orders, products, content, ad tracking, and site speed.
We call it the best Next.js ecommerce store in Pakistan because it is not a theme with a pile of plugins on top. Each page, each checkout rule, and each tracking tag was written for this one business. The result loads quickly, reads clearly, and can be managed by people who never touch code.
Shoppers browse by category, choose a pack size, order as a guest, and pay cash on delivery. The team gets one panel for orders, stock, reviews, deals, SEO, Meta Pixel, Google Analytics, caching, and the API settings that sit behind it.
- Built by
- Ozairwebs
- Live store
- sadapure.com
- Platform
- Next.js 16, React 19, Node.js 22, MySQL
- Hosting
- Hostinger Node.js hosting
- Market
- Pakistan, prices in PKR
- Checkout
- Guest checkout with cash on delivery
Mockups
A look at the SadaPure storefront
The image at the top of this page is the homepage. These three show where a shopper spends the rest of the visit. Each mockup puts the desktop layout next to the phone layout because every page has to work on both.
Storefront
What shoppers can do on the site
The public side is plain on purpose. A visitor should be able to find a product, understand it, and order it without reading a manual.
Product pages built around ingredients
Each product lists its pack sizes with separate prices, a plain ingredient list, usage notes, a photo gallery, and an optional video. Product-specific questions and answers sit on the page itself.
Guest checkout, cash on delivery
No account is needed to place an order. Cash on delivery is the only payment method, and the checkout does not advertise card or wallet options that are not available. Delivery charges and the free-delivery limit come from dashboard settings, not from code.
Tracking and accounts
A track-order page shows customers the status of their order, and delivery guidance is printed before they confirm. Those who want an account sign up with an email address and confirm it with a one-time code.
Reviews from real orders
Review links are sent only for completed, paid orders. Customers rate each product, can attach a photo, and nothing is published until the team approves it. Visitors can sort by newest, highest, lowest, or reviews with photos.
Deals, gifts and recipes
Scheduled deals and selected gift collections are priced on the server, so the cart and checkout always agree with the product page. The Organic Insights section holds recipes and care guides that link back to the products they cite.
Admin dashboard
The dashboard behind the store
The admin area sits behind its own login, away from the public site. Everything the team does in a normal week is in the left-hand menu, and none of it needs a developer.
Orders and status
Search by order number, filter by status, and see exactly which products and pack sizes were ordered. Status changes, review requests, and the order activity log live on the same screen.
Order export and labels
Pick a product and a date range, then download an Excel workbook or CSV with a city summary. Editable Word labels print three per A4 page, each with a tick box for the courier call.
Products and stock
The product editor handles prices, pack sizes, gallery, video, FAQs, and SEO fields. A Check product SEO button reviews the unsaved draft, and a CSV importer adds products in bulk. Inventory has its own quick stock screen.
Customers and reviews
A customer directory, a moderation queue for product reviews, and a separate one for recipe reviews. Review requests are sent via email or as a ready-made WhatsApp message.
Gifts and deals
Create a deal with start and end dates, choose its products, and place it on the homepage. The deal price is automatically added to the cart and checkout.
Homepage, pages and posts
Edit the hero, decide which categories appear and with which image, and reorder homepage sections. Pages, blog posts, menus, and the footer have their own editors, and Custom CSS covers small visual fixes.
Media library
One place for every product, category, and article image and video. It also runs the AVIF conversion batch and the storage panel that keeps image files out of the database.
Site and commerce settings
Site identity, contact details, social links, delivery rules, return terms, the sender block on printed labels, and a database backup section. A Brand identity for Google and AI feeds the structured data on every page.
Tracking and messaging pages
Dedicated screens for Meta Pixel, Google Ads, GA4, cookie consent, WhatsApp automation, WebMCP, and performance. Each one is described further down this page.
Analytics and ads
Tracking that waits for the visitor's say
Pasting scripts into a theme is how stores end up slow and untidy. SadaPure keeps each tracker on its own dashboard screen, with switches, test tools, and a shared consent manager available to them.
Meta Pixel and Conversions API
On the Meta Pixel screen, the team turns tracking on, enters the Pixel ID, and stores the Conversions API token, which remains on the server and is displayed in a masked form. There is a field for the test event code, one for Facebook domain verification, and a switch for each event: page view, view content, search, add to cart, initiate checkout, and purchase.
Browser and server events share the same event ID, so Meta can match them rather than count them twice. The purchase event is sent from the server once an order is saved, with customer details hashed first. A Send test event button and a short log show what Meta accepted, and a Meta failure never holds up a checkout.
Google Ads and GA4
One Google tag serves both products, so the page loads a single script. The dashboard takes the Ads tag, a list of conversion pages with their labels, a Purchase conversion that reports order value and order number, and the GA4 measurement ID.
The tag does not load until the visitor first touches the page or about 7 seconds after the page finishes loading. Commands are queued in the meantime and sent when the library arrives. The order-received page loads immediately, so a purchase is never missed.
One cookie consent manager
A slim bar at the bottom of the page covers Google Ads, GA4, and the Meta Pixel together. Visitors tap Accept or open Settings, where analytics and advertising are separate switches,s and Reject all is one tap away. The choice is remembered for the period set in the dashboard, and a Cookie settings link in the footer reopens it.
The team can ask everyone first or show a plain notice to visitors in Pakistan, pick Google Consent Mode in basic or advanced form, edit the banner wording, and bump the policy version when the policy changes. The Meta Pixel loads only after advertising consent is given.
WhatsApp automation
The WhatsApp screen holds the Cloud API connection and the template messages that the store sends after an order and when it requests a review. Access tokens are used on the server only, never in the browser.
For review requests, the order screen can also open WhatsApp with a ready-made message to the customer's number, so the team can send it manually when they prefer.
SEO, AEO and GEO
Built to be found by search engines and AI assistants
Ranking is earned by good pages, and no file or setting guarantees it. What the store can do is make each page easy for Google, Bing, and AI answer engines to read, quote, and trust. That work is built into the dashboard instead of left to a plugin.
The SEO screen groups the technical controls in one place, with direct links to the sitemap, robots file, product feed, and the llms.txt files, so the team can open and check them at any time.
Product FAQs stay visible as normal page text. FAQ rich-result markup is intentionally omitted from product pages because Google now limits FAQ rich results to a small set of sites, and product data is more important on those pages.
What is in place
- Clean addresses. Readable slugs, with a permanent redirect created when a slug changes.
- On-page controls. Title, description, canonical address, social image, and a noindex switch for every product, page, and post.
- Discovery files. A live XML sitemap, robots .txt rules, a Google Merchant product feed, llms.txt, and llms-full.txt.
- Structured data. Product and product group, offers, ratings, shipping, returns, and breadcrumbs.
- Brand entity. A form for alternate brand names, founder, slogan, Wikidata item, and official profile links, written into the organization markup together with a square logo.
- IndexNow. A panel that tells search engines when URLs change.
- Per-product check. A button that reviews the title, headings, image alt text, links, and canonical before saving, with no network call.
- WebMCP tools. Experimental browser tools for search, product details, add to cart, and view cart. No tool can finish an order or take payment.
Performance and caching
Speed settings the team can read and use
The Performance screen explains in plain words what the running build is doing, then gives the controls that go with it. Nothing there asks for a code change.
Shared page cache
Public pages are sent with headers that let shared caches hold them for about five minutes, while browsers still check back on every visit and keep the back button instant. Cart, checkout, account, login, order tracking, review, and admin pages are always private and never cached.
An environment switch turns the shared cache off if it is ever unwanted.
One-click cache purge
After a release or a big content change, one button clears the Next.js caches, the file caches, and, through the Hostinger API, the CDN. The actionrequiress an admin session, is limited to six runs every ten minute,s and is written to the audit log.
CSS and fonts
Stylesheets are served as fingerprinted files that browsers keep for a year. Inlining CSS into every page is available as an option, but the screen explains why external files are the better default.
Pre-encoded renditions
Images are delivered as AVIF in several widths with a long browser cache, while social preview images and the favicon stay in formats every platform can read. Ordinary image requests only read stored files, so browsing the shop never starts an encode.
Scheduled maintenance
An optional daily job, protected by a secret and off by default, removes expired sessions, used verification codes, old audit rows and stale rate-limit records in small batches.
Diagnostics
A health check reports the running version and database response time. Server errors and browser failures go to a rotating debug log that rolls over at 5 MB, so it cannot fill the disk.
Image storage
Images live in files, not in the database
Initially, uploaded images and videos were stored in MySQL. That is fine for a small shop, but by October 2026, the database had grown to about 328 MB, and nearly all of it was media. Exports stalled partway through the image data, and a cold image request meant a database read.
The media library now writes uploaded files to a folder outside the application directory, so a redeploy never touches them. The database keeps only the name, alt text, size, dimensions, a checksum, and the file location. Image and video addresses did not change, and video playback reads just the byte range it needs.
If a file ever goes missing while its database copy still exists, the store serves the copy and recreates the file by itself.
Moving an existing library
Three steps, in the Media screen
- Copy media to the folder. Each file is written, read back, and compared with its checksum before the row is considered copied. Nothing is deleted yet.
- Remove the database copies. Every file is checked once more. A missing or different file keeps its database copy.
- Shrink the tables. An optimize run gives the freed space back to the hosting quota.
A cleanup action can also remove files that no row refers to, but only when they are more than a day old.
API control
The APIs are switched and guarded from the dashboard
A store communicates with many external services. Each connection here has a settings screen, a clear on/off state, and limits on what it can do.
WebMCP token and tools
The WebMCP screen holds the Google origin-trial token. When the token is renewed, the team pastes the new one and saves it. No new build or deployment is needed, and the Disabled setting overrides all fallbacks.
The four tools it exposes are search products, get product details, add to cart and view cart. None of them can place an order, take a payment, or access an account.
Read-only product lookups
A small catalog endpoint answers product searches and product detail requests for agents and for the cart. It accepts reads only, checks its input, is rate-limited per visitor, and is marked private so no shared cache keeps the answers.
Hostinger API
The Performance screen shows whether the Hostinger API token, account, and cache domain are set, and whether the site runs as web hosting or an agency website. With that in place, the purge button reaches the CDN directly. Automatic purging after every save stays off unless the team decides otherwise.
Guards around every call
Admin actions need a signed-in session and a same-origin request. Public forms and lookups have rate limits, and scheduled jobs authenticate with a bearer secret that never appears in a URL. Secrets live in server environment variables, a strict content security policy lists the hosts allowed to load or receive data, and admin changes are written to an audit log.
Under the hood
How it was built and checked
SadaPure runs as one Node.js application on Hostinger. The storefront and the dashboard are part of the same Next.js project, but the dashboard is protected by its own authentication and is excluded from indexing and caching.
Before a release goes out, the project runs a dependency check, type checking, linting, unit and integration tests, and a verification pass over the finished build. Database and real-time checks need real services, so they are performed on the deployed site after each upload.
Why not WooCommerce or Shopify? Both are good products. We picked a custom build because SadaPure needed its own checkout rules, its own order exports, and tight control over what loads on a page. The trade-off is that a custom store requires a team to maintain it, and that is part of what Ozairwebs does.
Technology
- Next.js 16 with the App Router, and React 19
- TypeScript across the storefront and the admin
- Node.js 22 on Hostinger's Node.js hosting
- MySQL for catalogue, content, settings, orders and customers
- sharp for AVIF and WebP image processing
- Nodemailer for order and verification emails over SMTP
- ExcelJS and docx for the Excel exports and Word labels
- Meta Conversions API, Google tag and WhatsApp Cloud API for tracking and messaging
Questions people ask
SadaPure, answered in plain words.
Who built the SadaPure store?
Ozairwebs designed and built it: the Next.js storefront, the database design, and the admin dashboard. The SadaPure team owns the products, prices, orders, and content.
Why is SadaPure called the best Next.js ecommerce store in Pakistan?
It is our own description, and here is what it rests on. The store is written for one business instead of adapted from a template; it keeps ad tracking behind a consent manager; it serves pre-encoded images; and its dashboard covers orders, SEO, caching, and integrations without plugins. You can test the speed and the markup yourself on sadapure.com.
Does SadaPure accept online payments?
Right now, orders are paid on delivery. The checkout shows only the payment methods that are actually available, so it does not list cards or wallets that cannot be used.
Where are the product images stored?
In files on the server, in a folder outside the application. The database only holds each image's details and file location. That keeps the database small and makes backups and exports far less painful.
How does the store treat visitor privacy?
One consent manager sits in front of Google Ads, GA4, and the Meta Pixel. Google runs in a deny-by-default consent mode, and the Meta Pixel loads only after the visitor consents to advertising cookies. The owner can change the wording, duration, and regional rules from the dashboard.
Can a non-technical team run the dashboard?
Yes. Products, orders, deals, menus, the homepage, and the tracking tags are all forms and buttons. Small visual changes go through a Custom CSS screen, so the team rarely needs a developer for routine work.
Can Ozairwebs build a store like this for my business?
Yes. We would start with your catalog, your delivery and payment rules, and the tools you already use, then agree on what the first release must include. A store with a comparable structure can usually reuse the approach, while the checkout, content model, and integrations are customized to your operation.
Can the dashboard be extended later?
It can. New screens are added to the same project, so they share the login, the audit log, and the caching rules. Each change is tested against search, speed, and checkout before it goes live.
More case studies
See how we approached other platforms and industries. All case studies
Next.js CMS · Apparel manufacturing
DEAL N TRADING
A B2B website and custom CMS for a Sialkot apparel manufacturer: product catalogue, quote requests with email verification and AVIF image delivery.
Read the DEAL N TRADING case study
WordPress · Engineering consultancy
FIRETECH Life Safety Consultants
A structured corporate website for a fire and life safety consultancy: 12 NFPA-referenced service pages and a clear consultation path.
Read the FIRETECH Life Safety Consultants case study
Next.js · Public information tools
Renters Rights Toolkit
An independent UK renting platform with free checkers, letter templates and plain-English guides for tenants and landlords.
Read the Renters Rights Toolkit case study- 01
Tell us what you sell
- 02
Agree the first release
- 03
Build, test, launch
Want a store like SadaPure?
Tell us what you sell and how you deliver it.
Send a short note with your products, your delivery and payment rules, and any tools you already use. We will reply with a plan for the first release and the questions we need answered before we quote.
Start a conversation