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 features that answer questions about an app's own data, built on both the backend and the interface.
• Performance work across rendering, database queries and API response times.
• Product discussions on features and user needs before the build.
• Digital marketing on Meta Ads, including the ad content.
• Architecture discussion, code review and deployment, not only feature work.

Beyond the code

I work on the product side here as well. Before a feature is built I discuss it with the product managers and designers: what the people using that app need, and how much of it to build first.

I also handle digital marketing on Meta Ads, including creating the ad content.

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.