Interesting work rarely starts with a clean specification. It starts with incomplete information, competing constraints, and a problem that needs to become real. I work across engineering, product, and design to understand the problem, build what matters, and leave the system easier to evolve.
Works.
The problems worth solving usually sit between business rules, operational reality, product intent, and engineering constraints. These are systems I have made coherent across people, processes, interfaces, and infrastructure, where gaps between them have real consequences.
Nationwide ERP for Samsung & Xiaomi Distributor
Used by PT. Sinergi Sukses Mobilindo.
A business critical ERP spanning inventory, finance, purchasing, sales, reporting, and partner management across distributed branches. The challenge was not adding another module. It was making diverse daily operations behave like one coherent system.
Booking for Personal Gym Room Service
Used by The Private Gym.
A focused product built to test the business model before building the organization around it. The system starts deliberately small, while its boundaries anticipate the complexity that appears later: tenants, payments, automation, dashboards, and multiple client surfaces.
Peer to Peer Financing for Prop Tech
Used by PT. Bina Asia Propertindo.
The financing layer behind a property rental product, separating a simple borrower experience from the machinery underneath: funding, approval, disbursement, repayment, and external financing partners. The architecture had to absorb change without turning every new provider into a rewrite.
Approach.
Good work rarely moves in a straight line from idea to implementation. The valuable part is knowing which uncertainties to investigate, which constraints are real, and which assumptions are costly enough to challenge before they harden into architecture.
[01] Start With the Problem.
A request is rarely the actual problem. I look for the business rule, user behavior, operational constraint, or missing decision underneath it. Technology comes later, once there is something worth solving.
Question: What needs to become true?
[02] Make Uncertainty Explicit.
Not every unknown deserves a week of analysis. Some need a prototype, some need a number, and some need a conversation. I separate what we know from what we assume, then focus effort where being wrong would be costly.
Question: What don't we know yet?
[03] Shape the Smallest Useful System.
Architecture should create room for change without paying for hypothetical scale. I prefer clear boundaries, explicit domain models, and simple mechanisms first. Abstraction, infrastructure, and distribution come when the problem earns them.
Question: What is the simplest system that can survive the next stage?
[04] Build Across the Seams.
Difficult parts often sit between disciplines. A product rule may not map cleanly to operations, an interaction may hide system complexity, or an elegant architecture may be expensive to evolve. Those seams are part of the engineering problem.
Question: Where does the real complexity live?
[05] Let Reality Change the Design.
Production reveals what specifications cannot: unexpected behavior, operational friction, performance limits, and new constraints. I use those signals to improve the system instead of defending decisions made before reality arrived.
Question: What did reality teach us?
[06] Leave the System Better Understood.
A system should remain legible as it grows. Its important decisions should make sense to the engineers maintaining it, the product people changing it, and the business relying on it. Good architecture does more than work. It makes the next decision easier.
Question: Will the next decision be easier to make?
Labs.
Production work rewards reliability, while experiments reward questions. Labs are where I deliberately remove some usual constraints, testing architectures, rendering techniques, infrastructure ideas, and new interfaces to understand what survives contact with reality.
Minimal Scalable Backend
Status: Thesis in progress · Architecture experiment.
Exploring a minimal backend that treats API generation and the client experience as one system. The goal is not to recreate a large platform in miniature, but to find a portable architecture that can evolve from a modular monolith into independently scalable services.
Making LLM Inference Cheaper
Status: Thesis in progress · Systems experiment.
Inference cost is increasingly a systems problem, not simply a model selection problem. This experiment explores routing, caching, quantization, and workload aware execution as one optimization problem, balancing cost against quality, latency, and operational complexity.
WebGL Hover Liquid Reveal Effect
Status: Prototype · Visual experiment
A study in making interaction feel physical without making the interface feel busy. Images are distorted and revealed through GPU driven displacement, using a custom shader to turn a familiar hover state into something with movement, resistance, and depth.
WebGL Hover & Scroll Parallax
Status: Prototype · Interaction experiment
Exploring the boundary between spatial feedback and visual noise by combining hover and scroll as inputs to create depth aware interfaces that feel responsive and physical, while keeping rendering cost and interaction complexity under control.
2D SVG to 3D with Three.js
Status: Prototype · Graphics experiment
Exploring what happens when flat graphic assets become the beginning of a spatial system rather than their final form. SVG paths become geometry, geometry becomes depth, and depth becomes an interactive composition through materials and procedural transformation.
Contact.
If the requirements are incomplete, the constraints are competing, or the shape of the system is still unclear, that's often where the useful work begins.