Most business software can produce a number. Far fewer can explain how they got it —
six months later, to an auditor, line by line. That gap is where I work: rule engines,
approval workflows, and integrations built so every figure can be traced back to the
decision that produced it.
Client systems are under NDA, so instead of screenshots you get the reasoning —
built on artefacts I can share in full.
Rule engine
A price the system can defend
A second-hand phone dealer priced trade-ins by hand, so two staff would quote two
different numbers for the same device. The obvious fix — hard-code the discounts —
fails the moment someone asks why a number came out that way, or when last
month's rules change and last month's valuations silently move with them.
I model pricing rules as versioned data, not code, and store the
calculation trace alongside every valuation. Staff get an answer they can read back
to a customer:
base price · iPhone 13 128GB3,500,000
battery health < 80% · rule #12−420,000
box missing · rule #31−105,000
grade B cosmetic · rule #07−175,000
recommended offer2,800,000
Snapshot on write · rules never retro-edit history
Data modelling
Schemas built for the question you'll ask later
The same system, at the schema level. Every valuation keeps a feature snapshot next
to its real outcome — what it sold for, how long it took — so the dataset needed for
a future pricing model accumulates from day one instead of being reconstructed later.
An outlet master had grown to 266,000 rows. The listing screen took
around five seconds to open and, on larger filters, ran the process out of memory
entirely. The table wasn't the problem — the access pattern was: the
full set was being pulled into memory and counted there, so every page load paid for
all 266k rows to answer a question about twenty of them.
before~5.0s + OOM
after<1.0s
Paging pushed down to the database, a cheap count that stops caring about exact totals
past a threshold, and a partial index covering only active rows — because that is the
slice actually queried. No new hardware, no caching layer, no rewrite.
PostgreSQL · keyset paging · partial index · EXPLAIN-driven
Job orchestration
Dozens of overnight jobs that must finish before the office opens
Large operational systems rarely stop when the staff go home. Dozens of scheduled jobs run
overnight: pulling data from other systems, assembling documents, pushing results onward.
The hard part isn't running them — it's what happens when one of them fails at two
in the morning.
pull from source system · 01:00done
assemble daily documents · 01:40done
push to target system · 02:05 · attempt 1failed — network
automatic retry · 02:20 · attempt 2done
escalation to on-callnot needed
The principle I hold to: a job that isn't safe to run twice isn't a job, it's a
time bomb. Every task is idempotent, its status recorded per step, failures retried
automatically before they reach a human, and old data archived and purged on a schedule so
the queue doesn't quietly rot.
I needed to know which freelance platforms were actually worth the time, and the
available advice was recycled listicles. So I scraped four marketplaces, normalised
464 listings, and computed the distributions myself.
The result contradicted my own first read — a median I had estimated at $370 was
actually $100 once I sampled properly. Cheap to discover in analysis; expensive to
discover after committing.
<100100200300400500+
Python · scraping · distribution analysis
Shipped
Front end, when the job needs one
A production landing page: hand-written CSS, no framework, no build step —
36 KB, first paint in 0.4 seconds, deployed on a free tier that never
sleeps. Re-theming the whole site is six CSS variables.
Backend is where I'm strongest, but a system nobody can use isn't finished. I'd rather
own the whole path than hand over an API and hope.
Stitching together systems never designed to talk to each other
Large companies rarely run one system. There's a finance system a decade old, a newer
operational portal, and third-party systems — including government ones — whose rules
change without waiting for anyone to be ready.
I connect them through staging tables and batch processes rather than direct calls
between systems. The reason is simple: if the target system is down, the data must not
vanish — it waits in staging until it can be resent, and every attempt is recorded.
A system still used every day can't be taken down to be rewritten. What I do is move it
piece by piece while the old version keeps serving, until the last part crosses over and
the old one can be retired without anyone noticing.
The range I've worked across spans frameworks over a decade old through to current
versions, including database migrations between vendors.
Phase 1
Phase 2
Phase 3
Phase 4
Incremental · runs side by side · no service downtime
Official documents
Letters and invoices that are valid, not merely well printed
Official documents carry requirements ordinary reports don't: numbering must be
sequential and must never collide even when many people generate documents at once,
authenticity must be verifiable, and archives have retention periods.
I build collision-safe numbering, marking so documents can be re-verified, tiered
approval flows, and scheduled archive retention.
Industries I've worked in. Automotive distribution and aftersales
(vehicle allocation, parts dealer portal, warehousing and invoicing, expense vouchers),
human resources (manpower planning, recruitment, location-based attendance, leave,
transfers), banking office automation (memos, letters, minutes, dispositions, document
management, archive retention), and Indonesian taxation (tax invoices, withholding
certificates, reporting).
Recurring problem classes. Synchronising data between systems of
different generations, usually asynchronously through staging tables and batch processes.
Bulk file-based ingestion with layered validation and reconciliation. Job scheduling and
queue processing that must be idempotent and auditable. Migrating legacy systems to
current versions without downtime. Producing official documents with numbering,
authenticity verification, and digital signatures.
What I've built repeatedly. Tiered approval flows with value
thresholds and escalation, role-based access with per-role menus and permissions,
database-level audit trails, and Excel import/export with PDF generation.
What isn't my field. To be clear up front: I don't do large-scale
microservice architecture, cloud-native infrastructure, modern single-page front ends, or
machine learning modelling. If that's what you need, I'm not your person — and it's better
you know now than halfway through.
How to work with me
Fixed scope, fixed price, no open-ended retainers
I hold a full-time engineering role and take freelance work that can be specified up front
and delivered on a schedule I can guarantee. That constraint is deliberate — it is also why
nothing I ship is half-finished.
What comes up most often: REST API development with proper documentation,
payment gateway integration, third-party API and webhook
integration between systems, PostgreSQL and MySQL database design,
and data migration off legacy systems. If what you need is the backend for
a web or mobile app that already has a front end, that fits too.
from $520 · ~1 week
Database design & ERD
Schema design with written rationale
ERD and migration scripts
Index and query review
Documentation another dev can pick up
from $520 · ~1–2 weeks
API & webhook integration
REST integration with retry and idempotency
Webhook receivers with signature verification
Sync jobs with reconciliation
OpenAPI documentation
quoted per scope
Business rule engine
Rules as versioned data, not code
Full calculation trace per decision
Admin screen for non-technical staff
Audit log from day one
from $520 · ~1 week
Scheduled jobs & batch
Reliable scheduling for recurring work
Idempotent — safe to run twice
Per-step status log with failure escalation
Archiving and purging of old data
quoted per scope
Legacy modernisation
Audit of the running system and a staged plan
Framework and database migration
Runs alongside the old system, no big-bang cutover
Documentation so your team can carry it on
Frequently asked
Before you ask
How much does backend or API development cost?
From $520 for a clearly bounded scope — database design with an ERD, or a set of REST
endpoints with OpenAPI documentation. Payment gateway work and larger integrations are
quoted per scope once the requirements are clear. I don't work on open-ended hourly rates.
Do you build company profile websites?
Yes, though it isn't my focus. There's an example in the work section: a production
landing page, 36 KB, first paint in 0.4 seconds. If you only need a brochure site with no
system behind it, a specialist studio is usually better value. I'm most useful when there
is a backend, a database, or an integration underneath.
Can you integrate payment gateways?
Yes — including the parts that usually cause trouble: inbound payment flows, webhook
notifications with signature verification, idempotent handling of retries, and payouts to
recipient accounts. Delivered with documentation and a Postman collection so your team can
test it independently.
Our system is slow. Can you help with database optimisation?
This is the work I handle most often. The work section has an example: a 266,000-row
listing that took five seconds and ran out of memory, brought under one second with no new
hardware. The approach is always the same — read the execution plan first, never guess.
What if I need another developer to take over?
All source code, database schemas, and documentation are yours and are handed over at
every milestone, not stockpiled until the end. The repository is under your account from
day one. I write documentation assuming someone else will continue the work.
Do you work with clients outside Indonesia?
Yes. I'm based in Indonesia (UTC+7) and work comfortably in written English. Payment via
Payoneer or any platform that provides escrow.
Contact
Tell me what the system has to prove.
Send the problem, not a spec — I'll tell you honestly whether it's something I can scope,
and whether I'm the right person for it. If I'm not, I'll say so.