Kerfume.
A client commerce build. Storefront, checkout, admin, email, rewards, stock, SEO and tracking in one owned operating layer, so the brand is not renting a separate app for every function.
Client engagement. Written up with Kerfume's consent. This is their result, not a modelled internal example, and not a guarantee for other brands.
What was built
Owned operating layer
Storefront, admin, checkout, email, rewards, stock, SEO and tracking.
What it affects
The system behind the store
App spend, admin workload, tracking, stock, email, product data.
What they saved
£4,000+ a month
Operating cost after the build, confirmed by Kerfume. Not a revenue guarantee.
What this shows
A client system that scales
Catalogue and order volume can grow without a matching rise in rented apps.
Kerfume confirmed a £4,000+ monthly operating-cost saving after the Baraka Hall build, versus the app-heavy stack it replaced.
That figure is this client's operating cost, not a revenue claim, and not a promise that every brand will save the same amount. Actual savings depend on the stack you rent today.
The architecture is built to scale. More SKUs, more orders, and more staff seats do not require a matching rise in monthly app fees. Pricing, stock, checkout, feeds and admin read from one source of truth.
The Baraka Hall build cut more than £4,000 a month from our operating stack. It is our system. It scales as we grow, without adding another app each time the catalogue does.
A client build, published with consent.
Kerfume is a premium fragrance brand and a Baraka Hall client. This write-up records the commerce infrastructure decisions made for them: storefront, schema, checkout, recovery flows, and an admin built around how their operations team actually works.
The operating desk for the brand, not a generic CMS surface.
Pricing, inventory, customers, rewards, affiliates, support, outreach, and SEO files are all managed from one place. Permissions are set per staff member, and every sensitive action is logged.
This can consolidate functions often spread across multiple apps in a typical app-heavy setup, while keeping storefront, checkout, feeds, and structured data reading from a single source of truth.
- Pricingcascades to checkout, feeds, JSON-LD
- Inventorystates tuned for online luxury
- Customersorders, rewards, support, email log
- Orderstemplates, carriers, refunds
- Emailin-context sends with delivery log
- Rewardstokens, coupons, abuse rules
- Affiliatestiers, commission, holds
- SEO filesllms.txt, robots.txt, feeds
- Permissionsper-feature staff access
- Audit logevery sensitive action recorded
What the admin actually does.
Single operating desk
One sign-in for orders, customers, inventory, rewards, support, outreach, and SEO.
Pricing that cascades
Set prices at category level, override at SKU. Storefront, checkout, and feeds all read the same source.
Inventory states
In stock, low stock, sold out, pre-order, hidden. No physical-shop noise.
Customer view with full history
Orders, support threads, rewards, coupons, email log, and affiliate status on one screen.
Email actions in context
Send verifications, founders reminders, and order updates from the customer record. Delivery is logged.
Granular staff permissions
Admins see everything. Moderators get only the surfaces they need, per feature.
Editable SEO and AI files
llms.txt, robots.txt, sitemap signals, and product feeds are managed from admin.
Order operations
Saved templates, carrier and ETA fields, refunds, and customer-facing status messages.
Rewards and affiliates
Token economy, coupons, tiers, commission holds, and abuse rules without engineering.
Audit trail
Affiliate changes, order updates, admin emails, and file edits are all logged.
Why this architecture is different.
Compared with a typical app-heavy stack, this architecture keeps more logic in one owned system. Framed as architectural advantages, not a platform comparison.
- Data modelPatchwork of tools, each with its own schema and billing.One schema for catalogue, customers, orders, rewards, and support.
- Pricing source of truthPublic price, sale price, app price, and feed price can drift.Storefront, checkout, feeds, and JSON-LD resolve from one pricing layer.
- Checkout and conversionsClient-side pixels can double-fire and miss refunds.Server-verified webhooks and deduped, server-side ad conversions.
- Fully discounted ordersOften needs a workaround or a paid app.£0 orders write the order, decrement stock, and still log a conversion at value 0.
- Reward and coupon logicSits in a separate loyalty app with its own webhook timing.Account-bound coupons validated inside the same checkout function.
- Multilingual structureBolted on per surface, often per app.Language-prefixed routes, hreflang, and per-locale email rendering by design.
- Admin surfaceTheme-customised generic admin.Purpose-built admin with permissions, audit log, and operator templates.
- Security modelRole flags spread across app records.Roles in a dedicated table, default-deny RLS on PII, hashed OTPs and reset tokens.
- Recurring app dependencyPer-app monthly fees and version lock-in.Reduced app dependency. No per-app tax on growth.
- Data ownershipData and templates live across third-party tools.Database, email templates, feeds, and conversion pipeline are owned and portable.
This can consolidate functions often spread across multiple apps in a typical app-heavy setup, while keeping a single source of truth for pricing, inventory, customers, and conversions.
How this affects the business.
Less dependency
Fewer critical workflows spread across separate dashboards.
More operator control
The team can manage products, emails, customer records, and updates without waiting for a developer for every small change.
Clearer tracking
Checkout and conversion events can be verified from server-side events where scoped.
Cleaner recovery
Abandoned carts, refill reminders, win-back flows, and customer messages can be managed from the same operating layer.
Better handover
Documentation, admin access, and operating rules are part of the build, not an afterthought.
More portable data
The brand keeps more of its logic, content, and data in an owned structure.
Data needed to prove savings.
Before claiming savings, Baraka Hall needs the real operating numbers. Impact is modelled during audit, then measured before it is claimed.
- Current platform plan
- Monthly app spend
- Transaction fees
- Developer or support costs
- Current order volume
- Average order value
- Abandoned checkout volume
- Email list size
- Current recovery flows
- Current admin tasks
- Staff time spent on manual work
- Current SEO and analytics setup