Computer vision
Vision projects usually succeed or fail on the camera setup and the dataset more than on the model. So we start there: where the camera goes, what the light looks like at noon and at night, and how many labelled images we need. Typical jobs are identity checks, defect inspection, and counting or tracking people and products. Once the model works, we make it fast enough for the hardware it will run on, whether that's a cloud GPU or a Jetson Orin mounted next to the camera.
What you get
- Object detection, segmentation and tracking
- Face matching and identity checks, with liveness detection
- OCR and document reading, e.g. Thai ID cards, invoices, delivery notes
- Deployment on NVIDIA Jetson and other edge devices, sped up with TensorRT
Usual tools
- OpenCV
- YOLO
- PyTorch
- TensorRT
- Jetson
Ask about this→
Robotics and ROS 2
We write the ROS 2 nodes that connect a robot to its sensors and to the rest of your system. On top of that come motion planning with MoveIt, teleoperation, and data collection for imitation learning. We also build the operator screen. If the people on the floor can't run the robot without calling an engineer, the job isn't finished.
What you get
- ROS 2 architecture, drivers and links to your other systems
- Arm and mobile base control, with MoveIt for motion planning
- Teleoperation and imitation-learning data collection with LeRobot
- Simulation and bench tests before anything moves on site, plus the operator UI
Usual tools
- ROS 2
- MoveIt
- LeRobot
- Python
- C++
Ask about this→
AI and machine learning
First we check whether you need AI at all. Sometimes a rule or a SQL query does the job for less money. If a model is the right call, we prepare the data and pick or fine-tune one, then put it behind an API your other systems can call. You also get an evaluation report that shows where the model gets things wrong, and a plan for retraining when your data changes.
What you get
- Chat assistants that answer from your own documents (RAG), for example a policy bot on your LINE OA
- Forecasting, classification and anomaly detection on sales, sensor or transaction data
- Evaluation reports: accuracy on your data, typical failure cases, cost per request
- Deployment, monitoring and a retraining schedule
Usual tools
- Python
- PyTorch
- scikit-learn
- Hugging Face
- FastAPI
Ask about this→
IoT and sensors
Say you run a factory in Samut Prakan and want to know when a compressor starts running hot, before it stops. We would write the firmware for the sensor board (often an ESP32), send the readings through an MQTT broker into a time-series database, and put them on a dashboard with alerts to LINE or email. We also plan for the dull parts: what happens when the Wi-Fi drops, and how to update firmware on a device nobody can easily reach.
What you get
- Device firmware and sensor wiring (ESP32 and similar boards)
- MQTT or HTTP telemetry into a time-series database
- Live dashboards, with alerts by LINE or email
- Remote configuration and over-the-air (OTA) firmware updates
Usual tools
- ESP32
- MQTT
- Node.js
- InfluxDB
- Grafana
Ask about this→
Web apps
We build in TypeScript with Next.js and PostgreSQL. It's a common stack in Thailand, so if you hire your own developers later, they can pick up the code without us. Typical jobs: a booking system that takes PromptPay, or an admin panel to replace the shared Excel file nobody dares to sort.
What you get
- Web apps, customer portals and admin dashboards
- UX/UI design in Thai and English
- Login, user roles and payments
- Page speed, SEO and accessibility
Usual tools
- Next.js
- React
- TypeScript
- PostgreSQL
Ask about this→
Mobile apps
We normally write one codebase for both platforms, in React Native or Flutter. The app can keep working offline and sync when the signal comes back, which matters for staff working upcountry or in a warehouse with bad reception. If your product includes hardware, we write the Bluetooth or Wi-Fi link to it too.
What you get
- One app for iOS and Android
- Companion apps for Bluetooth LE devices
- Offline mode that syncs when it reconnects
- Release to the App Store and Google Play
Usual tools
Ask about this→
Backend and cloud
We design how the parts of the system talk to each other and build the services. Then we set up CI/CD, containers and monitoring, so a release is a normal weekday job. We also connect to what you already run, such as an ERP, a LINE OA or a payment gateway. If your traffic doesn't need Kubernetes, we'll say so and keep it simple.
What you get
- REST and GraphQL APIs, and integrations with ERP, LINE OA or payment gateways
- System architecture and code review
- CI/CD, containers and infrastructure as code
- Logging, monitoring and keeping the cloud bill under control
Usual tools
- Node.js
- FastAPI
- Docker
- AWS
- GCP
Ask about this→
Data pipelines and reports
A common situation: the numbers you need already exist, but they're split between a POS, a machine log and a folder of Excel files on someone's laptop. We move them into one database on a schedule, check them for gaps and duplicates, and build dashboards in Metabase or whatever BI tool you already use.
What you get
- Scheduled ETL/ELT pipelines (Airflow, dbt)
- Warehouse and schema design
- Dashboards and KPI reports
- Data checks for missing rows, duplicates and totals that don't match
Usual tools
- PostgreSQL
- BigQuery
- Airflow
- dbt
- Metabase
Ask about this→
