APIs, databases and authentication built to survive production — Node.js, Java and PostgreSQL, with KHQR and PayWay payment for Cambodia.
Most backends do not fail on the happy path. They fail the first time two people press the same button, or the night a payment provider times out, or the morning someone needs a report that nobody designed the tables for.
This is server-side work done with those days in mind: an API another developer can read, a schema that will still make sense in two years, and the boring operational parts — migrations, logging, backups — treated as part of the build rather than something to add later.
Not a list of technologies — the things that exist at the end and the state they are handed over in.
REST or GraphQL, with consistent errors, pagination and versioning.
Documented well enough that a mobile developer can build against it without asking you questions.
Real foreign keys and indexes chosen from the queries you will actually run, plus reversible migrations.
A data model that will still make sense in two years.
Sessions or JWT, password reset, roles and permissions, and multi-tenant isolation where more than one organisation shares a database.
Bakong KHQR and ABA PayWay for local payment, plus SMTP, Telegram and storage.
Docker, a CI pipeline, environment separation, and a rollback that does not involve a backup file and hope.
Four stages, each ending in something you can open rather than a status report.
What the system must do, who uses it, and what it has to talk to. Written down before anything is built.
Agreeing the data model early is the cheapest hour in the project; changing it after the front end exists is the most expensive.
A working vertical slice at a time, so there is always something to look at rather than a status report.
Source, migrations, environment variables, deployment steps, and a walkthrough. It is your system.
The choice follows the problem — a system your team will maintain in Java should not be handed over in something nobody there can read.
Six systems on the work page are built on exactly this.
Tenant isolation enforced twice — scoped on every request across some seventy record types, and again by row-level security policies in PostgreSQL, so the database holds the line even if the application does not.
Keeps selling while the internet is down and reconciles afterwards.
Puts one stock list behind a storefront, an admin panel and a phone app.
All are built and deployed to a pre-production environment — not yet running in production for a paying customer. That is the honest state of them, and the code is real either way.
See the work →Scope decides the number, so there is no price on this page. Here is what replaces one.
What the system has to do, who has to use it, and what it must talk to. Written down before anything is built.
It depends entirely on scope, which is why there is no price on this page. After scoping you get a fixed written quote and a delivery schedule, not an hourly meter.
A focused API is usually four to eight weeks; a full multi-tenant system is months. Staged delivery means you see progress rather than waiting for it.
On final payment: source, schema and deployment instructions. No licence to keep paying for, and no lock-in to us for the next change.
A brochure or product website is a different, much cheaper job — and ready-made systems you subscribe to rather than commission are a different purchase again.
It depends entirely on scope, which is why there is no price on this page. After a scoping conversation you get a fixed written quote and a delivery schedule, not an hourly meter.
A focused API is usually four to eight weeks. A full multi-tenant system is months. The scoping call gives you a real range, and the staged delivery means you see progress rather than waiting for it.
You do, on final payment — source, schema and deployment instructions. No licence to keep paying for, and no lock-in to us for the next change.
Yes. Extending or repairing an existing backend is common work; the first step is a short audit so the estimate is based on the real code rather than a description of it.
Tell us what the system has to do and who has to use it, and we will tell you what it takes.
Start a project →