Pitch deck · living business plan

The PieSam plan

How pooled rural delivery works end to end, what it earns, how it goes to market on rails that already exist — and, just as importantly, an honest board of where it still needs work.

01 · The problem

The last 15 km nobody will drive

Thousands of villages sit between towns that do have takeaways and delivery apps — but no restaurant or courier will drive 15 km for a single order, so the apps simply draw their delivery zones around the towns and stop. The village is left with one pizzeria, if that.

The economics flip the moment several orders travel together: one driver, one trip, five meals. What’s missing isn’t restaurants, drivers or ordering apps — all of that exists 15 km away. What’s missing is coordination.

02 · The solution

Pool the street into one run

A run is one shared delivery journey to a village at a set time. Neighbours claim seats — each their own order, from up to three nearby restaurants collected in a single loop. One pooled driver fee is split across every seat, so delivery gets cheaper as the street piles in. Below the minimum, the run never happens and nobody pays. PieSam takes a flat 7 kr per seat — never a cut of the food.

The landing page has the interactive seat-wheel version of this pitch.

03 · How it works

Four roles, one engine

Neighbour (eater)

Claims a seat in a run: picks a town restaurant, orders, pays their share of one pooled delivery fee. If the run never fills, nobody is charged.

Driver

Claims a confirmed run, collects every order in one tight pickup loop (max 3 clustered restaurants) and drops door-to-door or at one collection point — paid the whole pooled fee on delivery.

Sam Controller

The local franchise unit: one person per village who starts runs, lists PieSam on the platforms people already use, logs those outside orders into runs, and owns the customers and complaints.

PieSam HQ

Supplies the software, brand and playbook. Earns a flat fee per seat. Deliberately never the seller-of-record for food — that liability stays with those already licensed to carry it.

A run’s life

1
Open

collecting orders until the deadline
2
Confirmed

minimum seats reached — the run is a go
3
Claimed

a driver takes the run
4
Collected

one pickup loop through the town
5
Delivered

doorsteps, or one shared collection point
6
Settled

food + fees captured, driver paid

Money mirrors the lifecycle: joining places an escrow hold (food + worst-case delivery share + the flat fee); delivery captures and pays the driver in one atomic step; an expired run refunds every hold automatically.

04 · Go-to-market

Ride existing rails, franchise the village

Building a two-sided marketplace village by village is slow. Instead, each village gets a Sam Controller — ideally the shop or pizzeria that already holds the licence, kitchen and local trust — who lists a “PieSam” virtual brand on the platforms townspeople already use and pools those orders into runs. HQ supplies software, brand and the controller handbook (playbook, draft agreement, VAT sheet, safety SOPs). In Sweden the rails are Foodora and Wolt (Just Eat doesn’t operate here):

Wolt Self-Delivery

List on the Wolt app but deliver with our own couriers — and set a delivery area "even beyond Wolt cities". The rural unlock: serve a village Wolt itself does not reach.

Foodora MarketPlace

The partner prepares and delivers; foodora is merely the listing. A PieSam listing here is a discovery channel in the towns people already order from.

Wolt Drive (API)

Logistics-only, commission-free, pay-per-delivery, with scheduled drop-off (60 min – 7 days ahead). Slots map neatly onto a run’s delivery window — the automated last-mile rail.

The hard rule: PieSam HQ is never the seller-of-record

HQ stays out of the food sale entirely — no VAT exposure, no food-safety liability, no reseller agreements. A plain controller sells delivery slots only. A controller who already runs a licensed kitchen (like the village pizzeria) may additionally sell fixed-price PieSam set meals — and is then the seller-of-record themselves, which adds no liability they don’t already carry and lets them upsell their own kitchen alongside the town’s.

05 · Unit economics

Try the numbers yourself

These figures are computed by the exact fee code the app settles with — adjust the assumptions and watch every number move. PieSam’s only revenue is the flat 7 kr per seat.

Driver payout per run 90 kr Seats filled 5 Runs per village per week 3

Each seat pays

25 kr

18 kr delivery + 7 kr PieSam

vs going it alone

90 kr

the same trip, unshared

PieSam earns per run

35 kr

5 × 7 kr flat

Driver earns per run

90 kr

one loop, one drop

One village, at this cadence

105 kr/week to PieSam · 455 kr/month

15 meals delivered and 270 kr to local drivers, per week — per village. Scale is a multiplication by villages, not a new build each time.

Illustrative by design: seats, payout and cadence are assumptions you set above, not measured demand. Validating them is exactly what the pilot KPIs below are for.

06 · The moat

The rails are commodity; the pooling isn’t

Neither Foodora nor Wolt pools many people’s orders across several restaurants into one shared rural trip — their model is one order, one courier, one fee, inside a profitable urban zone. That per-order model is precisely why the villages are unserved.

PieSam’s defensible core is the pooling engine (seats, minimum-viability gate, escrow, proximity-bounded pickup loops) plus controller orchestration — a local human who owns the village relationship. Everything else — listings, couriers, payments — is deliberately rented from rails that already exist.

07 · Built today

A working demo, not a mock-up

✅ Run engine + escrow

Full lifecycle with a state machine, holds on join, capture + driver payout on delivery, automatic refunds on expiry — all unit-tested.

✅ Multi-restaurant pooling

A run collects from up to 3 restaurants clustered within 2.5 km; delivery addresses are geocoded and range-checked against the village (OSM Nominatim + OSRM, cached).

✅ Two fulfilment modes

Door-to-door, or one shared collection point (village shop counter today; the heated PieSam Box locker is the roadmap — the data model already supports it).

✅ Driver job board

Claim confirmed runs, a consolidated pickup manifest per restaurant, collect → deliver → paid.

✅ Sam Controller console

Start runs for the village, log external (Foodora/Wolt/phone) orders so outside demand pools with app demand, and — for licensed kitchens — manage and sell set meals.

✅ Controller handbook (franchise pack)

Onboarding playbook, a draft operating agreement, VAT & seller-of-record guidance and the trust & safety SOPs — the paperwork side of the franchise, drafted and public.

✅ Trust & safety basics

Allergy notes captured on every order and flagged on the manifests, plus a driver code of conduct that must be accepted (timestamped) before driver mode switches on.

✅ Bilingual foundation (EN/SV)

Locale detection + a language switcher with typed message catalogues; the chrome, landing and auth pages already ship in full Swedish — remaining pages migrate key by key.

✅ Live deployment

SvelteKit + SQLite behind Nginx/TLS at demo.piesam.com, seeded with a Skåne-style demo geography, demo accounts and live runs.

Poke around the demo

lina@example.com · eater
dag@example.com · driver
sam@example.com · Sam Controller (licensed kitchen)

08 · The honest bit

Where it needs work

This is the improvement board the rest of the plan exists to expose. “Next” blocks a real pilot; “Decision needed” wants a call before code; “Drafted” is written and waiting on review; “Later” can wait until the model is proven in one village.

Real payments

Decision needed

Blocked on registering the company — no PSP account without one. The seam is ready: escrow runs behind the PaymentProvider interface, so Stripe test-mode drops in the day the org. nr exists. Open with it: how the driver actually receives money.

Platform rails are manual

External orders are typed in by the controller today. The next real rail is the Wolt Drive API (scheduled drop-off slots) and, later, ingesting marketplace orders instead of re-keying them.

Set meals not buyable in-app

Set meals exist and sell via the controller, but an app customer cannot yet pick one on the run page. Small, high-value step that also exercises the escrow path for meals.

No notifications

Nobody is told "your run is confirmed" or "food is at the collection point" unless they have the tab open. SMS (or at least email) is table stakes for a real pilot.

Controller franchise pack

Drafted — needs review

Drafted and live in the Controller handbook: onboarding playbook, operating agreement template, VAT / seller-of-record sheet, safety SOPs. Still needs a registered company, a lawyer’s pass and per-operator tax confirmation before anyone signs.

Trust & safety

Decision needed

Shipped: allergy capture on every order (flagged on manifests) and a mandatory, timestamped driver code of conduct. Still open: formal identity verification (BankID), insurance requirements, and hardware custody at the collection point.

Restaurant relationships

Decision needed

Restaurants are seeded data. Even informally, a pilot needs 2–3 town restaurants who know batched pickups are coming. Self-serve onboarding + menu sync is the later software version.

Swedish translation

The i18n rails are in: locale detection, an EN/SV switcher and full Swedish for the chrome, landing and auth pages. Remaining: migrate the app pages, this plan and the handbook into the message catalogue.

PieSam Box hardware

Later

The heated locker with per-order doors is modelled in the schema (kind = locker, doorCount) but there is no hardware or Bluetooth-unlock prototype.

Scale infrastructure

Later

SQLite + polling is right for a demo; multi-village production wants Postgres/Turso, SSE instead of polling, and self-hosted Nominatim/OSRM.

09 · Roadmap

Demo → pilot → franchise

Now

› Working end-to-end demo, live at demo.piesam.com
› Pooled multi-restaurant runs, escrow ledger, collection points
› Controller console: external orders + licensed set meals
› Franchise pack drafted (/handbook) + allergy capture + driver code of conduct
› Bilingual EN/SV foundation with a live language switcher
› Unit + e2e test suites, seeded demo data

Next — one-village pilot

› Register the company, then Stripe test-mode + SMS notifications before the first real run
› Recruit one Sam Controller (ideally the village pizzeria) + 2–3 town restaurants
› Legal review of the drafted operating agreement + per-operator VAT confirmation
› Wolt Drive API spike: book a scheduled slot for a confirmed run
› Run 2–3 evenings a week for 6–8 weeks and measure the pilot KPIs

Later — repeatable franchise

› Self-serve village setup on top of the handbook playbook
› Restaurant self-serve menus, in-app set meals everywhere
› Full Swedish translation of every page
› PieSam Box locker prototype at one collection point
› Postgres, SSE live updates, self-hosted geocoding

10 · Risks

What could sink it, and the counter

⚠️ Cold start in each village

The controller seeds both sides: they start the runs, list PieSam on the platforms people already use, and can drive the first batches themselves. Start with one weekly "burger night" run, not a 24/7 promise.

⚠️ Platform dependency

Listings on Foodora/Wolt are discovery, not the home rail. Orders migrate to the commission-free PieSam app over time, and the slot-only model works with no marketplace at all (phone + app).

⚠️ Driver supply in small places

Runs are pre-scheduled batches, not on-demand gigs — someone driving home anyway can claim one. A controller or neighbour can pre-assign themselves when starting a run.

⚠️ Economics below minimum seats

The minimum-seats gate means an unviable run simply never happens: it expires and every hold is refunded. Nobody subsidises empty trips.

⚠️ Food-law liability

The hard rule: PieSam HQ is never the seller-of-record. Slot-only for plain controllers; set meals only for controllers who already hold a licence and kitchen, who are then the seller themselves.

⚠️ Cold food / handover quality

Tight pickup clusters (≤ 2.5 km), one village drop, staffed collection counters today and the heated PieSam Box as the roadmap. The controller owns complaints locally.

11 · Pilot KPIs

What one village must prove

The economics slider above runs on assumptions; a 6–8-week pilot replaces them with measurements. These are the numbers to watch:

Fill rate: % of started runs that reach minimum seats — the single best health metric
Seats per run: average confirmed seats; drives the per-seat fee people actually pay
Per-seat delivery fee: what a seat really cost after the split, vs going it alone
Runs per village-week: cadence: is this a weekly treat or a routine?
Repeat rate: % of eaters who take a seat again within 30 days
External : app order mix: how much demand the platform listings actually bring
Controller take per evening: does running the village pay enough to care?
Driver earnings per hour: payout ÷ realistic loop time — must beat the alternative

See it working

The fastest way to judge the plan is to use the thing: join a run, drive one, or open the controller console as the village pizzeria.

Browse open runs The driver board Controller console