Chenxi flower wholesale inventory-and-sales system
A full-stack operations system built solo for a flower wholesaler — live in production, with 200K+ RMB in cumulative sales.
Problem
Flower wholesale ran entirely on paper for outbound/inbound, ordering, pricing, inventory, spoilage, and expenses — there was no fast way to enter data on the warehouse floor, and the owner had no real-time view of the business. At the same time, a small business can't afford a traditional database and its upkeep.
Approach
A Flask backend with Feishu Bitable in place of a traditional database (zero-ops data storage), plus Feishu OAuth login and role-based access control; an H5 single-page app tuned for mobile so data can be entered on the warehouse floor; on the engineering side, CSRF protection, API rate limiting (60 requests/minute), and atomic transactions to keep data consistent; deployed on Gunicorn + Railway.
Results
Live in production
Status
200K+ RMB
Cumulative sales
0 (Feishu Bitable)
Database ops cost
AI's role in this project
The project has no AI features — it's included to prove the ability to ship solo: a real business, a real launch, real revenue.
A system people actually use
This isn't a practice project: it serves a real flower wholesaler, covering the whole flow — outbound, inbound, ordering, pricing, inventory, spoilage, expenses — and it's live in production with 200K+ RMB in cumulative sales.
Trade-offs worth a mention
Feishu Bitable as the database. The real constraint for a small business is "can't afford the ops." Bitable comes with permissions, backups, and visualization built in, and the owner reads the business numbers right inside Feishu — trading zero ops cost for a slight loss in query flexibility, which is the right call at this scale of business.
Designed for the warehouse floor. An H5 single-page app tuned for mobile, so a worker can glance at it and enter data right in the warehouse; Feishu OAuth + role-based access splits owner / warehouse / sales.
Even a small system keeps engineering discipline. CSRF protection, API rate limiting (60 requests/minute), and atomic transactions to keep the books consistent — money data can't be wrong.