An online store is a commercial operating system connecting catalogue data, stock, prices, checkout, payment, shipping, returns and customer communication.
Platform choice should follow decisions about the offer and operating model. An attractive shop can still fail operationally when product information, delivery rules or daily ownership are unclear.
This guide explains how to scope a new store, a rebuild or a migration without assuming a universal platform, price or timeline.
A dependable online-store project begins with operations, not a theme. Define what will be sold, where stock and product facts come from, who fulfils and supports orders, which markets are in scope and what must be legally reviewed. Then select the platform, architecture, integrations and delivery scope that can support that model. Cost depends on this complete system and on the work required after launch—not simply on the number of pages.
1. Decide whether you need a store, catalogue site or marketplace presence
Before commissioning checkout functionality, clarify the transaction the customer should complete. A general website development project may be enough when products only need explanation and enquiries are handled individually. A marketplace can validate demand or provide distribution, but it limits control over presentation, customer relationships and operating rules.
Online store
Suitable when customers should select products, provide delivery details, pay and receive structured order communication through a controlled storefront.
Catalogue website
Useful when prices or specifications require consultation, configuration, a quotation or eligibility checks before a contract can be formed.
Marketplace presence
Provides access to an existing audience, while platform rules, fees, data access and brand presentation remain external dependencies.
2. Define the business and operating model before choosing a platform
A small range held in one location has different data and fulfilment needs from made-to-order goods, subscriptions, bundles, regulated products or distributed stock.
- Offer: products, variants, bundles, services, subscriptions and known restrictions.
- Customers: consumer or business buyers, decision needs, service expectations and approved markets.
- Inventory: source of truth, reservations, overselling rules, locations and update frequency.
- Fulfilment: packaging, carriers, pickup, tracking, partial delivery and returns handling.
- Ownership: people responsible for products, prices, orders, support, finance and platform administration.
Record unknowns as decisions or hypotheses. Hidden assumptions create late changes and make offers difficult to compare.
3. Choose a platform by operational fit
Compare platforms against the operating model, not an isolated feature list. A hosted SaaS platform such as Shopify can reduce infrastructure ownership. Open-source software offers more freedom but transfers hosting, updates and security coordination to the project. Custom development needs validated requirements that established systems cannot serve responsibly.
| Decision area | Questions to ask | Evidence required |
|---|---|---|
| Catalogue and checkout | Can the model represent products, pricing, tax, customer groups and order rules? | Representative products and real order scenarios. |
| Integrations | Which systems must exchange stock, orders, customer or accounting data? | Documented interfaces, owners and failure procedures. |
| Operations | Can the team maintain the shop without permanent developer intervention? | Role map, workflows and training needs. |
| Change and exit | How are data exported, URLs preserved and dependencies replaced? | Data ownership, migration and continuity plan. |
4. Build a complete cost model
A quote becomes meaningful when cost categories and exclusions are visible. Compare total scope and ongoing responsibility, not a single launch amount. The broader marketing budget should distinguish the shop foundation from content, media, personnel and acquisition.
| Cost layer | Typical scope | Questions for the offer |
|---|---|---|
| One-off delivery | Discovery, architecture, design, setup, implementation, migration, testing and training. | Which outputs, revisions, approvals and launch activities are included? |
| Recurring platform | Subscription, hosting, apps, domains, support and maintenance arrangements. | Which dependencies continue, who contracts them and how can they change? |
| Transaction and external | Payment, logistics, tax or accounting services and other volume-dependent providers. | Which charges sit outside the development proposal? |
| Internal operation | Product updates, merchandising, support, fulfilment, returns, reporting and governance. | Who supplies the capacity and how is quality controlled? |
5. Prepare the inputs and project brief
A useful brief provides facts and decision rights. It must expose missing information and identify who can resolve it.
- Business objective, approved markets, target customers and success definitions.
- Product sample with variants, identifiers, dimensions, weights, prices, tax treatment and images.
- Brand assets, content rules, claims that require evidence and prohibited claims.
- Payment, delivery, pickup, return and support scenarios.
- Required integrations, available documentation, data owners and access constraints.
- Approval process for design, content, configuration, legal review and launch.
6. Structure the project into controlled phases
Phases create reviewable decisions. They are not promises of duration: catalogue condition, integrations, approvals and migration risk determine the real schedule.
Discovery
Confirm goals, operating flows, constraints, decision owners and evidence gaps.
Architecture
Define catalogue structure, navigation, data model, URL logic and integration boundaries.
Design and content
Build reusable templates and prepare the information required for customer decisions.
Implementation
Configure the platform, theme, checkout dependencies, apps and approved integrations.
Migration and population
Import, map, clean and verify products, customers, content and redirects where applicable.
QA and launch
Test end-to-end scenarios, resolve blockers, train owners and execute the release plan.
7. Design catalogue, variants and product information
Catalogue architecture affects customer choice, internal maintenance, search visibility and downstream feeds. Categories should reflect meaningful ways to browse rather than every internal label. Variants need consistent attributes, and identifiers must remain stable across stock, fulfilment and marketing systems.
Each template should define required facts, optional evidence, media standards and a responsible owner. The same discipline used for evidence-based SEO content helps prevent generic category copy, duplicated descriptions and unsupported product claims. Content must answer a real selection question and remain maintainable when the range changes.
Migration warning: do not import legacy data simply because it exists. Map fields, normalise values, identify missing media, retain necessary URLs and define a reconciliation report before moving production records.
8. Configure checkout, payments, shipping, tax and returns
Checkout turns commercial promises into system rules. Test ordinary and exceptional cases, not only one successful purchase.
| Area | Configuration questions | Operational test |
|---|---|---|
| Payment | Which methods, currencies, capture rules and failure states apply? | Successful, declined, cancelled and refunded transactions. |
| Shipping | Which destinations, rates, exclusions, carriers and tracking events apply? | Mixed baskets, remote areas, partial fulfilment and undeliverable orders. |
| Tax | Which registrations, product treatments and invoice requirements have advisers approved? | Representative baskets and destination combinations. |
| Returns | How are requests received, authorised, tracked, refunded and returned to stock? | Full, partial, damaged and non-returnable scenarios where applicable. |
Platform settings do not replace tax, accounting or legal advice. The business remains responsible for approved rules and for keeping them current.
9. Prepare the store for selling in Germany
Consumer-commerce readiness must be designed into pages, checkout and post-purchase processes. Under Section 312j BGB, paid consumer orders require specified key information to be presented clearly immediately before ordering, and the order control must communicate the obligation to pay unambiguously. The exact checkout implementation should be reviewed for the specific offer.
Section 356a BGB addresses an electronic withdrawal function for relevant distance contracts concluded through an online interface. Its placement, availability, wording, submitted information and confirmation process need both technical and legal review.
Accessibility scope also needs an explicit decision. Section 3 BFSG sets the general accessibility requirement and contains an exemption for microenterprises offering or providing services. This should not be assumed without checking the business and service. For covered e-commerce services, Section 19 BFSGV includes requirements relating to product or service accessibility information and to perceivable, operable, understandable and robust identification, authentication, security and payment functions.
Physical operations matter as well. The Central Agency Packaging Register explains packaging-law obligations for mail-order companies and online retailers, including LUCID registration and, depending on packaging, system participation and volume reporting.
Legal orientation only: this overview does not determine whether a rule, exemption or legal text applies to a specific store. Have qualified legal, tax and accessibility specialists review the actual offer, customer group, processes, providers and implementation before launch.
10. Plan multilingual and international selling
Adding a language is not merely translating navigation. Each market affects assortment, currency, prices, tax, delivery, returns, payment, support and legal information.
Commercial scope
Choose markets deliberately and document which products, prices, delivery methods and service levels apply.
Language adaptation
Localise product terminology, search demand, measurements, customer questions and transactional messages.
Operational ownership
Assign people to maintain translations, answer customers and approve changes across every active market.
Launch only the combinations the business can operate accurately. A visible language or destination creates an expectation that the complete buying and support journey works.
11. Test, measure and launch deliberately
The official Shopify launch checklist separates setup, organisation, testing, launch and later sales channels. That sequence is useful even when another platform is selected: a storefront should not go live merely because its design is complete.
- Test navigation, search, filters, variants, stock states and product information on relevant devices.
- Run successful and failed orders, refunds, cancellations, fulfilment and customer notifications.
- Verify consent behaviour, analytics events and the distinction between checkout activity and confirmed orders.
- Check redirects, canonical signals, indexability, metadata and monitoring for migrated URLs.
- Record launch owners, rollback conditions, support contacts and the first review point.
After the shop and product data are dependable, additional distribution can be considered. A separate guide explains Google Merchant Center setup and shopping feeds; it is a post-foundation channel, not a substitute for a reliable catalogue and checkout.
12. Define ongoing ownership and compare offers
Launch transfers the system into operations. Handover should cover access, configuration, supplier contracts, data definitions, routine tasks, monitoring, incident escalation and deferred decisions.
| Offer comparison | What should be explicit? |
|---|---|
| Scope | Templates, products, languages, integrations, migration, content, testing and training. |
| Responsibilities | Client inputs, provider outputs, approvals, legal review and third-party coordination. |
| Dependencies | Platform plan, themes, apps, licences, payment, logistics and external specialists. |
| After launch | Warranty boundaries, support route, maintenance, updates and improvement ownership. |
Common mistakes include choosing a theme before modelling products, treating data cleanup as an import task, leaving shipping exceptions until testing, assuming legal texts are automatically included and launching without named operational owners.
13. Frequently asked questions about online-store development
How much does an online shop cost?
There is no reliable universal amount. Cost depends on platform, catalogue condition, design system, content, integrations, migration, markets, testing, training and the boundary between provider work and internal work. Compare itemised scope, exclusions and recurring dependencies.
Is Shopify suitable for every business?
No platform fits every operating model. Shopify can reduce infrastructure work, but its data model, checkout options, app dependencies, plan features and integration limits must be tested against real products and workflows.
How long does development take?
Duration depends on decision speed, data readiness, content, integrations, migration volume, legal review and QA. A credible plan states dependencies and acceptance gates instead of promising a date before the scope is understood.
What must the client provide?
The client normally owns business rules, product facts, approved prices, tax and delivery decisions, policies, brand assets, system access, qualified reviewers and timely approvals. The proposal should assign every input explicitly.
Are legal texts and legal review included?
Only if the offer says so and identifies a qualified provider. Technical placement of supplied texts is different from drafting, tailoring or legally reviewing them. The same distinction applies to tax and accessibility assessments.
Can an existing shop be migrated without losing SEO value?
Migration risk can be reduced, not eliminated. Inventory current URLs, preserve valuable paths where possible, map redirects, retain relevant content and metadata, test internal links and monitor crawling and search performance after release.
What remains after launch?
Product and price maintenance, order handling, support, returns, stock reconciliation, provider updates, access control, analytics QA, accessibility and legal review, content improvement and incident response all require continuing ownership.
14. Conclusion: build the operating system, not only the storefront
A dependable store connects commercial scope, product data, checkout, fulfilment, compliance review and daily ownership. Platform selection becomes clearer when those facts are visible and proposals separate delivery, dependencies and ongoing work.
The best next step is therefore not choosing a theme. It is building a validated commerce brief with representative products, real order scenarios, named decision owners and explicit launch gates.
Need an online store planned around your real catalogue and operations?
Salestudia can structure the scope, platform decision, storefront, product architecture, integrations, testing and handover as one controlled project.
Plan your online store with SalestudiaEditorial note: the linked official sources were checked on 30 July 2026. Platform features, laws and regulatory guidance may change. This article is a planning guide, not legal or tax advice, and does not guarantee launch dates, search positions, sales or revenue.