The Stack Is Rarely the First-Order Problem.
Three years into running the technology of a bank, I've sat through more stack debates than I can count. Java versus Go. Kafka versus RabbitMQ. Monolith versus microservices. Each conversation is conducted with the same quiet intensity — as if choosing the right runtime would solve the problem nobody has actually named yet.
It won't.
The stack is to software what the engine is to a car. It sets the outer bounds of what is possible, but most organizations don't fail because they picked the "wrong" engine. They fail because the steering is broken and the map is upside down.
The Mirage of the Technical Fix
Over the years, I've watched technology organizations develop an expensive habit: confusing visible friction with root cause. When a system slows down, the stack is "outdated." When delivery becomes inconsistent, the architecture is "legacy."
This instinct is understandable. The stack is tangible; it gives leadership something concrete to debate. But in reality, stack is less like a broken machine and more like what Kelsey Hightower calls "hairline fractures" — subtle structural weaknesses that function well enough until the pressure of scale or the friction of modernization exposes them. It works, but it hurts like hell when you touch it.
Misdiagnose: The Institutional Fracture
Too often, companies assume the visible layer is the root layer. But replacing the stack without diagnosing the institutional fractures simply packages dysfunction more efficiently.
The real bottlenecks are almost always one of three things:
Unclear Ownership. When everyone owns the system, nobody truly owns it. Decisions that should take a day take a month, and technical debt becomes "someone else's problem."
Missing Feedback Loops. Without fast feedback from tests and monitoring, teams slow down out of fear. Fear is the real performance killer, and the stack gets blamed for it every time.
Misaligned Incentives. When engineers are rewarded for individual heroics rather than team throughput, you produce dysfunction regardless of what's running underneath.
When the Stack Actually Matters
This is not an argument that technology is irrelevant. There are precise, brutal moments when the stack stops being a background detail and starts being the primary blocker to survival.
Economics. When your success becomes your liability because costs scale linearly with your revenue, you must move.
Talent Ecosystems. If your stack requires a niche language that only 50 people in your region speak, you aren't an engineering org — you're a museum.
Structural Bottlenecks. When your business model requires sub-millisecond concurrency and you're fighting a runtime built for CRUD apps, you're not optimizing; you're delusional.
In Tokobagus and MatahariMall, we shifted stack and technology ecosystems not because of fashion, but for Constraint Removal. We moved because the business equation — flexibility, cost, and talent depth — had changed.
Stack as Institutional Design
Stack is no longer evaluate as technology selection; it is evaluated as institutional design. A language or platform is a holistic system. It is a hiring model, an operational burden, a security posture, and strategic leverage.
This changes the conversation from "What is the best stack?" to the more serious question: "What constraint is our current environment preventing us from overcoming?"
The Sequence of Transformation
One of the most expensive mistakes I've made is trying to modernize the stack before strengthening the fundamentals. We try to rewrite before we standardize; we migrate before we govern.
Fundamentals. Make deployment so boring it generates very minimum conversation.
Cohesion. Establish shared principles. Conway's Law is real: your architecture will always mirror your communication structure. Build loosely coupled teams first; the architecture follows.
Challenge the Stack. Only now can you distinguish between "the stack is limiting us" and "our operating model is limiting us".
Stack is leverage. It can amplify a brilliant design or institutionalize a disaster.
— KomangWhatever ships best for this context
It sounds like a dodge. It is actually the most sophisticated answer in the room.
Looking back, my career isn't a sequence of migrations; it's a sequence of learning when technology was truly the bottleneck — and when it was just exposing the fractures we had been tolerating for too long.
Stop fighting identity wars dressed in technical language. Fix the feedback loops, clarify the ownership, and find the Fit.