Session · Internal sharing · Netmonk, Telkom Indonesia
Optimal Decision Making Process for Choosing the Right Tech Stack
Choosing a tech stack is usually argued on preference. This session reframed it as a decision with a method behind it: weighted factors, an impact/effort matrix, and arithmetic that tells you whether the work pays for itself.
Reva Wiki
Overview
An internal engineering session for the Netmonk team at Telkom Indonesia. Tech stack decisions were being made the way they usually are, on familiarity and preference, and I wanted to give the team a repeatable way to argue them instead.
The framing was deliberately non-technical to start with: a tech stack defines the team as much as the product. It sets hiring criteria, the learning curve for everyone who joins, and where the team's expertise concentrates. It also drives business outcomes: cost, longevity, and time to market. Get it wrong and you have made a hiring problem and a business problem, not just an engineering one.
Key Takeaway
- Tech stack equals team composition.
The moment you pick the stack you have picked your hiring pool, your onboarding curve, and where expertise will concentrate. That is a people decision wearing an engineering costume. - Effort is only half the question.
The priority matrix stops teams from spending months on low-impact work simply because it was easy to start, and from dismissing high-impact work because it looked expensive on day one. - Automation has a break-even point, and you can compute it.
Before building an automation, multiply the current time spent by how often it happens. If the build costs more than that, it is not automation, it is a hobby.
Summary
Four parts, moving from what to weigh, to how to prioritise, to whether it is worth doing at all.
-
What a tech stack actually decides
Team composition and business goals, not just architecture. Everyone should feel confident in the tools they are using, and the choice has a direct impact on how well the team scales. On the business side: cost, longevity, and time to market, because companies that adopt and adapt faster leave the competition behind.
-
The factors to weigh
Split into external and internal. External: functionality, scalability, maintenance and support, supported target platforms, security, cost, and maturity. Internal: project requirements, technical constraints, compliance and regulations, team expertise, and prototype testing and evaluation. The internal list is the one teams skip, and it is usually the one that kills the decision later.
-
The action priority matrix
Impact against effort, four quadrants. High impact + low effort is Great, execute it. High impact + high effort is Good, but only if conditions allow. Low impact + low effort is Weak, so try to increase the impact first. Low impact + high effort is Bad, so focus on other ideas.
-
Does it actually pay for itself?
The part that turns opinion into arithmetic. An effort is worth it when time to complete the effort < current time spent × frequency, and the same inequality with cost substituted for time. We worked two live examples: a banking process taking 40 minutes weekly against a 10-hour build (break-even at 15 weeks), and Netmonk's own manual client fulfilment, 30 minutes each, 20 clients a day, against one week of automation work. 2400 < 3000: worth proceeding.
Closed on technology gap analysis, comparing the current condition against the desired outcome across what, when, why, and how, then turning the gap into a roadmap plan.