Key takeaways
- Compare a working business system, not just a theme or page count.
- Separate one-time implementation from recurring infrastructure, licences and support.
- Lot evidence, payment changes and migration can materially change the scope.
- Require named account owners and testable acceptance criteria in every quote.
- Peptide Website charges for a one-time build; clients pay providers directly, with no platform fee to us.
What are you actually buying?
The useful answer to “how much does a peptide website cost?” starts with scope, not a headline figure. A theme changes how pages look. A working research-use-only business system also connects products, variants, inventory lots, laboratory evidence, checkout, fulfilment and communications. Two quotes can describe a “complete store” while including very different responsibilities. Compare the outcome you can operate, not the number of pages in a presentation.
For a small catalog, loading a handful of product descriptions may be straightforward. Loading variants, specifications, multiple historical lots and independent COA reports is a different job. Migration adds another layer: preserving customer records where appropriate, mapping URLs and validating stock. Use the technical launch checklist to define the work before requesting quotes, then separate implementation costs from the bills that continue after launch.
Map every cost component
Ask each builder to complete the same cost inventory. “Usually pays” below describes common commercial arrangements, not a universal rule. Your agreement should identify the account owner, the billing recipient, the included quantity and what triggers additional work. A provider subscription paid directly by you is still part of the operating cost, even when it is not on the agency invoice.
| Component | One-time or recurring | Who usually pays | What to ask |
|---|---|---|---|
| Design / theme | Initial setup; later revisions | Client through builder or theme vendor | Custom design or configured theme? Which templates and revisions? |
| Catalog loading | Initial import; ongoing updates | Client or internal catalog staff | How many products, variants and specifications are included? |
| Lot and COA records | Initial setup; each new lot | Client or catalog staff | Separate lot records, historical reports and public lookup? |
| Copy compliance review | Launch review; continuing reviews | Client through builder and qualified advisers | Which surfaces are checked, and who approves final wording? |
| Checkout / processor integration | Setup; provider charges continue | Client through builder and payment provider | Which approved provider is connected, and who handles changes? |
| Taxes / shipping setup | Initial configuration; later changes | Client; service charges may recur | Which zones, rules, tax engines and test cases? |
| Email / domain authentication | Setup; sending and domain renewals | Client to sending and domain providers | Who configures SPF, DKIM and DMARC, then checks delivery? |
| Email marketing platform | Setup and recurring service | Client to selected service | Which lists, consent records and workflows are connected? |
| Server-side conversion tracking | Setup; monitoring and service costs | Client through builder and providers | Which events, consent checks and deduplication? |
| Migration / 301 redirects | Migration project; follow-up checks | Client through builder | Which data and old URLs are mapped and tested? |
| Hosting | Recurring | Client to hosting provider | Whose project is it, and what usage affects billing? |
| Database | Recurring | Client to database provider | Who owns it, exports it and tests recovery? |
| Media storage | Recurring | Client to storage provider | Are COA PDFs and product media included in usage estimates? |
| Apps / plugins / licences | Often recurring; some one-time | Client to vendors or through builder | List every dependency, renewal and transferable licence. |
| Maintenance / security updates | Recurring or scheduled projects | Client or contracted maintainer | Who patches, tests updates and responds to failures? |
| Support | Defined window or optional ongoing | Client through support provider | What is covered, how is it requested, and when does it end? |
Design / theme
One-time or recurringInitial setup; later revisions
Who usually paysClient through builder or theme vendor
What to askCustom design or configured theme? Which templates and revisions?
Catalog loading
One-time or recurringInitial import; ongoing updates
Who usually paysClient or internal catalog staff
What to askHow many products, variants and specifications are included?
Lot and COA records
One-time or recurringInitial setup; each new lot
Who usually paysClient or catalog staff
What to askSeparate lot records, historical reports and public lookup?
Copy compliance review
One-time or recurringLaunch review; continuing reviews
Who usually paysClient through builder and qualified advisers
What to askWhich surfaces are checked, and who approves final wording?
Checkout / processor integration
One-time or recurringSetup; provider charges continue
Who usually paysClient through builder and payment provider
What to askWhich approved provider is connected, and who handles changes?
Taxes / shipping setup
One-time or recurringInitial configuration; later changes
Who usually paysClient; service charges may recur
What to askWhich zones, rules, tax engines and test cases?
Email / domain authentication
One-time or recurringSetup; sending and domain renewals
Who usually paysClient to sending and domain providers
What to askWho configures SPF, DKIM and DMARC, then checks delivery?
Email marketing platform
One-time or recurringSetup and recurring service
Who usually paysClient to selected service
What to askWhich lists, consent records and workflows are connected?
Server-side conversion tracking
One-time or recurringSetup; monitoring and service costs
Who usually paysClient through builder and providers
What to askWhich events, consent checks and deduplication?
Migration / 301 redirects
One-time or recurringMigration project; follow-up checks
Who usually paysClient through builder
What to askWhich data and old URLs are mapped and tested?
Hosting
One-time or recurringRecurring
Who usually paysClient to hosting provider
What to askWhose project is it, and what usage affects billing?
Database
One-time or recurringRecurring
Who usually paysClient to database provider
What to askWho owns it, exports it and tests recovery?
Media storage
One-time or recurringRecurring
Who usually paysClient to storage provider
What to askAre COA PDFs and product media included in usage estimates?
Apps / plugins / licences
One-time or recurringOften recurring; some one-time
Who usually paysClient to vendors or through builder
What to askList every dependency, renewal and transferable licence.
Maintenance / security updates
One-time or recurringRecurring or scheduled projects
Who usually paysClient or contracted maintainer
What to askWho patches, tests updates and responds to failures?
Support
One-time or recurringDefined window or optional ongoing
Who usually paysClient through support provider
What to askWhat is covered, how is it requested, and when does it end?
Do not accept “email included” as a substitute for specifying the work. Transactional sending, mailbox access, domain authentication and marketing automation are distinct. SPF and DKIM help authenticate messages; DMARC sets a policy and supports reporting. Correct setup does not guarantee inbox placement. Likewise, connecting a tracking endpoint does not establish that every event is accurate or that privacy choices are respected.
Three paths, three different bills
The platform decision changes where costs appear. Shopify can be fast to start and packages hosted infrastructure into its service. WooCommerce provides an owned, flexible software base, while you arrange hosting and maintenance. A custom system generally needs more implementation work upfront but can remove recurring platform rent to the builder. None of these paths eliminates payment-provider charges, domain renewals or the need to operate the business.
| Decision | Shopify + apps | WooCommerce + plugins | Owned custom build |
|---|---|---|---|
| Upfront effort | Hosted setup can shorten the initial configuration | Hosting, theme and plugin integration need coordination | Detailed scope, implementation and acceptance testing |
| Recurring costs | Platform subscription, selected apps and provider charges | Hosting, selected licences, services and maintenance | Hosting, database, storage, services and optional support |
| Dependency | Platform capabilities and app compatibility | Plugin compatibility and update process | Implementation quality and documented service integrations |
| Processor flexibility | Available third-party gateways and regional eligibility | Compatible gateways subject to provider approval | Provider interface where included; each provider still requires approval |
| Code and data | Platform code is not yours; assess available data exports | Own your installation and data; check extension licences | Contract must transfer code, data and client-controlled accounts |
Upfront effort
Shopify + appsHosted setup can shorten the initial configuration
WooCommerce + pluginsHosting, theme and plugin integration need coordination
Owned custom buildDetailed scope, implementation and acceptance testing
Recurring costs
Shopify + appsPlatform subscription, selected apps and provider charges
WooCommerce + pluginsHosting, selected licences, services and maintenance
Owned custom buildHosting, database, storage, services and optional support
Dependency
Shopify + appsPlatform capabilities and app compatibility
WooCommerce + pluginsPlugin compatibility and update process
Owned custom buildImplementation quality and documented service integrations
Processor flexibility
Shopify + appsAvailable third-party gateways and regional eligibility
WooCommerce + pluginsCompatible gateways subject to provider approval
Owned custom buildProvider interface where included; each provider still requires approval
Code and data
Shopify + appsPlatform code is not yours; assess available data exports
WooCommerce + pluginsOwn your installation and data; check extension licences
Owned custom buildContract must transfer code, data and client-controlled accounts
The platform decision guide examines these trade-offs in more detail. Shopify is not automatically the wrong choice for a research-use-only store, and custom is not automatically better. The right comparison is your actual workflow: evidence, purchasing conditions, editing, fulfilment and recovery when something fails. Ask for a demonstration using fictional products and sample lots rather than relying on a polished homepage.
Hidden costs research stores encounter
Processor changes and checkout rework
Shopify Payments may restrict peptide businesses; eligibility and alternatives must be checked for the region and exact business. The official eligibility guidance points to applicable regional terms. Other processors may restrict the category too. Choosing a platform before resolving the payment approach can create rework. A provider interface reduces the amount of storefront logic that changes, but connecting another processor is still a scoped integration with approval, testing and operational responsibilities. See the payment preparation guide before treating checkout as a finished line item.
Small dependencies that accumulate
An app for lot evidence, another for gates, another for redirects and another for emails can each be reasonable individually. Together they introduce renewals, permissions and compatibility checks. With WooCommerce, overlapping plugins can also complicate checkout updates. Keep a dependency inventory showing what each tool does, who owns the subscription and what happens if it is removed. Budget staff time for testing, not merely licence payments.
Migration and operational friction
A migration can damage discoverability when useful URLs disappear or redirect to unrelated pages. No builder can promise preserved rankings, but they can deliver a documented URL map and verify the redirects. Disputes create another hidden workload: searching messages, finding order evidence and checking dispatch records. Clear policies and accessible records can reduce avoidable confusion; they cannot remove chargebacks or replace the processor’s dispute process.
A twelve-point checklist for comparing quotes
Give competing proposals the same acceptance checklist. Require specific answers in writing, then identify exclusions separately. “Included” should mean that someone will configure and test the workflow, not merely that the platform could support it. Ask how changes to the catalog or scope are agreed so that a normal revision does not become an unexpected invoice.
- 1. Specify products, variants, specifications and media included in catalog loading, with import cleanup responsibilities.
- 2. Require separate lot and COA records, historical evidence and a working public lookup where that is in scope.
- 3. Identify every client-owned account: repository, deployment, database, storage, domain and sending service.
- 4. Define design deliverables, page templates, custom sections, preview access and revision boundaries.
- 5. List the copy surfaces reviewed and distinguish automated checks from qualified legal review.
- 6. Name the payment integration, approval responsibility, manual fallback and failed-payment tests.
- 7. Document shipping zones, tax rules, blocked destinations and order-attestation behaviour.
- 8. List transactional messages, domain authentication, marketing connections and consent responsibilities.
- 9. Specify tracking events, privacy handling and validation, rather than a generic analytics installation.
- 10. Include migration data, old-URL mapping, permanent redirects and post-migration link checks.
- 11. Require handoff training, written account inventory, export instructions and maintenance responsibilities.
- 12. State the post-launch support window, covered faults, exclusions and optional ongoing arrangement.
Then compare the proposals against a sample acceptance journey. A staff member should create a lot, attach its report, revise a product page, accept a test order, fulfil it and handle a refund. Include a failed payment and a blocked destination. This reveals gaps that a feature list misses and turns the quote into a testable deliverable. It also helps you distinguish work supplied by the builder from work retained by your own team.
Ownership is a financial question
An owned store is not a maintenance-free store. Code ownership is useful only when you can access the repository, deploy the application, export the database and understand the service accounts. Confirm what documentation and rights are transferred. A custom design with the deployment locked in an agency account is a different commercial arrangement from a complete handoff. The ownership model shows the accounts Peptide Website places in the client’s name.
Consider the cost of changing suppliers, too. Ask whether another qualified team can maintain the application without proprietary agency credentials. Document dependencies and access roles, revoke temporary access when appropriate and confirm how recovery is handled. Those practical details affect continuity more than a broad promise that “you own everything.” Your contract should distinguish ownership of delivered code from licences for third-party services or tools.
How Peptide Website scopes a build
Peptide Website has no public price list because catalog size, migration requirements and custom sections change the work. The commercial model is a one-time build deployed into your own accounts. You pay hosting providers directly, with no monthly platform fee to Peptide Website. Optional ongoing support is separate. Hosting, database, media, email and other service usage remain operating costs; “no platform fee” does not mean free infrastructure.
The build scopes provide a starting point for the conversation. Bring a catalog sample, the available lot reports, current store URLs and the checkout requirements already discussed with your provider. Identify what your team can supply and what needs implementation. The next step is to book a build call, compare a clear scope and decide whether the owned platform fits your business. Peptide Website builds software, not peptides, and cannot guarantee processor approval.
Frequently asked questions
Why is there no single price for a research peptide website?
Catalog size, variant complexity, lot records, migration, custom design and integrations change the work. Compare a written scope and continuing service responsibilities rather than a generic website label.
Does owning a custom store remove all recurring costs?
No. Hosting, database, storage, email, domains, payment-provider charges and optional support may continue. Peptide Website has no monthly platform fee to us; clients pay their service providers directly.
Can Shopify or WooCommerce be a sensible lower-scope option?
Yes, depending on the required workflow and maintenance capacity. Shopify offers hosted convenience, while WooCommerce offers installation control with update responsibilities. Confirm provider eligibility and evidence requirements before choosing.
What should I bring to a build call?
Bring a catalog sample, variants and specifications, available COAs, existing URLs for migration, intended destinations and payment-provider requirements. This makes the implementation scope and exclusions easier to compare.