Kortreistved: hyperlocal firewood marketplace where the nearest supplier delivers

Kortreistved

Project Overview

  • Team

    Team

    • 7 people

  • Services

    Services

  • Technologies

    Technologies

    • React, Tailwind CSS, JavaScript

    • PHP, Laravel, MySQL

    • Flutter, Dart

At a glance

  • What it is

    A Norwegian online marketplace for buying firewood

    • Buyers enter their delivery address
    • The platform shows only products from suppliers who can deliver to that exact spot
    • Standard, group, pre-order, and B2B order types

  • How it works

    Every order is matched by coordinates, not zip codes

    • Neighbors can join group orders for a shared delivery
    • Businesses with multiple shops order on invoice through a separate B2B flow
    • Drivers run delivery routes from a mobile app

  • What Bluepes does on this project

    A dedicated team handles the full product cycle

    • Analysis, design, development, QA, releases
    • Embedded with the platform across multiple seasons
    • Knows the business, not just the code

About The Project

The platform connects local firewood suppliers with buyers and provides delivery nationwide.

  • Background

    Kortreistved is a Norwegian online marketplace for buying and delivering firewood. The platform connects buyers with local suppliers based on the buyer's exact delivery address — the closer the supplier, the higher the priority. The business is highly seasonal: autumn and winter carry peak demand, while spring and summer are used for new feature development and platform improvements that would be too risky to release during peak. The platform spans several connected surfaces — an admin panel, a supplier dashboard, a B2C webshop, a separate B2B webshop for chain customers, and a mobile app for suppliers and drivers. Most changes touch more than one surface, which shaped how the team organised delivery, testing, and releases.

  • What Kortreistved Needed

    The client needed an engineering partner who could take responsibility for the full product lifecycle — from analysing existing functionality and identifying bottlenecks, to delivering new features and maintaining a stable production environment during peak season. The geographic ordering logic that the business depends on required continuous iteration based on operational feedback from suppliers, drivers, and chain customers. The engagement was framed around long-term iteration rather than a one-off rebuild, which is closer to the decision between a marketplace plugin and a purpose-built platform that most growing marketplaces eventually face. The roadmap evolves with the business, and the team participates in analysis, planning, design, implementation, QA, and release across every surface.

Why this project is engineering-complex

  • Geographic-first matching

    Every order depends on coordinates and a chain of conditions that decide which supplier can actually deliver

    • Multi-condition supplier matching
    • Address resolution with partial-match fallback
    • Nearest-vendor tie-breaking rules
    • Delivery radius and zone enforcement

  • Five connected surfaces

    Most product changes touch more than one surface. Coordinated releases and shared API contracts are not optional

    • Admin panel (legacy + React)
    • Supplier dashboard (React)
    • B2C webshop (React)
    • B2B chain-customer webshop
    • Flutter mobile app for the field

  • Seasonal load profile

    Peak season is autumn and winter. Downtime during peak has a real cost, and release strategy is built around it

    • Six-month peak window each year
    • Feature freeze during peak season
    • Hotfix-only release pattern in winter
    • Heavier feature work in spring and summer

Outcomes

  • Performance gains

    Specific engineering improvements with measurable before/after numbers

    • Product availability: 3–5s → ~1s
    • Route recalculation: 5–7s → <1s
    • CRON-based WordPress recovery
    • Stable peak-season releases

  • Business features now live

    Major marketplace capabilities delivered, refined, and operating in production

    • Coordinate-based geographic matching
    • Package products (80–85% of total sales)
    • Group Buy with deadline and single-route logic
    • Pre-orders with split-payment options
    • B2B Chain Customers with EHF / PowerOffice

  • Operational reliability

    How the team and process protect the business across seasons

    • Dedicated team embedded long-term
    • Embedded QA with test-case documentation
    • Seasonal release management protocol
    • Multi-surface coordination across web and mobile

Platform Architecture

How the platform is built

In simple terms: one shared backend powers every part of the platform — admin panel, supplier dashboard, both webshops, and the mobile app. The same data drives every screen, so a change made by an admin appears for buyers, suppliers, and drivers without manual sync. The platform runs on a Laravel backend with a single MySQL database. The backend exposes a REST API used by every client surface — the React supplier dashboard, the B2C webshop, the chain-customer webshop, the mobile app, and the Laravel Blade admin panel. The backend is moving gradually from a monolithic structure toward modular organisation by bounded domain — orders, products, users, logistics. Architectural decisions that shape day-to-day delivery:

  • Backend-level RBAC controls permissions across every client surface, so the same authorisation rules apply whether a request comes from the admin panel or the mobile app
  • A layered Controller → Service → Repository pattern keeps business logic separated from transport and persistence
  • API versioning protects backward compatibility, which matters particularly for the mobile app where users do not update on a predictable schedule
  • The supplier dashboard and B2C webshop share a single frontend codebase. Build target flags produce different applications with their own UI configuration, branding, and enabled features
  • Background queues and scheduled jobs handle imports, exports, notifications, and heavier calculations that should not block a user request

Core marketplace features we delivered

Engineering challenges we solved

  • Slow product availability queries

    Product listings took 3–5 seconds to load because one query combined every availability condition at once

    • Joined coordinates, supplier radius, zone pricing, stock, status, priorities
    • Rewrote the query path and simplified redundant branches
    • Added result caching for stable inputs
    • Load time dropped from 3–5s to ~1s

  • Slow route recalculation

    Planning a route took 5–7 seconds every time an order was added or removed

    • Every adjustment forced a full recalculation
    • Reworked the routing algorithm
    • Recalculation dropped from 5–7s to under 1s
    • Route planner became usable as a live tool

  • Releases during peak season

    A broken release during autumn–winter peak has a direct revenue cost

    • Only hotfixes, security, and business-critical changes in peak
    • Larger feature work concentrated in spring and summer
    • Smoke testing after every production release
    • Six-month freeze window treated as normal

  • Group Buy logic redesign

    The first version let groups keep adding members after deliveries were already scheduled

    • Broke the single shared-route assumption
    • Added a group deadline and delivery-date inheritance
    • Blocked delivery planning before the deadline closes
    • Enforced one route across all members

  • WordPress connectivity recovery

    The marketing sites lost their database connection and broke the link to the webshop

    • Affected the marketing sites that drive traffic to the webshop
    • Failure required manual intervention to fix
    • Built a CRON-driven detection and recovery process
    • Connection now restores automatically

Mobile app for suppliers and drivers

The driver workflow

Drivers and suppliers use one Flutter app to run their workday in the field — picking up the day's route, navigating to each address, confirming each delivery with a proof photo, and submitting completed routes back to the platform. The same app works on iOS and Android.

Cross-platform build

The app is built with Flutter on a shared Dart codebase. iOS 11 and above is supported; Android targets minSdk 21 and targetSdk 36. Kotlin and Swift are used only as thin bootstrap layers, not for business logic. Brand behaviour for the firewood and GardenBio modules is handled through runtime module selection rather than build flavours.

Partial offline support

Offline support is partial. Delivery statuses and returns are stored locally in SQLite so the driver can keep working when connectivity drops. Sign-in, route refresh, photo upload, and route start/complete still require a connection.

Our Approach

Let’s have a talk
Let’s have a talk

Let’s have a talk

Get a first consultation on your project

Contact us
Call to action end icon

Projects

SuperYachtsMonaco

SuperYachtsMonaco — sale, purchase and charter of yachts of all sizes

  • / e-commerce

  • / project_management

  • / software_development

Healthcare Platform

Healthcare Platform Project Development

  • / health-tech

  • / fin-tech

  • / healthcare

  • / product development

  • / software development

Masmovil

Software Product Development
for MasMovil Group

  • / telecommunication

  • / product_development

  • / software_development

We have completed an array of projects, each of them unique from the perspective of business logic and generally common in terms of technologies, and vice versa. Basically, there’s no possibility (and we mean no, zero, null, non c'è) chances that we’ll start a new project out of blue (pun intended).

See all

FAQ