BOTTEC — Telegram E-commerce Platform

The shape of the system

BOTTEC turns a Telegram chat into a full commerce surface: product catalogue, cart, checkout with multiple payment providers (Stripe + local cards), order status, warehouse pick lists, courier handoff. Customers never leave Telegram; operators get a real backoffice.

The hard parts weren't the bot UI — Telegram's bot framework is fine. The hard parts were everything around it:

Payment provider integration. Stripe is straightforward; the local provider had a 200-page PDF spec, no test environment worth using, and a support team that responded in working days. The integration layer is explicitly defensive: typed contracts, idempotency keys, dead-letter queue for reconciliation. When something goes wrong with payments, you find out in seconds, not at month-end close.

Warehouse and logistics. Inventory sync against a third-party warehouse system on a 5-minute pull. Courier dispatch via a separate API. Both are unreliable in different ways, so the order state machine is the source of truth — external systems get caught up to it, never the reverse.

Owner moderation surface. The owner needs to see live orders, suspend a product, refund a payment, message a customer — all without writing SQL. A small but well-typed admin API + a thin web UI handles that.

Lessons that transferred

Every later project I worked on (Contento, the trading bot, the biotech AI work) inherited two patterns from BOTTEC: state machines as the source of truth, and typed integration contracts even for "throwaway" providers. Both turned out to matter more than the specific stack choices.