Entry and frequency
Do users arrive through search, sharing, WeChat, desktop, or offline, and how often do they return?

Websites & Systems
Websites, mini programs, H5, apps, and internal systems are not interchangeable feature lists. We choose the right form from user entry, workflows, data, and long-term operations, then complete development, deployment, acceptance, and handoff.
A “store” may mean a catalog and lead form, or payments, inventory, fulfillment, refunds, membership, and reconciliation. A reliable solution starts from the operating rules rather than a platform label.
Do users arrive through search, sharing, WeChat, desktop, or offline, and how often do they return?
What do customers, staff, admins, and partners do, and where are approvals or manual steps required?
Who maintains data, and must the product connect payments, logistics, CRM, ERP, messaging, or existing databases?
Who updates content, handles orders and exceptions, manages access, and owns maintenance after launch?
The interface is only the entry point. A real transaction passes identity, rules, data, third parties, and operations before leaving a traceable state.
Web, mini program, H5, or app
Roles, rules, states, and approvals
Databases, APIs, and integrations
Configuration, access, logs, reports
A project can use one platform or a staged combination. Covering the critical path first is more reliable than building every endpoint in phase one.
For brand presentation, search acquisition, content, service explanations, leads, and public business entry points.
For sharing, short campaigns, and lightweight flows without installation, including embedded entry points.
For WeChat distribution, QR access, membership, or frequent light services within platform constraints.
For long-term products that genuinely need high frequency, device capabilities, push, offline use, or complex interaction.
For ongoing access, approval, order, project, inventory, customer, data, and team workflows.
Submit the users, three to five core workflows, current systems, timing, and budget. We will identify a lighter build path first.
These are common modules. Final scope follows real workflows and explicitly states inclusions, exclusions, and prerequisites.
Brand content, services, cases, search structure, lead forms, and content management.
Products, orders, payments, refunds, fulfillment, membership, notifications, and service states.
Customers, projects, workflows, approvals, access, configuration, logs, and operating data.
Connect payment, logistics, messaging, CRM, ERP, open platforms, and internal services.
Address performance, reliability, and maintenance risk in stages without an automatic full rewrite.
Connect knowledge, generation, recognition, or assistants to real access rules and workflows.
When scope is unclear, begin with requirements or prototyping. Commit to cost and timing only when boundaries are comparable.
Confirm the business problem, users, core workflows, current systems, hard dates, and constraints.
Define endpoints, features, data, APIs, exclusions, client prerequisites, and acceptance.
State stages, costs, milestones, third-party fees, change rules, and responsibilities.
Demonstrate critical paths, integrate real APIs, and record issues and decisions throughout.
Review code, data, deployment, accounts, documents, training, known issues, backups, rollback, and support.
Production reliability comes from engineering work that should be in scope and acceptance, not added at the last minute.
Limit data and actions by role, protect credentials, and retain records for sensitive operations.
Set checks for critical pages and APIs, then handle timeouts, retries, and failure states.
Define environments, domains, certificates, backups, release windows, and rollback conditions.
Keep critical accounts with the business and hand over agreed code, configuration, data, and operating guides.
Not every project needs every item, but the agreement states what is delivered, who provides it, and how it is accepted.