Direct Answer
Retail software fails on inventory truth, not on the storefront. We build catalog, order, inventory and settlement as one data model, so stock stays consistent across a mini program, an app and physical stores instead of drifting between systems.
Suitable For
- Retailers selling through a mini program, app and physical stores at the same time
- Brands that outgrew a SaaS storefront and need custom pricing, membership or settlement rules
- Multi-store operations needing per-store stock, staff permissions and daily reconciliation
Not Suitable For
- A single small store that a standard SaaS storefront already serves well
- Requests to clone a marketplace without a supply or traffic plan behind it
Core modules and the data each one owns
| Module | Scope, data and rules it owns |
|---|---|
| Catalog & SKU | Product, variant, attribute and price-tier data; controls how one product maps to many sellable SKUs across channels. |
| Inventory | Per-warehouse and per-store stock, reservation on order placement, release on cancellation, transfer and stocktake records. The single source of truth for availability. |
| Order & fulfilment | Order state machine from placement through payment, picking, shipment, delivery, refund and after-sales; every transition is logged for dispute handling. |
| Membership & promotion | Member tiers, points, coupons, campaign rules and their stacking priority — the rules engine, not hardcoded discounts. |
| Settlement & reporting | Daily reconciliation between orders, payment gateway records and refunds; store-level and channel-level revenue reporting. |
| Admin & permissions | Role-based access down to store and field level, backend-enforced, with an audit log of price and stock edits. |
Step-by-step Process
- Send the current workflow, the roles involved and where the process breaks down today
- We map the data model, the modules needed at launch and what can wait for a later phase
- Confirm scope, integrations, acceptance criteria, source-code ownership and deployment responsibility
- Iterative build with demos at each milestone, then functional, compatibility and performance testing
- Deployment, source-code and documentation handover, then an agreed maintenance path
Buyer Checklist
- One primary user workflow and one admin workflow defined for the first release
- Role and permission matrix agreed before development, enforced in the backend
- Integration accounts and API credentials confirmed as available
- Data migration source, format and volume reviewed
- Acceptance criteria written per module, not per screen
- Source-code ownership, deployment responsibility and maintenance scope stated in the contract
Information Needed for Quotation
- The workflow you want to replace or build, and who performs each step
- User roles and what each role may see and edit
- Platforms required at launch (web, mini program, iOS, Android, desktop)
- Systems to integrate: payment, ERP, WMS, hardware, accounting, third-party APIs
- Existing data to migrate, its current format and rough volume
- Whether source-code handover and self-hosting are required
Frequently Asked Questions
Can one system serve a mini program, an app and physical stores?
Yes, provided inventory and orders live in one backend rather than being duplicated per channel. Channels become clients of the same API. The common failure is letting each channel keep its own stock table, which guarantees oversell.
How do you prevent overselling during promotions?
Stock is reserved at order placement inside a database transaction, with row-level locking or an atomic decrement in Redis for high-concurrency drops, and released on timeout or cancellation. The reservation window and its timeout are agreed during scoping.
Which platforms do you build for this industry?
WeChat and Douyin mini programs for in-app commerce, iOS and Android apps for repeat customers, a responsive web store for search traffic, plus a Vue admin panel for operations. One backend serves all of them.
What can you integrate with?
WeChat Pay, Alipay, Stripe and PayPal; logistics tracking APIs; ERP and WMS via REST or scheduled sync; invoicing and accounting exports; SMS and template message notifications.
Will we own the source code?
Source-code handover, repository access, deployment notes and database documentation can be included in the agreed scope. State it in the brief so it is priced in rather than added later.
Can you take over an existing system instead of rebuilding?
Yes. We start with a code and environment review, then propose a scoped plan for bug fixes, refactoring, UI rework or new features. Rebuilding is only recommended when the review shows the existing codebase cannot carry the roadmap.
Related Pages
Request a Quotation
Include the fields listed above so the response can focus on model, material, fitment or service scope instead of generic claims.
Request a Project Estimate
Tell us about the product goal, current workflow, target platform, constraints and decision timeline. We will review the scope and recommend a practical next step.