Keeping one customer out of another's data
On a shared platform this is the failure nobody recovers from quietly. I build the separation into the storage layer, so it does not depend on every future query remembering to filter correctly.
About
I am a backend developer based in Baubau, Indonesia, and I have spent the last six years writing PHP for products that other businesses run their operations on. Payroll that has to pay the right amount. Bookings that cannot be double sold. Records that belong to one company and must never appear in front of another. When the data is that consequential, the interesting problems stop being about features and start being about correctness, isolation and access.
Backend problems I get brought in for
Permissions an admin can actually manage
Most systems start with two roles and outgrow them fast. I design permission models detailed enough to be useful and plain enough that a customer's own admin can change them without filing a ticket.
Reports that used to be fast
Queries are fine at launch and painful three years later. I find where the time is really going and cut it, while the results stay exactly the same.
Raising the floor on an existing codebase
Strict analysis and real tests, added to code that already ships. The goal is simple: mistakes get caught before deployment rather than by a customer.
Making third parties agree
Every provider models the same idea slightly differently. I turn that mess into one predictable shape, so nothing downstream has to know which provider it came from.
Cleaning up what should not be there
Credentials sitting in config files. Dependencies kept out of habit. I get them out rather than bumping a version number and calling it fixed.
How I work
- Let the machine do the checking
- A rule enforced by tooling beats a rule everyone is supposed to remember. I lean on strict analysis and tests so that discipline does not depend on anyone having a good day.
- Production access is earned
- I have been the person trusted with it on systems holding other people's sensitive data. That changes how carefully you ship, permanently.
- Boring beats clever
- Small reversible steps, understood by whoever is on call at 2am. Save the interesting thinking for the problem itself.
Working together
Where are you based and which hours do you keep?
Baubau, Indonesia, on GMT+8. That gives me a full overlap with Australia and Singapore, most of the working day with the rest of South East Asia, and a workable morning overlap with Europe. I already work this way day to day for a client in Australia, so the timezone is a solved problem rather than an experiment.
Do you work on existing codebases or only new projects?
Mostly existing ones, and that is usually where I am most useful. Joining a codebase that already carries real customers, learning why it looks the way it does, and improving it without a rewrite is a specific skill. Greenfield work is enjoyable, but rescuing something people already depend on is harder and matters more.
What kinds of engagements do you take?
Contract and independent work, remote. I am comfortable being the backend owner on a small team, or the person brought in for a specific problem: a permission model that no longer fits, a report nobody can wait for any more, a codebase that needs a safety net before the next big change.
What does a first conversation look like?
Send me an email describing the problem, not the job spec. I will tell you honestly whether it is something I would be good at, and if it is not, I will say so. Nothing about that first exchange commits either of us to anything.
Can you work with a team that is not in your timezone?
Yes, and I already do. The practical answer is that I write things down. Decisions, trade-offs and the reasoning behind a change go somewhere the rest of the team can read them later, so progress does not stall waiting for our hours to overlap.
Do you only write backend code, or will you touch the frontend?
Backend is where I am strongest and where I want to spend my time. That said, I have shipped internal interfaces when a feature needed one end to end, and I am comfortable working closely with frontend engineers rather than throwing an API over the wall.
What languages do you work in?
English for all written and spoken work, and Indonesian natively. Most of my professional communication has been in English with teams outside Indonesia.
Got a backend that needs to be right?
Always happy to talk backend architecture, or about working together. My work history is on LinkedIn.
Usually replies within a day · Remote · GMT+8