Surfstock

Surfstock is an e-commerce site created to sell the remaining inventory from a former Danish surf shop. The catalogue includes specialist windsurfing, kitesurfing, SUP, and clothing products with irregular variants, large discounts, limited quantities, and different fulfilment rules depending on product size.

I owned the complete technical delivery, including the application architecture, product catalogue implementation, search and filtering, Snipcart integration, stock handling, deployment, maintenance, and the connection between the storefront and checkout. I worked with two UX collaborators on the initial design and usability testing.

Project overview

Surfstock transformed a physical remaining-stock problem into an online sales channel. The business had valuable products left after closing a former surf shop, but the inventory was too specialised and varied to be presented effectively through a simple listing or generic marketplace page.

The resulting website organised the stock into familiar surf categories, made discounted prices prominent, allowed visitors to search and filter the catalogue, and supported purchasing through Snipcart. Smaller products could be delivered, while oversized products required free collection in Frederiksberg.

The site is still available as a portfolio and product reference, but it is no longer actively maintained and purchasing has been disabled.

Context and my responsibility

I built Surfstock for a family-run business and was responsible for every technical part of the solution. Two UX collaborators contributed to the visual design, user flows, and usability testing during the initial development period. I translated their design work and the business requirements into the production application.

My responsibilities included choosing the technical approach, modelling products as content, implementing the responsive storefront, connecting product data to Snipcart, configuring stock behaviour, creating search and filter interactions, deploying to Netlify, and maintaining the live solution.

The project required close communication with people who understood the products and commercial constraints but did not need to make framework-level decisions. I therefore focused discussions on catalogue structure, stock, delivery, pricing, and the customer journey, then converted those decisions into technical behaviour.

The problem

Remaining stock is structurally different from a normal e-commerce catalogue. Many products were older models, available in only one or a few variants, and unlikely to be restocked. The product data was uneven, and the categories ranged from small accessories to large boards and sails.

The main user problem was discovery. A customer looking for windsurfing equipment needed to narrow a specialist catalogue quickly, while someone arriving from Google on a specific discounted product needed enough context and confidence to complete a purchase.

The fulfilment model created another constraint. Small products could be shipped, but large equipment could not use the same delivery flow and instead had to be collected in Frederiksberg. The website needed to communicate this difference before checkout rather than leaving it as a surprise after purchase.

Requirements and constraints

The solution needed to:

• Present a large amount of irregular remaining stock clearly.
• Organise products into specialist surf categories and subcategories.
• Support search and client-side filtering.
• Display original and discounted prices prominently.
• Handle product variants and limited stock.
• Prevent unavailable products from being purchased.
• Support delivery for smaller items and pickup for oversized equipment.
• Integrate a secure checkout without building a complete commerce backend from scratch.
• Be inexpensive to host and straightforward to maintain.
• Perform well enough for product pages to be discovered through search engines.

The business also needed a solution that could be launched without a long implementation period. Because the stock was finite, the architecture had to be proportionate: reliable enough for real transactions, but not burdened by infrastructure intended for a continually expanding retail operation.

Product and UX decisions

The catalogue structure followed the language of the surf market: windsurfing, kitesurfing, SUP, clothing, and their relevant subcategories. This allowed experienced customers to navigate through familiar product types without learning a custom taxonomy.

Discounts were a central part of the value proposition, so product cards and detail pages made both the original price and the reduced price visible. This communicated the reason for the shop’s existence immediately and helped users compare the remaining stock.

Search and filtering supported customers who knew either the exact product or only the category they needed. Fuse.js provided flexible text search, while Filterizr supported interactive catalogue filtering without requiring a server request for every selection.

The delivery distinction was kept visible. Smaller products could move through a standard delivery flow, while larger products were clearly associated with free pickup in Frederiksberg. This aligned the digital checkout with the physical limitations of the inventory.

The interface was designed and tested with the two UX collaborators. My role was to ensure the proposed flows remained realistic within Snipcart’s checkout model, the static content architecture, and the available product data.

Technical implementation

Surfstock is built with Astro, React, and TypeScript. Astro provides a fast content-oriented foundation, while React is used where the storefront needs richer client-side interaction.

Product data is stored as Markdown. This approach kept the catalogue close to the codebase, made individual products easy to edit, and avoided introducing a separate CMS for a finite stock inventory. The product files include the information needed to render category pages, details, pricing, variants, and commerce metadata.

Fuse.js powers text search, and Filterizr manages client-side filtering. Together they make it possible to browse a relatively broad specialist catalogue without introducing a larger search service or a custom backend.

Snipcart handles cart, checkout, transaction processing, product validation, and stock quantities. Keeping stock in Snipcart meant the commerce layer could prevent sold-out products from being purchased even though the public catalogue was generated from Markdown content.

Netlify hosts and deploys the application. The architecture kept operational complexity low while still supporting a real purchase flow, stock control, and product discovery.

Communication and collaboration

The most important communication task was converting physical inventory rules into a digital customer journey. The business described products in terms of brands, sizes, condition, and whether they could be shipped. I converted that knowledge into categories, fields, checkout metadata, and visible fulfilment information.

Working with the UX collaborators required another kind of translation. Their tests and interface proposals focused on what users understood, while I assessed how the design could be implemented in Astro and how it interacted with Snipcart’s constraints.

I also had to explain technical trade-offs to the business without making them choose between tools they did not know. For example, storing products as Markdown was presented as a maintenance and scope decision: it kept the finite catalogue manageable and the site fast without paying for or administering a larger system.

Results and current status

Surfstock generated real commercial results. Before the website had been formally launched, a customer discovered it through Google and early orders reached approximately DKK 10,000. The site continued to produce sales after launch, demonstrating that the catalogue, product pages, and checkout were functional in a real purchasing context.

The early organic sale also validated the importance of technically accessible product pages. The site did not depend exclusively on paid promotion or an existing marketplace to reach customers.

The remaining inventory project has since moved out of active operation. The website is still live, but it is no longer maintained and products can no longer be purchased. I keep it available because it documents the original catalogue and demonstrates a complete e-commerce implementation.

Lessons and retrospective

Surfstock taught me that commerce projects are shaped as much by fulfilment and stock rules as by the visible storefront. A polished product page is not enough if inventory, variants, shipping, and checkout do not describe the same reality.

The project also showed the value of selecting architecture according to business lifespan. A finite remaining-stock catalogue did not require a custom commerce backend or a complex editorial organisation. Astro, Markdown, and Snipcart provided an appropriate balance between performance, maintainability, and transaction support.

If I rebuilt the solution for an ongoing retailer, I would choose a more scalable product-management workflow and formalise inventory synchronisation. For this specific business case, however, the lightweight content architecture reduced implementation and maintenance overhead while still supporting real sales.

What this project demonstrates

Surfstock demonstrates my ability to deliver a commercial website from product data to checkout. It shows frontend development, e-commerce integration, search and filtering, stock and fulfilment modelling, deployment, collaboration with UX specialists, and clear communication with non-technical business stakeholders.