The bench at work
Xinhuayuan Co., Limited builds web platforms, mobile apps and machine integrations for small and mid-size clients, from written spec to release and onward maintenance. Every engagement starts on the same bench and passes through the same discipline: draw the specification, build in reviewable stages, release with the documentation attached, and stay on hand afterwards. The six services below describe what that discipline looks like in practice.
We are software developers and systems integrators by trade, working from Rm 5, 8/F, Mega Cube, 8 Wang Kwong Rd, Kowloon Bay, Hong Kong (HK). We take on a limited number of builds each quarter so that each one receives the attention a real operating system deserves.
Bay T1
Web Platform Development
Our web platform work covers the systems that quietly run a business: customer portals, operations dashboards, booking engines, membership services and internal data tools. A platform build begins with a written specification that names the users, the data model, the flows and the non-functional needs such as load, retention and access control. We then build in short stages, each ending with a working slice that the client can open and test. On the technical side we favour well documented frameworks, automated deployment and readable code, because a platform is only valuable if the next team can maintain it without holding a private ritual. Handover includes the source, the deployment scripts, the environment notes and a walkthrough recorded for staff who join later. When a platform needs to grow, it grows along seams we drew from the beginning, not through emergency surgery.
Bay T2
Mobile App Development
Mobile builds from this bench serve two audiences: customers who expect a polished app, and staff who need a tool that works in a warehouse, a van or a client site. We plan for offline use from the first drawing, because connectivity is the exception rather than the rule once an app leaves the office. That means local storage, conflict handling and a sync model that a user can reason about. We build for iOS and Android, sharing a code base where the platforms allow it and going native where performance or device access demands it. Battery, data use and screen legibility under poor light are treated as requirements rather than afterthoughts. Before a release we run the app through real field conditions with the people who will live in it, and the feedback from those sessions shapes the final build rather than a later patch.
Bay T3
Systems Integration and APIs
Integration is where most operational software succeeds or fails, so we treat it as a first class discipline. We connect accounting suites, inventory systems, payment providers, delivery partners, CRM tools and shop floor machinery through documented APIs and dependable message flows. Each integration starts as a map that shows what data moves, in which direction, how often and what should happen when a partner is slow, rate limited or offline. We favour idempotent operations, retry policies with sensible backoff, and clear alerting so that a single failing endpoint never silently corrupts a process. Where a partner offers only a brittle interface, we build a small adapter layer so that the fragility stays contained in one place. Clients receive the integration documentation as a living document, useful to their own developers long after our involvement ends.
Bay T4
E-Commerce Builds
E-commerce work is judged by a trading week, not a screenshot. We build storefronts and checkout paths that survive messy supplier catalogues, seasonal traffic and the awkward realities of payment and delivery. That ranges from configuring and extending established commerce platforms to building custom storefronts where the product model does not fit an off the shelf tool. We pay particular attention to catalogue hygiene, stock truth across channels, cart recovery, tax and shipping rules, and the admin experience that a merchandising team actually has to use every day. Performance budgets are set early, because a store that loads slowly on a mobile connection loses sales before a customer ever sees the product. After launch we monitor the funnel and tune the parts that matter, guided by real orders rather than by opinion.
Bay T5
Legacy Modernization
Many of the most important systems in a business are also the oldest, and replacing them in one leap is usually the fastest way to lose a quarter. We modernize in stages. First we map the existing behaviour, including the undocumented rules that only one person still remembers. Then we wrap what still works behind a clean interface, so that surrounding systems can be improved without touching the fragile core. Next we migrate the riskiest or most valuable modules first, keeping the old system running beside the new until the new one has earned trust. Throughout, we keep a rollback path open and we measure the migration against the behaviour we mapped at the start. The result is continuity rather than a dramatic cut over, and a modern system that grows out of the old one instead of replacing it overnight.
Bay T6
Maintenance and Support
A release is a beginning. Our maintenance and support work keeps client systems patched, monitored and quietly improving under an agreement that names response times, escalation paths and a monthly rhythm of small fixes. We handle dependency updates, security patches, backup verification and performance reviews, and we keep a change log so that every adjustment is traceable. Support is delivered by the same team that drew and built the system, which means less time spent reconstructing history and more time spent solving the problem in front of us. Where a client prefers to take maintenance in house, we prepare the documentation, run a handover, and remain available for the occasional deep question on a consulting basis.
How the work runs from drawing to care
The stages below are not a sales diagram. They are the order in which work actually moves across this bench, and they hold whether the build is a two week integration or a year long platform.
Drawing
A written specification naming users, data, flows and constraints, agreed by both sides before code begins.
Build stages
Short stages, each ending in a working slice you can open and test while feedback is still cheap.
Release
Deployment scripts, documentation and access details handed over in one package at go live.
Care
Monitoring, patching and small improvements through a maintenance agreement with named response times.
What we need from you
A clear problem, access to the people who understand it, and a willingness to make decisions at the drawing stage. You do not need a finished brief. You do need to be available for the short reviews that keep a build honest, and to nominate one person who can speak for the project when a question cannot wait. In return you get a system built against a written record rather than a memory, and a team that stays reachable after release.
What we decline
We decline projects where success depends on hiding the architecture from the client, where a deadline has already been sold to a customer before the specification exists, or where no one on the client side can own the outcome. Saying no early is cheaper for everyone than discovering the mismatch halfway through a build. If your project falls outside the six services above, we will say so and, where we can, point you toward someone better suited.
Ready to draw the specification
Tell us what the system needs to do and who it serves. We will tell you plainly whether the bench is the right place for it, and what the first drawing would look like.
Start a Build Back to Home