i am Rain
Back to home

Project retrospective / 2026.03 – Present

oppachikin

More than just a website for a fried chicken shop —
an end-to-end operations system spanning customer ordering, payment, and delivery,
through to internal scheduling and payroll.

oppachikin online ordering menu screenshot

Timeline

5 Weeks From zero to a production ordering and operations system.

Scope

External + Internal Customer ordering and store operations designed in tandem.

Status

Live End-to-end payment pipeline verified · Processing real-world paid orders.

Pre-launch Risk Audit

1 Week Rigorous audit of payments, webhook callbacks, and rate limiting prior to launch.
01 / External: Customer Experience

From "Phone-Only" to "Self-Service E-commerce"

In Minsk, most restaurant orders still rely on walk-ins and phone calls. Even high Instagram traffic failed to convert because there was no landing page. Here, a website isn't just a bonus channel — it's the primary driver for customer acquisition.

  1. Order Channel Phone or walk-in only (zero direct conversion from Instagram). Seamless Instagram-to-website conversion for 24/7 self-service ordering.
  2. Delivery Transparency Opaque delivery availability and pricing until you called. Transparent, automated delivery fee calculation at checkout.
  3. Payment Method Cash-only, in-person transactions. Integrated Alfa Bank online payments, enabling a cashless checkout flow.
  4. Order Tracking Blind waiting post-purchase with no status updates. End-to-end real-time tracking for both order prep and delivery.
02 / Internal: Store Operations

From "Manual & Reactive" to "Automated Workflows"

Customers never see this backend—but it's where we free the owner and staff from repetitive monitoring, manual calculations, and complex payroll settlements.

  1. Order Fulfillment Staff could only take manual orders and cook on the spot. Orders auto-route to a Telegram staff channel. One click marks an order "done," instantly syncing the status to the customer.
  2. Delivery Dispatch Manually hailing a courier for every single delivery. Automated courier dispatch via the Yandex B2B API the moment preparation is complete.
  3. Shift Scheduling Chaotic group chats prone to human error and missed shifts. One-click, self-service weekly shift selection via a custom Telegram bot.
  4. Time-Tracking & Payroll Manual hour tallying and payroll calculations at month-end. Automated time-tracking and instant payroll calculation via the bot.
  5. Customer Retention Repeat business relied purely on the owner's memory. Automated membership and loyalty point system. (Built with an append-only transaction ledger—because anything involving financial value requires a strict audit trail.)
03 / Delivery automation

Pricing delivery with data, not gut feel

Delivery is the easiest place to lose money. Instead of guessing, we sampled real Yandex courier fares across distances and time bands to build a defensible pricing table. After cooking, the system auto-dispatches; edge cases route to a human.

How we price

Distance × time-of-day banding from real samples

8 fixed routes (0.9–12 km) × ~5 days continuous sampling = 2,592 samples

A Vercel Cron job samples Yandex real-time fares every 10 minutes into Supabase, then bands them by distance × time-of-day (off-peak / light peak / strong peak) to generate the customer-facing price table.

How we dispatch

Auto by default, human fallback for edge cases

After cooking, the system re-quotes at dispatch time and uses the free claims/create as a true-price probe (only accept is charged). Normal orders auto-dispatch; 12 km+, anomalies, and failures route to a human.

Sampling

2,592 real samples Cron every 10 min across 8 fixed routes.

Pricing

Distance × time-of-day banded Reproducible, not gut-based.

Fallback

Anomalies always go to a human No hard-forcing edge cases.
04 / Security audit

The most important step before launch: security audit

Getting features to work is just step one. Before going live, every loophole that could cause real financial damage needs to be closed — this system had to hold up to real money and real traffic. None of this was built up front — I dedicated a full week near launch to a security audit and patched these one by one.

Duplicate payment callbacks

A successful callback can be retried by the gateway due to network issues.

Gate state transitions on current order status — duplicates return 200 but trigger no side effects.

Amount tampering

The client-submitted total can be changed by a user in the request.

Always recompute the final total server-side from item IDs before payment — the frontend price is display-only.

Webhook forgery

A public webhook URL can be spoofed, impersonating Telegram.

Validate the secret_token in the webhook header; reject mismatches with 401.

OTP abuse

SMS codes cost real money; an unprotected endpoint gets drained.

Upstash Redis rate limiting by IP + phone number, two dimensions.

05 / Collaboration with AI agents

AI didn't think for me — it amplified my judgment

AI does not make product decisions for me. It reduces the distance between a well-specified idea and a working implementation. The bottleneck becomes how clearly I can define the business rules, risk boundaries, and trade-offs before handing work to AI agents.

What I own

  • Understanding how a real store actually operates
  • Deciding which risks must be closed before launch
  • Turning "experience" into testable hypotheses
  • Choosing where to automate vs. keep a human in the loop

What AI agents do

  • Mapping out API integration paths
  • Generating and refactoring TypeScript code
  • Debugging payment, webhook, and cron issues
  • Translating the security checklist into concrete implementations