Software for Peptide & Research Supply Companies

Two brands, two domains, one backend

Operators in this space rarely run one brand for long. A second launches to reach a different buyer, or to keep a wholesale line separate from a retail one. The default answer — stand up a second site — doubles the hosting, doubles the admin logins, and guarantees the two catalogs drift apart within a quarter.

We resolve brand at the request. The hostname decides which brand a visitor is on, and that decision is made server-side before any page renders: which logo, which palette, which catalog, which certificate library, which order-number prefix. One codebase, one database, one bill.

The part that matters for correctness is that the brand is never taken from anything the browser sends in a form. It is derived from the host and passed to the order routine directly. A customer cannot land on one brand and have their order recorded against the other, because the client is never asked.

This also means the two brands are genuinely separate where it counts. The same compound can carry a different price, a different blend composition and a different certificate on each brand — because they are different products that happen to share a name, and the system treats them that way.

Why certificates break before anything else

Certificate of analysis handling is the first thing that fails on a migrated store, and it fails silently. A catalog is imported, certificates are matched by product name, and two products from different suppliers that share a compound name end up pointing at the same file. The page renders. The link works. The document is wrong.

Nothing in a generic e-commerce platform will catch that, because as far as the platform is concerned a file was attached to a product and the attachment succeeded. The failure is invisible until a customer reads the batch number.

We scope certificates per brand and bind them to batch identifiers rather than display names. When a brand genuinely has no certificate for a product, the page says so plainly instead of falling back to the nearest match. An honest gap is recoverable; a confident wrong answer is not.

The dose problem nobody mentions until migration day

In almost every store we have taken over, strength was never structured data. It lived inside the product name — and the dedicated dose field held a placeholder, or a count, or the literal string "n/a".

That is survivable while a human reads every line. It stops being survivable the moment you want products sorted by strength, a dose family grouped on one card, or a reorder rule that knows the difference between a 2mg vial and a 10mg one.

Parsing it back out is harder than it sounds, because the same field has to reject the concentrations that look identical to a strength. A 30ml premix labelled per-millilitre is not a 20mg product, and a parser that cannot tell them apart will mislabel a whole category with total confidence.

So we centralise it in one place, anchor the patterns, and make the catalog carry strength, count and format as real fields. Then sorting, filtering and family grouping work — and keep working when a new strength is imported.

Replacing a store that is already live

Most of this industry's builds are migrations, often under time pressure and sometimes without cooperation from whoever holds the current system. The order matters.

1. 1

   Mirror everything first

   Before touching anything, we take a complete copy — catalog, pages, media, certificates, brand assets. If access is about to be lost, it gets lost after the mirror, not before.

2. 2

   Rebuild the catalog as structured data

   Products are re-imported with strength, count, format and category as real fields rather than whatever the old export happened to put in them. This is the step that decides whether the next two years are pleasant.

3. 3

   Re-bind certificates to batches

   Every certificate is re-attached by batch, scoped to the brand it belongs to. Anything that cannot be matched is marked available on request rather than guessed at.

4. 4

   Stand the storefront up on your infrastructure

   New repository, new hosting, new database — all under your accounts. You hold the keys from day one, which is usually the entire reason the call happened.

5. 5

   Wire checkout and fulfillment

   Payment methods, shipping rules, order numbering, tracking and notifications. Payment recipients are configuration, never code, so they can be changed without a deploy.

6. 6

   Cut the domain over

   The switch happens when the new store is verifiably correct, not when the calendar says so. Both brands in the August 2026 build went live before the old sites finished going dark.

About payment processing, honestly

Processor access is the least stable part of this industry and the part we get asked about most. Nobody can promise you a permanent merchant account, and any vendor who does is selling you something.

What software can do is make the answer cheap to change. We put every payment method behind one interface, keep credentials and recipients in environment configuration rather than in code, and design checkout so adding or removing a method is a settings change.

That way losing a processor costs you an afternoon instead of a rebuild — and you are never in the position of having a working store you cannot take money through.