Ayurvexa

Joining Dcrayon's multi-brand Laravel platform

The choice was between rebuilding Ayurvexa as a standalone WordPress or Shopify store, or adding it as one brand (a tenant) on Dcrayon's existing Laravel 12 platform. A standalone rebuild would have meant setting up checkout, courier booking, order emails and an admin panel again from nothing. The shared platform already ran those for other brands, so Ayurvexa joined it, and only the parts that are specific to a supplement brand had to be built. This sits within our custom web application work.

The platform uses the stancl/tenancy package. Every request is matched to a brand by its domain before any route runs, and requests to the central domain cannot reach a brand's pages. A central database holds the tenants and their domains, and each brand gets its own database for products, customers, orders and settings. Each brand's branding (name, logo, favicon and colours), business details (support contacts, GST number, legal name and address) and integration settings for payments, shipping, WhatsApp, Instagram, the Meta Pixel and GA4 are stored per brand, never in shared code. Files are stored per brand too: a tenant image service writes products, branding, banners and content images into that brand's own folder.

Fitting the layout to five products

Two commits on 6 Apr 2026 adapted the shared homepage. The category carousel now appears only if at least one category holds more than five products, which hides it on Ayurvexa, and when there are six or fewer featured products the grid centres them instead of leaving gaps. Brands with their own navigation get the logo on the left. A header ticker carrying Ayurvexa's offer lines, split on a separator in the theme settings, was later limited to Ayurvexa alone.

The platform resolves views in three layers: a brand's own view folder first, then the default storefront, then the core views. Ayurvexa had its own home page, product page and checkout views, with its own CSS and JavaScript, while everything else came from the shared storefront. A console command, ayurvexa:create-combos, built the five combination packs: each pairs two products, adds up their MRPs, prices the pair below the two bought separately, copies the first product's image and categories, and refuses to run outside the Ayurvexa tenant. Combos are stored as ordinary products, so they use the same cart, stock and checkout as the single supplements. Products can also carry a "Choose Your Pack" configuration, which the product page shows as pack options.

Redirects that kept WordPress links alive

On 17 Apr 2026 about 20 explicit permanent (301) redirects were added for old WordPress addresses; a 301 tells search engines a page has moved for good. The product route then works in order. A deleted product returns a 410 status, which asks search engines to drop the address instead of retrying it. An old product slug from a map of WordPress-era names, such as liver-support or coq10, redirects permanently to the current product. Anything else is matched by keywords from the slug against active product names. A fallback route at the end of the routing table applies the same 410 and keyword logic to any address no route recognises. When we checked on 13 Oct 2026, /products/liver-support and /products/coq10 both redirected to the current product pages. Redirect planning of this kind is part of our technical SEO service.

BMI calculator and free consultation booking

The BMI calculator page exists only on Ayurvexa: the controller returns not-found for every other brand on the platform. It takes weight in kilograms and height in feet and inches, and places the result in a band from underweight through to obese class II and above.

The free consultation form asks for a name, an email address, an Indian mobile number (checked against the pattern for ten-digit numbers starting 6 to 9), the product or concern the visitor is interested in (energy and stamina, liver health, skin radiance, nutrition and immunity, or heart health), a preferred date and an hourly time slot, and a question of up to 2,000 characters. Each request is saved in the store's enquiries table with the subject "Free Consultation Request" and emailed to the brand's team, and the form accepts no more than five submissions a minute from one visitor. A promotional banner on the home page can open the same form as a pop-up when the brand switches consultations on in its theme settings. A fix on 23 Apr 2026 removed hard-coded wording from the consultation email so that it reads correctly for this brand.

Razorpay, full prepaid and partial cash on delivery

Checkout only accepts a payment method from a fixed list, which covers cash on delivery, partial pay, Razorpay and UPI alongside the platform's other gateways. Guest phone numbers must be valid Indian mobile numbers, a saved address must be a valid stored address, and checkout is limited to ten attempts a minute.

For Razorpay payments, the signature Razorpay returns is checked with a constant-time comparison before the order is confirmed. Razorpay's webhook is verified against the raw request body with HMAC-SHA256 in middleware, before the controller sees it. Orders are matched to Razorpay by their Razorpay order ID and payments are written with an update-or-create, so a repeated notification updates the same record instead of creating a second one.

Partial cash on delivery takes an advance through the primary gateway. The advance amount is a store setting, the order records the advance and the balance due separately, and the payment is marked paid only when the amount received covers the full total. In late April 2026 the admin order views were updated to show what has been paid, what is still due on delivery and any refunds, and gaps in Ayurvexa's order emails were closed. This is the checkout side of our e-commerce solutions.

Keeping each brand's caches and emails separate

Separation needed checks beyond the database. Cache keys for settings and cached pages carry a tenant prefix. On 27 Apr 2026 the Instagram reels cache was made brand-specific, after Ayurvexa reels appeared on another brand's store; the key now includes the tenant ID. On 30 Apr 2026 the configuration bootstrapper, the code that loads a brand's settings at the start of each request, was changed to forget any mailer it had built for the previous brand, to clear any setting a brand does not define rather than inherit it, and to send through a brand's own mail server only when that brand has one, otherwise using the platform's mail server with the brand's address as the reply-to. Continuous integration also checks that no brand name is hard-coded into shared code.

Blade components and Alpine stores on the storefront

The storefront is server-rendered Blade with Alpine.js for interactive parts and Tailwind CSS, built with Vite. Reusable Blade components run from small to large. Small ones include alerts, inputs, the logo, breadcrumbs, trust badges and the WhatsApp and Instagram buttons. Mid-sized ones include modals, the product card, the FAQ section and the product structured-data block. Large ones include recently viewed, similar products, recommended products, the Instagram reels strip and the exit-intent pop-up. Layouts cover the storefront, checkout, guest pages and the admin panel.

Shared state lives in Alpine stores: cart for the basket, wishlist for saved items, toast for short messages, authModal for sign-in and registration, pdpPack for the pack selector on product pages, and freebie, which reads the cart and shows how far the shopper is from a free gift. Reusable Alpine components handle accordions, drop-downs, image galleries, modals, quantity selectors, search and tabs, with igReels running the reels strip and bmiCalculator running Ayurvexa's BMI page.

Structured data, sitemaps and product feeds

Product pages publish structured data for the product, brand, offer, shipping details and delivery time, the regions shipped to, the return policy, FAQ answers, the breadcrumb trail and the organisation. The sitemap index lists separate sitemaps for pages, products, categories, brands and blog posts, and is cached for an hour. A Google Merchant Center feed carries each product's ID, title, link, images, availability, price and sale price, brand, identifiers, Google product category, shipping and return policy labels, and a separate catalogue feed serves Meta. The robots file keeps private areas, such as accounts, checkout and administration, out of search. A newsletter sign-up offers a first-order code, with its own limit of five submissions a minute.

Admin access, sign-in limits and security headers

The admin panel uses its own authentication guard, requires two-factor authentication and records an audit trail of admin actions. Staff roles (manager, cashier, support and warehouse) are mapped to the admin sections each may open, such as orders, catalogue, customers, marketing, content, reports and settings. Platform-wide super administration sits on a separate guard in the central application. Repeated failed sign-ins lock further attempts for a period, keyed on the visitor's IP address and the email used. Forms are protected by Laravel's CSRF tokens (cross-site request forgery protection), and webhooks are verified by signature instead.

A security headers middleware runs on every response. A header request on 13 Oct 2026 showed HSTS (HTTP Strict Transport Security) for one year with subdomains and the preload directive, frame blocking, content-type protection, a strict referrer policy, a permissions policy that turns off the camera and microphone and limits location to the site, and a cross-origin opener policy that still lets payment windows open from checkout.

Delivery and checks on a shared codebase

Changes were tracked as commits and pull requests in the platform repository. The continuous integration pipeline compiles every Blade view, validates routes and configuration, checks that Blade directives are balanced, runs the brand-name check, builds the front-end assets and runs a dependency audit and a secret scan.