One anonymized project from a real delivery, plus three scenario examples that show how we approach common problems. Scenario examples are illustrative and are not client claims.
Context. A plastic pallet pooling business moves pallets between a main warehouse, a transit warehouse, and 20+ customer sites. The pallets do not change ownership, but their location changes every day. The client was running three Excel ledgers and reconciling them by hand at month-end.
What we built. A document-driven ERP with four core document types: return to main warehouse, dispatch to transit warehouse, transit dispatch to customer, and stock adjustment. Every document updates inventory, and every inventory balance can be traced back to a document and an operator.
Scope of the first phase.
Result. The month-end inventory reconciled with the client's original Excel, including 70,000+ pallets. Seven adjustment documents were used to explain import differences, each with a note and an audit trail. We do not publish an “efficiency percentage” because it cannot be verified and does not help the next project.
Why it matters. The hard part was not the screen design. It was the data model: making sure every movement has a source document and every difference has an explanation.
This is a scenario example, not a client case. A manufacturer with 200+ product models wants a website that does more than list specifications. The site structure separates product categories, selection guides, application scenarios, and inquiry paths.
Each product page answers three questions: what it is, which model fits which use case, and what to do next. The inquiry path is one primary action per page, with a short form or WeChat contact. The technical layer includes unique titles, structured data, sitemap, and analytics.
This is a scenario example, not a client case. A 5–20 store chain wants members, bookings, in-store redemption, and repeat visits in one place. The first release covers member profiles, points, booking, and redemption; coupons and analytics come after the core flow is stable.
The critical design decision is redemption. It has to work offline, be reversible, and record who performed it. If the store staff cannot trust the redemption flow, they will go back to paper.
This is a scenario example, not a client case. A service company with 20–100 technicians needs dispatch, arrival check-in, photo evidence, customer signature, and settlement. The app is designed around a clear state machine: assigned, accepted, departed, arrived, in service, completed.
Offline support is a requirement, not a bonus: photos, forms, and signatures are stored locally and synced when the device is back online. Settlement rules are defined before dispatch, so finance is not reconstructing the month from chat messages.
The ERP project is a real delivery, anonymized at the client's request. The other three are scenario examples based on common requirements. They show our approach, not a claim that we delivered those exact projects. If you need a reference for a specific industry, ask; we will tell you what we can and cannot share.
Send the current process, the number of sites or warehouses, and the report you need at month-end.