Freelance web development
I build the software that sits in the middle of your operation — the POS, the audit trail, the booking queue, the approval flow. Practical systems, built to be handed over and kept running.
Every project below starts the same way: a team is doing important work in tools that were never meant for it. The job is to move that work somewhere it can be trusted, shared, and measured.
A full application built around one real process, from database schema to the screens your team uses every day. No off-the-shelf product bent into a shape it was not designed for.
The unglamorous screens that decide whether a team is fast or stuck: queues, approvals, bulk edits, and a dashboard that answers the question someone asks every morning.
Point-of-sale, stock control, room and resource booking — systems where a wrong number costs real money, so they are built around accuracy first and speed second.
The repetitive step nobody should still be doing by hand. Notifications, scheduled jobs, and connections between the systems you already pay for.
Moving a process out of a shared spreadsheet or an abandoned system, without losing the history or the habits your team already has.
A system nobody can deploy is a liability. Every project ships with a repeatable deploy, documentation, and a repository you own outright.
Most of the risk in custom software is decided before any code exists. So the first stage is deliberately slow and the rest moves quickly.
We walk through the process as it happens today, including the workarounds. This is where the real requirements live: the exception nobody documented, the report someone rebuilds by hand each month, the approval that happens over a phone call. You get a written scope and a fixed picture of what version one contains.
Work happens in a repository you have access to from day one. Each stage delivers something usable rather than a progress percentage, so you are testing real screens with real data early instead of reviewing a demo at the end.
The system goes live with your data, usually alongside the old process for a short period so nothing depends on a single switchover day. I fix what surfaces in the first weeks of real use, because that is when the genuinely important bugs appear.
Source code, database, deployment configuration, and documentation are yours. If you want me to keep maintaining it, that is a separate arrangement — never a dependency you were locked into by default.
A note on scope. The fastest projects are the ones where version one does less than the wish list. Shipping a narrow system that people use beats shipping a complete system three months late that they work around.
These are the tools I reach for by default, chosen because they are stable, well-documented, and easy for another developer to pick up after me — which matters more than novelty when you own the result.
You can see how these come together in the POS Flask build, the internal audit system, and the 3D duct ordering system.
Custom software is not the right answer for everyone. It fits best when:
If an existing product covers 90% of what you need, I will tell you that rather than quote a build.
Cost depends on three things: how many user roles the system has, how many workflows it replaces, and whether it has to integrate with software you already run. A focused internal tool with one or two roles is a much smaller build than a multi-department business system with approvals and reporting.
I scope every project before quoting, so the number is based on your actual workflow rather than a template. This breakdown of what drives cost walks through the factors in detail.
A narrow internal tool usually reaches a usable first version in a few weeks. Larger business systems with multiple roles, approvals, and reporting take longer and are best delivered in stages — you start using part of the system while the rest is still being built.
Yes. I am based in Phnom Penh and work remotely with clients in any time zone. Collaboration happens over email, Telegram, and scheduled calls, with work visible in a shared repository as it is built. If you are hiring locally, the Cambodia page covers how that works.
That is one of the most common reasons teams reach out. Spreadsheets stop working once several people need to edit the same data, history matters, or approvals are involved.
Moving that process into a web application gives you permissions, an audit trail, and reporting — without changing how your team already thinks about the work.
Yes. You own the source code and the data. I hand over the repository and the deployment setup so you are never locked into working with me to keep the system running.
Mainly Laravel (PHP) and Flask (Python) on the backend, Vue.js with Tailwind on the frontend, and MySQL or SQLite for data. Docker handles deployment, and I integrate services like the Telegram API when a workflow needs notifications.
Tell me what your team does by hand today. If custom software is the right answer, I will scope it. If it is not, I will say so.
Start a conversation ↗