The OJK auditor was on the call. I was sharing my screen. And the app crashed.
No senior engineer to ping. No team lead to escalate to. Just me, a system I had rebuilt from scratch over the past several months, and a government regulator watching in real time.
That moment is burned into my memory — not as the worst day of my career, but as the most clarifying one.
The Situation I Walked Into
I joined a fintech startup as the sole backend developer. What I found on day one: no handover document, no architecture diagram, no README, no one to ask. The previous developer had already left.
The existing system was a PHP Laravel monolith running on CentOS, with a React Native mobile app, MySQL, and two Alibaba Cloud instances — one primary, one for mirroring. It had been running for years. Nobody fully understood how it worked anymore.
The company held a P2P lending license and was under pressure from OJK (Indonesia's financial regulator) and AFPI to bring the system up to compliance standards. The director gave me the brief and one key piece of information: most of the core operations had been running manually.
Within months, the director stopped coming in. I later learned the company was facing serious financial difficulties. By that point, I was the only person in the office — me and one admin.
I kept building.
First Decision: Don't Rewrite Everything at Once
The legacy codebase was beyond patching. A full rewrite was necessary. But rewriting an entire fintech platform alone is not a sprint — it's a months-long commitment with regulatory deadlines attached.
My decision: rewrite incrementally. Start with authentication only. Prove the new stack works. Then expand.
New stack: NestJS on the backend, Next.js for the web frontend, Expo for mobile, Ubuntu replacing CentOS, Docker for containerization.
The auth system was completed. Clean, working, deployable.
Then I got the feedback from OJK: a partial system is not acceptable for audit. The entire platform needed to be functional — not just authentication.
I had made a technically sound decision with a faulty assumption. I had not validated the audit scope with the regulator before committing to the incremental approach.
That was the first real lesson.
What I Built, Alone
Over the following months, working without a team, without guidance, and with a paycheck that arrived increasingly late, I built:
Two-factor authentication (password + OTP via email and phone)
KYC flow with face photo upload
DigiSign integration for digital signatures
Full migration from monolith to microservices
AFPI Data Center integration for regulatory reporting
Loan application flow with approval stages, interest calculation, tenor management, and insurance integration
BNI sandbox integration, tested through to live transaction
Mobile app rebuilt in Expo
CI/CD pipeline with Jenkins and Docker on Ubuntu
All of it, in parallel, without a senior engineer to ask.
The Audit Day
When the OJK audit session came, the system had most of its core features working. But during the live demo, there was a bug. The kind that only appears under pressure, in front of the people you least want to see it.
The audit did not proceed.
I am not going to reframe this as a hidden success. It was a hard moment. The system I had poured months into — alone, under financial stress, in an increasingly unstable company — did not make it through the finish line that day.
But here is what I know: the system ran. It processed real transactions. It integrated with government data centers. It had security layers that the original system never had.
It just wasn't enough, on that day.
What I Actually Learned
Validate assumptions with your stakeholders before committing to an architecture decision.
Incremental migration was the right technical call. But I assumed OJK would accept a partial system without confirming it first. That assumption cost months of work. Now, before I make any significant architectural decision, I ask the hard question upfront: what does "done" mean to the person who will evaluate this?
One database per service is not optional in microservices.
Early in the build, I made a mistake I only recognized later: I created a dedicated Express service for the service bus, but gave each service its own MySQL instance rather than its own database on a shared instance. The RAM cost was immediate and painful. I fixed it — but I learned the principle properly only by feeling the consequence.
Working without a team teaches you things a team never would.
When there is no one else, every architectural decision is yours. Every bug is yours. Every late-night debugging session is yours. It is uncomfortable in ways that are difficult to describe. But the outcome is a developer who can read an unfamiliar codebase, make decisions without guidance, and stay functional when the environment is unstable.
The platform never went live. The company did not survive its challenges.
But every system I have built since — at Telkomsel, at Astra Group — carries the decision-making instincts I developed in that office, alone, with a legacy codebase and a deadline I could not fully control.
That is what the hardest projects give you. Not a success story. A foundation.
Top comments (0)