Understanding needs
I studied international trade and started with campus and small business projects, learning to listen for real needs and see work through to delivery.
I’m ethanyeang. I work on product definition and business, and I stay hands-on with web development, AI agents, robotics and hardware alongside a technical team in Shenzhen.
I’m interested in the moment when software touches the real world: models reading an actual scene, robots taking action and prototypes turning into tools people can use. I work between open source, product design and the workshop.
I studied international trade and started with campus and small business projects, learning to listen for real needs and see work through to delivery.
I led product and delivery work across SaaS, ERP and custom software, learning to coordinate requirements, product design and technical teams. Interfaces, permissions, data and collaboration matter long after a demo is over.
At MetaHub in Shenzhen, I work on enterprise AI products and delivery. Outside that product work, I keep bringing agents, robotics and hardware into the same workshop to test what works in a real setting.
Start with the smallest flow that can test an idea. A real run teaches more than a larger plan on paper.
A product is for people doing real work. If they don’t want to use it, the demo still has work to do.
Clear, reproducible experience helps the next builder avoid repeating the same debugging session.
For teams with a clear goal that want custom AI or robotics work. I lead product definition and business, take part in technical validation, and deliver with an engineering team. Shenzhen projects can include on-site testing; elsewhere we work remotely.
Start from a real business goal. Evaluate retrieval, workflow design, tool integration and deployment boundaries. Agree on test criteria before sizing a prototype and delivery scope.
Connect hardware, teleoperation, real robot data, model inference and field demonstration in one project plan. Depending on platform support, explore SO-101, B601, Reachy Mini, LeKiwi and open VLA workflows.
For teams validating a problem and ready to try a real workflow: agree on users and scope, build a usable prototype, then work with an engineering team to implement and iterate.
Who is the user, and which real workflow should change?
Agree on hardware, data, system boundaries and acceptance criteria.
Test it with people and use field observations to guide the next step.
Clarify development, integration, deployment and ongoing support.
Three main areas: enterprise agents and private deployment, robot integration and real-world VLA validation, and product prototypes with custom software. We start from the business goal and existing constraints, then decide whether an assessment, a prototype or a full delivery is the right scope.
Yes. In Shenzhen we can meet and test on site; elsewhere the work is mostly remote, with an on-site phase if the project needs one. We can communicate in Chinese or English.
Send an email with the context, goal, existing hardware or data, expected timeline and budget range. The first conversation tests whether the problem is worth solving and where the boundary is; if it fits, we agree on stages and deliverables.
Based on scope, hardware, data readiness and delivery format. Exploration, prototype and full delivery are usually quoted as separate stages, each confirmed before the next, so the scope does not lock in too early.
SO-101, B601, Reachy Mini, LeKiwi and common LeRobot / VLA workflows can be evaluated. Actual support depends on the hardware, firmware, drivers and site conditions. Where something is uncertain, we run a small validation first instead of promising an outcome.
No promises about unverified metrics. We define testable acceptance criteria first and rely on real data and field results. The demos on this site document specific experiments, not guaranteed reproduction in every setting.
Chinese / English · In person in Shenzhen or remote collaboration.