Muhammad Royhan
Senior Fullstack Engineer · Team Lead
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
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 an ERP build and a rental marketplace someone else had started — inherited code, inherited decisions, a project 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.
Banking software 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, a side project between March and June 2025 carried the same discipline into a team spanning more than one country.
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
Want the next chapter written on your team?
Open to Senior Fullstack Engineer and Team Lead roles, remote-first. Reach out directly — no forms.