AstroBaaS

Orders & fulfilment

Delivery Radius & ETA Estimation (Restaurants)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €24/mo; delivery-zone mapping, ETA calculation, dynamic fee by distance

Generated from docs/plan/paid/delivery-radius-eta-estimation/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A delivery range and ETA system for restaurants that calculates delivery fees based on distance and rejects orders outside the delivery radius.

The problem

Order to 50km away means too long delivery; merchants need radius check, ETA calculation, and dynamic delivery fees.

What it does

  • Define delivery radius (e.g., 10km from restaurant location)
  • Check if address is within radius (haversine distance or postcode zone)
  • Calculate ETA (base prep time + delivery time based on distance)
  • Apply dynamic delivery fee (e.g., €2 base + €0.50 per km beyond 5km)
  • Show ETA and fee to customer before checkout
  • Reject orders outside radius

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

  • Traffic data — we don’t integrate Google Maps for real-time traffic. Reason: external dependency.
  • Route optimization — no turn-by-turn routing. Reason: advanced logistics separate feature.
  • Driver tracking — no GPS assignment or tracking. Reason: delivery logistics separate paid feature.

Data model

New tables: DeliveryZone {id, restaurantId, centerLat, centerLon, radiusKm, baseFee (minor units), perKmFee (minor units, e.g., 50 = €0.50)}; DeliveryEstimate {orderId, distance (km), prepTime (minutes), deliveryTime (minutes), eta (timestamp), deliveryFee (minor units)}. No migration.

API

  • POST /api/restaurants/:id/delivery-zones
  • POST /api/delivery/estimate

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Restaurant admin: define delivery zone (center location, radius, fee structure).

The seam — why this is paid

Core owns: radius check interface. Paid owns: ETA algorithm, traffic integration, driver assignment.

Support commitment: delivery ETA algorithm, zone audits, delivery partner SLA

Dependencies

  • Order infrastructure
  • Restaurant/merchant configuration (location)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

  • Postcode within 10km returns ETA; outside returns rejection
  • ETA calculation: base 15min + 2min per km = 15 + (distance*2) minutes
  • Delivery fee: €2 base + €0.50/km beyond 5km = 200 + max(0, (distance-5)*50) minor units
  • Delivery fee is added to order total at checkout

Risks

Wrong location: merchant’s restaurant coordinates incorrect; mitigation: admin can adjust radius and center. Distance calculation errors; mitigation: test against Google Maps API on sample addresses.

Commercial context

Suggested price€24/mo; delivery-zone mapping, ETA calculation, dynamic fee by distance
Rival anchorToast: €65/mo built-in; Google Maps integration: free; custom: €1500+

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.


Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.