01 / Delivery platform
Panalk.
A delivery business should not have to become a software company to run its day. Panalk puts orders, dispatch, drivers, payments, and customer updates in one platform.
- connected surfaces
- Nine Recorded 2026-10-31
- API tests
- 676 Measured 2026-10-27
- identity tests
- 280 Measured 2026-10-27
- languages
- Five Recorded 2026-10-31
- 01
Operator
Orders, prices, drivers, vehicles, branches, and the customer relationship.
- 02
Panalk core
Tenant boundary, dispatch, payments, proof of delivery, and support.
- 03
Customer
A clear view of the journey and a route to help without an account.
01 / Context
The problem
A growing delivery business usually runs across a spreadsheet, a chat group, a pile of messages, and a driver's phone. The order is in one place, the price in another, and the customer has to ask for an update. Building the missing software is a second business. Many operators cannot take that on and still run the first one.
Panalk is the infrastructure behind the operator. It does not become the delivery company and does not take over the operator's brand or customer relationship. It gives the operator a system that is already built for the work.
02 / Audience
Who it is for
The operator running the day, the shops that send through it, and the customer waiting for an update are three different users with three different questions. The operator needs control. The shop needs a reliable delivery route. The customer needs to know where the parcel is and how to get help.
Each company keeps its own customers and records. The software is shared; the business boundary is not.
03 / Constraint
The constraint that shaped the build
A logistics platform without a real tenant boundary is a data breach waiting for a busy day. Filtering rows by a company id in each screen is not enough. The boundary has to hold when a role is wrong, a customer link is copied, or a request goes through the API.
The platform also had to work in five languages, record payments without holding customer funds, handle handovers between people and vehicles, and give a customer a useful page without making them create an account.
04 / Build
What we built
The build covers the full day, not one screen:
- An operator dashboard for orders, pricing, dispatch, drivers, vehicles, branches, payments, proof of delivery, and customer updates.
- A driver surface for the assigned leg and the handover record.
- A customer portal and a signed delivery link so a recipient can follow the journey and ask for help.
- Plans, billing, support, roles, permissions, and an API for shops and other systems.
- Five languages and a tenant model that applies at the database boundary, not only in the interface.
05 / Decisions
The hard part
The interesting work was mostly not visible. Identity and tenant isolation had to agree. A customer link had to reveal only its own delivery. A payment event had to be recorded without pretending Panalk is a wallet. A failed handover needed a useful state, not a generic error.
The test counts from 27 October 2026 are part of the proof: 676 API tests and 280 identity tests. The number is useful because it shows where the effort went, not because a test count is a product feature.
06 / Outcome
What is live
Panalk is live at panalk.xyz. The public product description is the operator's view of the system. The work behind it is a platform with a small number of moving parts that have to agree every day.