MK Electrical Supplies
MK Electrical Supplies has been supplying electrical components to Australian trade for more than twenty-five years, out of a Sydney warehouse that ships nationwide. mkelectricalsupplies.com is a custom build rather than a hosted store: a Next.js storefront in front of a .NET Core application with PostgreSQL underneath.
Why not just use a platform
This is the question worth answering honestly, because for most retailers the answer is that you should. A hosted platform is cheaper, faster to launch and someone else's problem to maintain. We recommend exactly that to plenty of clients. It stops being the right answer when the catalogue does not fit the shape the platform expects, and electrical supply is one of the clearest examples of that mismatch.
A fashion catalogue has products with a handful of variants: size and colour. An electrical catalogue has the same nominal product existing across a dozen current ratings, conductor sizes, cable lengths, drum quantities and pack configurations, where two items that look near-identical in a list are not substitutes for each other and getting it wrong means a return, a delayed job and a phone call. Bending that into a generic variant structure produces either an unusable product page or thousands of orphaned SKUs. Owning the commerce layer meant the data model could follow the stock instead of the other way round.
Search built for someone who already knows the answer
The customer here is a qualified electrician, and they are not browsing. They are usually mid-job, they know what they need, and often they are holding the old part with the number printed on it. So search accepts a product name or a raw SKU, sits next to a category selector, and has a hide-sold-out toggle — because for a trade buyer an out-of-stock result is not a product, it is noise. Sorting is deliberately plain: default, price ascending, price descending. Nothing clever, because clever costs a click.
Around that sit the paths for the buyers who genuinely are shopping — the featured and bestseller rails, category entries for cables, lighting, switchgear, HDMI and monitors, security cameras and industrial lines, and a paged catalogue behind them. Two quite different behaviours, served without either getting in the other's way.
Operational promises as merchandising
Two facts decide a trade order more reliably than any banner: will it ship today, and what will freight cost. Same-day dispatch on orders placed before 2pm and free freight over $200 are therefore treated as merchandising rather than policy — surfaced where they change the decision, near the product and the cart, rather than buried in a shipping page nobody opens. Promotional pricing is scheduled in the backend rather than hand-edited into templates, so a 40% run on HDMI or 20% on security cameras starts and ends on its own.
Accounts, wishlists and a cart that survives between visits complete the picture, because trade buying is repetitive by nature. Someone who wired a job last month is ordering the same items again this month, and the store should remember that even if they do not. If you are weighing a custom build against a platform for your own catalogue, our e-commerce website service starts with exactly that question.
The SEO build
A catalogue this size makes search a structural problem rather than a copywriting one. The generated sitemap runs to more than 2,100 URLs — every category and product page — and is declared in robots.txt, because at that volume the difference between a crawler finding your catalogue efficiently and wandering it at random is the difference between products that rank and products that are effectively invisible. The title leads on the category the business competes in nationally, electrical supplies in Australia, rather than on the company name.
Structured data covers the Organization and its ContactPoint, plus a WebSite entity carrying a SearchAction — the markup that lets Google surface a search box for the store directly in results, which for a catalogue of this depth is worth more than it is for a small site. Nine Open Graph properties and the Twitter card set complete the sharing layer, so a product link pasted into a supplier email or a trade group renders with its image and title rather than as a bare address.
The Challenge Of Project
- Designing a product and variant model in PostgreSQL that matches how electrical stock is actually sold — by rating, length and pack — instead of forcing it into a generic platform's idea of variants.
- Making two very different customers work in one interface: the electrician searching a part number mid-job, and the buyer browsing a category with no number in hand.
- Joining a separately deployed .NET Core backend to a Next.js frontend so carts, accounts and pricing stay consistent without the storefront waiting on the API to render.
- Treating dispatch cut-offs and freight thresholds as merchandising rather than policy, since those two facts decide a trade order more often than any promotion does.
- Keeping a growing catalogue quick to filter, where a slow result set costs an order to a competitor who has the part in stock too.