Creating an own Webshop - Part 1

4 minute read

This is part one of a series of articles about building my own webshop. I’m listing my requirements and wishes for my e-commerce solution. This way I narrow it down to a few suitable software solutions that I could later use for my webshop.

What my webshop needs to be able to do

For me as owner, the webshop should operate as lean, transparent, and automated as possible. I want to spend little time on operation, maintenance, and support. Payment processing, order status management, customer registration, sending customer information, and a large number of steps in the shipping process, such as postage and entering shipping confirmations, should be automated or at least prepared for automation.

But the webshop must also be structured in a way that is understandable for customers: simple and with just a few clicks from the homepage to checkout, easy to use, similar to other common webshops, with straightforward payment processing. As little data as possible should be collected from the customer.

My webshop only needs to display a few products. Therefore, navigation can be kept very simple. Due to the small number of product categories, a tree structure may be completely avoidable.

Let’s take a detailed look at what features the web shop ultimately needs to provide.

Functions for Admins

  1. Create a product
    • Title
    • Tags
    • Short description
    • Description
    • Images
    • Videos
    • Price
    • Profile / Data sheet / Instructions
  2. Edit a product
  3. Remove a product
  4. Manage orders
    • Confirm a step
    • Restart a step
    • Cancel a process
  5. Manage customers
    • Create (sandbox)
    • Delete (data protection)

Functions for Buyers

  1. Browse the webshop
  2. Configure product(s) or select product variants (e.g., color, quality)
  3. Add product(s) to a shopping cart
  4. Manage shopping cart
  5. Register (optional, only for customer data storage and order management)
  6. Select shipping
  7. Make a payment

Automatic functions

  1. Payment registration
  2. Invoice creation and dispatch
  3. Inventory management
  4. Shipping notification

Non-functional Requirements

Here I list everything the web shop should be able to do “on the side.” Things that are not directly required for order processing or visible to customers.

Usability on the Operator Side

  1. The shop should have as few dependencies on third-party software as possible and only integrate those modules that are absolutely necessary. Examples:
    • Payment processing
    • Shopping cart
    • Customer account / address data
    • Inventory
    • Order processing (mailer) for buyers
    • Invoicing.
  2. The shop should only contain as many dynamically generated elements as absolutely necessary.

Usability on the Buyer Side

  1. The web shop should feel like current, common e-commerce solutions: nimble, clear, simple.
  2. No obligation to have a customer account.
  3. The shop should support common payment methods (debit, credit, PayPal, Apple/Google Pay, etc.). Only local (German-based) payment service providers are acceptable.
  4. Inventory levels and production times should be displayed transparently for the user.

Data Protection

  1. The shop should only collect data necessary for business transactions.
  2. If technically and legally possible, the shop should be able to operate without a cookie banner.
  3. Customer accounts should be automatically deleted after two years of non-use (with two weeks’ notice).

Look & Feel

Here are some examples of successful, simple shop designs:

Requirements derived from this:

  1. The web shop’s structure and color scheme should match my Blog page and provide a consistent look.
  2. Only static fonts should be used without reloading.
  3. Product descriptions should be able to be uploaded as Markdown documents (or similar).

Database or file solution?

It doesn’t always have to be a database. For many applications, only a fraction of the functionality of common database solutions is required, but this significantly increases the complexity of the overall system. For example, if concurrent writing rarely or never occurs and there is no strong data concatenation, a file solution can be simpler, faster, and more efficient Linking a related “Engineering Kiosk” podcast episode.

On the other hand, many shop systems come with batteries included, meaning they already have built-in data management that is almost transparent to the programmers.

File solution (static website)

  1. From the operator’s perspective, the web shop should feel like a Git project (everything is a file).
  2. Changes to the offer, item descriptions, prices, etc. should be able to be pushed to the server via git push – just like with a static website.
  3. If a pull request is merged into ‘main’, the web shop should be rebuilt (CD pipeline) and the changes published to the server.
  4. Dynamic elements are required for inventory management, shopping carts, customer interaction, and automated functions. Here, it is important to decide which elements are best handled directly in JavaScript and which are better handled via an automation pipeline.

Database solution (dynamic website)

  1. Products are stored in the database.
  2. The web shop is managed via a web interface.
  3. Database management should be partially automated, with backups and encryption for customer data provided.
  4. The database is transparent for the admin: There is no direct interaction; everything is channeled through e.g. a web interface.

In the next article

Comparing e-commerce solutions for my webshop

You may also enjoy