Homecent 宅迅

A software company in Shenzhen. We build software products, and we run them after launch.

Core business: Software product development
Also provided: Technical support and maintenance
Based in: Shenzhen, Guangdong, China
Working languages: English, Simplified Chinese

Shenzhen Homecent Trading Co., Ltd. develops software products and provides technical support. The work is software: we take a product idea or an existing system, carry it through development and release, and stay on for the maintenance that follows.

The work. We build business systems, customer portals and the services behind them. An engagement starts with a written scope: what the product must do, what it must not do, and how we will both know it is finished. Then it is built in short iterations, each one ending in software you can run.

The support. Support is not a separate contract we would rather not sell. Monitoring, triage, patches and dependency upkeep continue on the same system, with an engineer who already knows the code and response terms agreed before anything goes live.

The languages. Requirements, progress notes, documentation and the code itself are delivered in English and Simplified Chinese. Our clients work in both, often in the same week, so nothing important is written in only one of them.

The contact. Enquiries go to one person, Ribin Ding, who reads them and answers them. Nobody is routed through a sales desk. Tell us what the product has to do, or what has stopped working, and the first reply is a set of questions.

A wide view over Shenzhen: dense towers along Shennan Road, low hills behind them under a clear sky — Shenzhen, looking west along Shennan Road. “The west panorama of Shenzhen2021” by Charlie fong, CC BY-SA 4.0, via Wikimedia Commons (cropped)

Six kinds of work,one team that stays

Custom software development

A complete, maintainable system, from requirements through to production release.

Business systems and internal tools, Server-side services and background processing, Technical documentation and handover

Web platforms and portals

Public sites, customer portals and admin consoles that remain maintainable after launch.

Server-rendered and static front ends, Admin consoles and reporting views, Accessibility and performance budgets

System integration and APIs

Make the systems you already run work with the software you are adding.

Third-party and partner API integration, Data migration and synchronisation, Authentication and access control

Technical support and maintenance

Ongoing support with a named owner, rather than an anonymous ticket queue.

Monitoring, triage and incident response, Bug fixes, patches and dependency upkeep, Change requests and small enhancements

Cloud and delivery engineering

Build, deploy and operate on infrastructure you can audit and take over.

CI/CD pipelines and release automation, Cloudflare and mainstream cloud platforms, Observability, logging and cost awareness

Technical consulting and review

An independent read on architecture, risk and delivery before you commit.

Architecture and code review, Delivery plans and effort assessment, Build-versus-buy and vendor evaluation

Where are you now?

Three situations, three different first steps. Choose the one that fits and the page answers for it.

Trading floors inside the Huaqiangbei electronics market in Shenzhen, hung with shop signs — Huaqiangbei, Shenzhen. Where the components come from. “Huaqiang Electronics World 1” by Mx. Granger, CC0, via Wikimedia Commons (cropped)

What happens first, and what we would need from you.

We have an idea

First step. We write down what the product has to do and who will use it, then give you a scope, a delivery plan and a price or a rate.

From you. A description of the problem, who it is for, and any deadline you are already working to.

Send this as an email

We run an existing system

First step. We read the code and the infrastructure before proposing anything, and tell you which parts we would keep, change or leave alone.

From you. Repository or system access, the constraints you work under, and what is already planned.

Send this as an email

Something has stopped working

First step. We start with the failure: what changed, what the logs say, and what is still running. Then we tell you what we would do first.

From you. The symptom and when it started, plus access to the environment if the system is yours to open.

Send this as an email

First we agree what it must do.

Requirements, acceptance criteria, and what we are not building.

Then the plan goes in writing.

Architecture, milestones, and a delivery schedule you can hold us to.

Then it is built in short iterations.

Each one ends in software you can run, not a status report.

Then we stay on after launch.

Monitoring, patches, and the changes that follow a release.

This pageis the sample

No logos, no case studies, no numbers we cannot show you. Two tables you can check from where you are sitting: what we commit to, and how this site itself is built.

What we commit to
Commitment	What it means	How you can hold us to it
Scope in writing	Assumptions, deliverables and acceptance criteria are agreed before code is written.	Ask for the scope document before any work starts.
Working software	Progress is measured by what runs, not by hours recorded.	Every iteration ends in a build you can open yourself.
No lock-in	Code, documentation and infrastructure access belong to you.	The repository and the accounts are held in your name.
Support after launch	Maintenance is part of the engagement, not an afterthought.	The engineer who built the system stays on it.

This site, as built
Item	Measurement	How to check it
JavaScript sent to the browser	0 KB	View source: no module scripts. The only script is the structured data for search engines.
Pages	Eight, in two languages	Four routes, each built in English and in Simplified Chinese.
Photographs and footage	Six, openly licensed	Credited in the footer, each with a link to its source.
Checks before deploy	Types, unit tests, output verification	npm run check, npm test and npm run verify all have to pass.
Response headers	No inline script, no framing, HSTS	curl -I https://hcentlab.com