Lumbung internal platformLumbung internal platform

Short explanation

Lumbung Mandiri runs its operations on an internal application platform — task management, financial tracking, activity reporting, operational workflow — spread across more than twenty applications used daily by multiple business units.

I build and maintain them, and I write the Go services underneath them. This is where the frontend title stopped fitting.

• 20+ business-critical applications in continuous production use.
• REST APIs in Go connecting frontends, internal services and third parties.
• AI-powered features built across both layers — service integration and interface.
• Performance work across rendering, database queries and API response times.
• Architecture discussion, code review and deployment, not only feature work.

Why it's built this way

Each business unit needs tooling shaped like its own workflow, but twenty separately-conceived applications would be twenty separate maintenance problems. They share one Next.js and TypeScript foundation, so a fix to the foundation is a fix everywhere.

The APIs are Go for the same reason the frontend is shared: a single service layer that every application speaks to beats each application inventing its own integration with the same third party.

Writing both halves

The thing I'd point at from this job is that I write the endpoints my own interfaces call. When the contract between them is wrong, it's a conversation with myself rather than a ticket and a two-day wait.

That changes what you build. You stop designing endpoints that are convenient for the server and start designing them for the screen that consumes them — and you stop asking the client to do three calls and a merge because the API didn't want to do a join.

The part that was actually hard

Scale of surface, not scale of traffic. Twenty applications in continuous use means twenty things that can break while you're building the twenty-first, and no version of this job involves a quiet week to refactor.

Performance work arrived the way it usually does — gradually, then all at once. Queries that were fine at launch stopped being fine as the data grew, and the fix was rarely in the frontend even when the symptom was.