Muhammad Royhan
Senior Fullstack Engineer · Team Lead
Systems where a wrong number is someone's paycheck — payroll, lending, compliance.
Competition kept me out. Obligation kept me in.
Backend and frontend, seven years and three promotions at one company. I lean on systems thinkingUnderstanding a system by how its parts affect each other over time, not by inspecting any one part in isolation. and a Stoic bias for what's controllableThe Stoic dichotomy of control: spend effort only on what you can actually influence, and design for the rest. to build software that holds up after I hand it over.
- 7 years, one company
- 3 promotions to Team Lead
- Payroll for 800+ employees
- Banking · ERP · Marketplace
What's Royhan's tech stack?
React.js, Next.js, Flutter, and TypeScript on the frontend; Node.js, Express.js, NestJS, and Sequelize.js on the backend; MySQL, Docker, and AWS SQS for infrastructure. He picks tools that stay boring under pressure rather than chasing what's newest.
Tell me about the payroll system project.
A payroll engine for 800+ employees, covering Indonesian PPh 21 tax (TER method), BPJS, and PP 58/2023 — every run idempotent, every figure traceable back to its inputs through a generic audit trail across ten entities. Royhan took it from a small internal system in 2024 to full production in June 2026, and still maintains it.
Is Royhan available for contract work?
Yes — he's remote-first, based in WIB (UTC+7), and open to EOR, contract, or full-time arrangements with a two-week notice period. Best fit: systems where a wrong number has real financial or legal consequence — payroll, lending, compliance.
Why did Royhan stay at one company for 7 years?
Not passion for code specifically — he stayed because the longer he worked, the more people ended up depending on his output being correct, and that responsibility mattered more to him than switching jobs would have. Three promotions later (Junior to Team Lead), he's still there, now leading systems other people's paychecks and debts depend on.
Junior Software Engineer
The one who never meant to be here
I avoided software on purpose. The field looked overcrowded, and I had no appetite for competing against people who had wanted it far longer than I had.
Moving Bytes Digital hired me anyway. My first work was picking up an ERP project already in motion, then a rental marketplace someone else had started — inherited code, inherited decisions, work handed over mid-run.
By 2021 I was maintaining that marketplace and building its mobile app in a team. The competition never arrived; the obligation did — and with it a question. How do you decide well without controlling the variables?
Senior Software Engineer
Numbers that belong to someone else
In 2022 I took an employee credit system for a rural credit bank — first commit through to handover. My first project owned end to end, in the least forgiving domain I had touched.
An employee credit system has no cosmetic bugs. A misplaced figure is somebody's debt, and the person it belongs to finds out before you do.
The handover taught me more than the build did. Code you hand to someone else has to explain itself without you in the room — a constraint I have designed for ever since.
Team Lead — Legacy Maintenance
Promoted into other people's decisions
The promotion to Team Lead came in 2023. Not the lead who builds new systems, or the one running the flagship manufacturing project — the one who keeps everything already shipped still running.
This is the part nobody puts in a portfolio. Most of that year was spent inside decisions I had not made, in code I could not rewrite, against timelines I did not set.
It taught the lesson this whole page rests on: you rarely control what you inherit. You only control whether it is more explainable when you hand it on.
Seven years in, this is roughly how I sort it. Try a few before you read where I land — the disagreements are the interesting part.
The codebase you inherit
Where I land: Not controllable — You don't get to pick the decisions already made. You only pick whether the next person inherits something clearer.
A client's deadline
Where I land: Not controllable — Rarely yours to set. What's yours is how honestly you scope against it.
How the codebase is structured
Where I land: Controllable — This one's actually yours. Most of the job lives here.
A teammate's debugging style
Where I land: Not controllable — You can share context and docs. You can't make someone think the way you do.
Whether a third-party API stays up
Where I land: Not controllable — You only control how your system behaves when it doesn't.
Test coverage on what you ship
Where I land: Controllable — Nobody else decides this. If it's thin, that was a choice.
Team Lead
The one that had to be right
Two years, two systems, one engineer on each — traded between them whenever one needed to move faster. Scroll through it — the problem earns the solution rather than being told it.
One company
2024. A payroll system for our own company — small, internal, forgiving. If it broke, I heard about it down the hall.
It ran correctly for a year, and became the foundation the client build started from — not a rewrite, an inheritance.
2025. The same problem for a client, at more than 800 employees. A wrong figure was no longer a bug report. It was a wage that did not arrive.
So I built for re-derivation before speed: every number traceable to its inputs, every run reproducible from scratch.
Delivered June 2026. It has been running since, and I still maintain it — which is its own kind of verdict.
Stated formally
- Premise I
- A payroll error is not a defect report. It is a wage that did not arrive.
- Premise II
- A figure that cannot be re-derived from its inputs can only be trusted, never verified.
- Conclusion
- Build so every figure can be re-derived. Trust is not a control.
Team Lead
Where that leaves me
So — the question from the beginning. How do you decide well without controlling the variables?
I still have no clean answer to the question from 2019, and I have stopped expecting one. What I have is a method: separate what you can design — boundaries, ownership, traceability — from what you can only answer.
I never chose this field for love of it. I stayed because people depended on the work being right, and that turned out to be the more durable reason.
Alongside the payroll work, the company trusted me with a side project between March and June 2025 — a cross-country initiative meant to test whether I could hold my own next to engineers from other countries.
Selected Work
The systems behind the story, written up in full.
2024 — 2026 · Team Lead
Payroll for 800+ Employees→
A payroll engine where every figure has to be re-derivable from its inputs — Indonesian tax and social-security rules, idempotent runs, and an audit trail across ten entities.
- NestJS
- TypeScript
- MySQL
- AWS SQS
- React.js
- Docker
2022 · Senior Software Engineer
Employee Credit System for a Rural Credit Bank→
My first project owned end to end — first commit through to handover — in a domain where a misplaced figure is somebody's debt and the system's output is a signed contract.
- Node.js
- Express.js
- Sequelize.js
- MySQL
- React.js
Tech Stack
The tools I reach for — chosen for what stays boring under pressure.
Frontend
- React.js
- Next.js
- Flutter
- TypeScript
Backend
- Node.js
- Express.js
- NestJS
- REST API
- Sequelize.js
- JavaScript
Infra & Tools
- MySQL
- Docker
- GitHub
- Postman
Who this is for
Reach out if any of this sounds like your system, not mine.
- A wrong figure has legal or financial consequence — payroll, lending, compliance, anything that produces a number someone signs.
- A payroll, lending, or compliance codebase nobody currently understands end to end.
- A team that lost the senior engineer who held the context.
- A system that has to survive an audit, or a handover to a team that wasn't in the room when it was built.
- Remote-first
- WIB · UTC+7
- EOR, contract, or full-time
- 2-week notice
Want the next chapter written on your team?
Reach out directly — no forms.