Case · Fulfillment

February–May 2026

Removing the Human Bottleneck from Marketplace Fulfillment

The Premium Gifting E-commerce business produced handmade chocolates and sold them online. For express delivery, we used both our own production site and a partner dark-store network.

Speed matters especially for a gift: if it arrives too late, the moment can simply be lost. The order therefore had to be fully assembled and ready before the courier arrived.

The process was simple at first. I accepted orders at the production site myself, assembled them, and handed them to couriers. Partner dark stores made delivery faster, but the process itself became more complex: the systems were not connected, and every order from the on-demand marketplace still passed through me.

If a partner dark store was fulfilling the order, I transferred the data into its system. If our own production site was fulfilling it, I sent everything to the working Telegram chat and waited for the team to respond. When necessary, I reminded the team about the order or called an employee.

The courier often arrived in roughly 15 minutes. Every manual action consumed part of that time and added another opportunity for error.

By the beginning of 2026, I was already living in another country, but I was still a required link in this process.

Without me, the process could simply stop.

How the manual dependency developed

The partner locations operated through a dark-store fulfillment network. It allowed us to hold products closer to customers and deliver faster across several cities.

About a year before the integration launched, our products were stocked at ten locations in that network. Over time, we kept one location because it worked better for our logistics. Our own production site continued to fulfill some orders in parallel.

But the on-demand marketplace, the partner fulfillment system, and the internal production process were still not connected.

NEW ORDER
     │ accept
     ▼
CHOOSE ROUTE
     ├── transfer data ─────────→ PARTNER SYSTEM
     │
     └── hand off ──────────────→ TEAM TELEGRAM
                                      │ check response
                                      │ remind / call
                                      ▼
                                 ASSEMBLY → COURIER

NEW ORDER
     │ accept
     ▼
CHOOSE ROUTE
├─ PARTNER → transfer data
└─ TEAM → TELEGRAM
             │ check
             │ remind
             │ call
             ▼
       ASSEMBLY → COURIER

The dark store operated seven days a week. I therefore had to remain available all the time.

The work could have been handed to a dedicated order coordinator. One person, however, could not cover all the long shifts. A two-days-on, two-days-off schedule would have required at least two hires.

Their job would have been to accept orders, transfer data between systems, and make sure the team started assembly on time.

I decided to automate the complete order route.

Why the existing integration did not work

The marketplace handled both restaurant delivery and retail orders, but used different integration flows for the two merchant types. Although we sold boxed gifts rather than restaurant meals, our production site had been onboarded through the marketplace's restaurant flow. The partner fulfillment network's ready-made connector supported only merchants registered as retail stores, so it could not receive our orders.

I designed a custom integration and built it with Claude Code.

Supabase formed the foundation. Orders and statuses were stored in cloud Postgres. The server logic ran as TypeScript in Supabase Edge Functions.

The Edge Functions accepted marketplace requests, worked with the database, called the partner API, and controlled the Telegram bot. I later added another marketplace to the same system.

MARKETPLACES SERVER LOGIC STATE

marketplace A ───────────────→ Edge Functions ────────────→ Postgres marketplace B ───────────────→ validate · route order · status · courier │ ┌────────────┴────────────┐ ▼ ▼ partner API Telegram Bot │ │ ▼ ▼ partner dark store production

MARKETPLACES
marketplace A / B
        ↓
  EDGE FUNCTIONS
 validate · route
        ↓
     POSTGRES
order · status · courier
        ↓
  ┌─────┴─────┐
  ↓           ↓
partner API  Telegram Bot
  ↓           ↓
dark store  production

How one order moved through the system

When the marketplace sent a new-order request to our backend, an Edge Function validated the request and saved the data in Postgres.

The order then followed one of two routes. If a partner dark store was fulfilling it, the Edge Function sent the data to the partner API. If our own production site was fulfilling it, the Edge Function formed a message and sent it to the working chat through the Telegram Bot API.

The production team did not need a separate control panel. Everyone already used Telegram, so the new process fit into a familiar tool.

The message contained:

the order number;
the items;
the expected time;
the current status;
courier information;
controls for working with the order.

An employee could accept or reject an order. When cancelling, the bot asked for a reason. After assembly, the employee selected “Assembled.”

When courier data arrived from the marketplace, the bot updated the same message. At handoff, the employee entered the courier code as a Telegram reply. This action remained manual: the code confirmed that the right person was receiving the order.

Every button press reached an Edge Function through a Telegram webhook. The function processed the action and wrote the new status to Postgres.

EMPLOYEE ── presses a button ──→ TELEGRAM WEBHOOK
                                          │
                                          ▼
                                     EDGE FUNCTION
                                          │
                                          ▼
                                  NEW STATUS IN POSTGRES

EMPLOYEE
 ↓ presses a button
TELEGRAM WEBHOOK
 ↓
EDGE FUNCTION
 ↓
STATUS IN POSTGRES

The marketplace did not receive a separate notification when the status changed. Instead, it requested the order status again. The Edge Function read the current value from Postgres and returned it in the response.

MARKETPLACE ── status request ──→ EDGE FUNCTION
     ▲                                │
     │                                ▼
     └────── current status ───── POSTGRES

MARKETPLACE
 ↓ status request
EDGE FUNCTION
 ↓ reads
POSTGRES
 ↓ current status
MARKETPLACE

Reconstruction based on archived production code

Try handling an order

Production

5 March

Reconstruction based on archived production code. On the website, this path can be followed step by step. The complete sequence remains available without the interactive mode:

The marketplace sends a request containing the order.
An Edge Function validates the request, saves the order, and selects a route.
For our own production site, the bot sends one Telegram message with “Confirm” and “Cancel” actions.
Team actions arrive through a Telegram webhook and update the status in Postgres.
Courier information appears in the message after assembly.
An employee enters the courier code. This is the required human control at handoff.
The final status is saved in Postgres and returned when the marketplace requests it again.

The status was not pushed to the marketplace through a separate webhook. If the team did not respond, the system sent another Telegram notification and started an internal phone escalation. If the integration did not return either a confirmation or a cancellation, the marketplace had its own independent fallback: it called the location, and an employee could open the order in the marketplace's web interface to confirm or cancel it there.

We could have recorded exactly which employee pressed each button. We deliberately left this out of the first version.

The team was small and experienced. Assembly accuracy was not a problem, and individual monitoring would not have solved the main issue. Shipping the system sooner mattered more.

What happened when nobody responded

For express delivery, sending a message is not enough. The system has to make sure the order was actually noticed.

If the production team did not respond, the system sent a second Telegram notification. Phone escalation followed.

NEW ORDER
     │
     ▼
TELEGRAM NOTIFICATION
     │ no response
     ▼
SECOND NOTIFICATION
     │ still no response
     ▼
PHONE CALL

NEW ORDER
 ↓
TELEGRAM NOTIFICATION
 ↓ no response
SECOND NOTIFICATION
 ↓ still no response
PHONE CALL

One more risk remained: the integration itself could stop working. In that case, the first message, reminder, and phone call from our system would all be missing.

The marketplace therefore provided an independent fallback. If either marketplace did not receive a confirmation or cancellation, it called the location directly. An employee could then open the order in the marketplace's own web interface and confirm or cancel it there. That interface remained available independently of our Edge Functions, Postgres, and Telegram flow.

OUR SYSTEM MARKETPLACE FALLBACK

Telegram no confirmation │ or cancellation second notification │ │ ▼ phone call call the location │ │ │ ▼ │ marketplace web interface │ confirm / cancel │ │ └──────────────────┬─────────────────┘ ▼ ORDER HANDLED

1 · OUR SYSTEM
Telegram
 │ second notification
 │ phone call
 └───────────────────┐
                     │
2 · FALLBACK         │
no confirmation      │
 │ call location     │
 │ marketplace web   │
 │ confirm / cancel  │
 └───────────────────┤
                     ▼
               ORDER HANDLED

What changed after launch

I no longer had to participate in every order.

Orders assigned to the partner dark store were sent automatically to the partner system. Orders for our own production site appeared in Telegram. The team could accept an order, assemble it, and hand it to the courier without my involvement.

The marketplace received the current status from our database on its next request.

Instead of creating a separate dispatch team, we used automatic routing and the employees who were already at the production site. This meant that we did not have to hire at least two people for shift-based order handling.

Nobody was laid off. A separate team for this work had never existed, and after launch it was no longer needed.

How long the system operated

The integration operated from February through May 2026.

We closed our own production site at the beginning of May. All sales stopped at the end of the month. The integration continued operating until the business stopped.

Before launch, every order could require my involvement. After launch, the production team and the partner warehouse worked directly with the system.

I was no longer a required link between an order and its fulfillment.

My role

I knew this process from doing it, not from a written description: for a long time, I had performed it manually myself. That made it possible to see both the technical gap between systems and the actual operating risks.

Within the project, I:

mapped the existing process;
designed the order routing and server logic;
built the TypeScript Edge Functions with Claude Code;
created the Postgres data structure;
connected two marketplaces and the partner fulfillment API;
embedded order management in Telegram;
added repeat notifications and phone escalation;
provided an independent fallback for complete integration failure.