Lesson 14C - Choosing the right tech stack

Most tech stack debates are really product debates that nobody has named properly. One person is arguing for speed. One is arguing for control. One is arguing for résumé value. Somebody says "scalability" because it sounds responsible. Then the team walks out with a stack decision that has more ego than evidence.

Your actual job is not to pick frameworks from memory. It is to force the room to answer three questions in the right order: what are we building, who is building it, and what can we borrow instead of building from scratch? If you get those three right, the stack usually becomes obvious. If you get them wrong, the team will spend months solving imaginary problems.

You will face this early in product work because technology choices harden fast. A bad survey question can be rewritten next week. A bad onboarding screen can be redesigned next sprint. A bad stack decision sits underneath every release, every hiring plan, and every missed deadline. That is why PMs need judgment here even when engineering owns the final implementation details.

Tech stack choice is a product decision wearing engineering clothes

The trap is to treat stack choice as a private engineering matter. It is not. The moment a technology decision changes launch speed, platform reach, hiring cost, or the shape of the user experience, it becomes product work.

The cleanest way to think about it: a tech stack is just the set of constraints you are choosing to live with for the next 12 to 24 months. Some constraints buy speed. Some buy control. Some buy performance. Some buy nothing except bragging rights.

That is the pattern. Teams rush to "Flutter or React Native or React or Go or Django?" before they have mapped the user jobs cleanly enough. You should slow that down.

A stack does not serve the product in the abstract. It serves specific user behaviour, specific workflows, and a specific stage of company. Swiggy's delivery partner app has one set of needs: location access, constant movement, unreliable connectivity, and push-heavy operations. Razorpay's merchant dashboard has another: dense information, admin workflows, longer sessions, and desktop usage. If you collapse those into one vague requirement called "build an app," you will get weak architecture and weaker product decisions.

Mobile versus web is really a bet on user behaviour

Most PMs confuse platform choice with fashion. It is a usage-pattern question first.

If the product depends on device hardware, frequent notifications, background activity, offline tolerance, or quick repeat actions through the day, native mobile deserves serious weight. If the product depends on discovery, search visibility, link sharing, long-form consumption, dense workflows, or cross-device access, web usually deserves serious weight. And if the product serves two different jobs, you may need both.

You do not win points for forcing everything into mobile. You do not win points for insisting everything can live on web either. You win when the first version matches the highest-value user behaviour.

Consider a product for kirana store owners. If the core action is quick restocking during store hours, a phone-first experience may matter. If the core action is reviewing margins, exports, and inventory reports during the evening close from a laptop, web may be the right first surface. In practice, many Indian products serve both patterns. Zerodha knows a serious trader behaves differently from a casual mobile user. That is why surface decisions cannot be reduced to ideology.

What I tell PMs is simple: write down the top five actions a user must complete in week one. Then ask where those actions naturally happen. Standing on a street with one hand free? At a help desk? On a warehouse floor? At a desktop in an office park in Hyderabad? That answer should shape the stack more than any conference talk.

The stack you can hire for beats the stack you admire

The second failure mode is fantasy staffing. A founder sees what a large company uses and assumes a four-person team can execute the same playbook. They cannot.

Your engineers are not abstract resources. They are people with strengths, habits, gaps, and hiring markets attached to them. If your current team is strong in React and Python, that matters. If your next two hires in Bangalore are much easier to find in TypeScript than in a niche systems language, that matters. If your only mobile engineer is leaving in eight weeks, that matters even more.

That conversation is more mature than "Go is faster" or "Python is easier." It ties technology back to the roadmap.

The best early stack is usually the one the team can ship, debug, hire for, and hand over cleanly. Not the one that looks most sophisticated in an investor update. I have watched thousands of PMs get trapped by borrowed technical ambition. The team spends two quarters learning the stack while competitors spend two quarters learning the customer.

This matters even more in India because hiring markets are uneven. You may find strong React and Node engineers in Bangalore or Hyderabad quickly. You may struggle to build a dependable iOS team in a smaller city if your compensation band is tight. A PM who ignores that reality is not being strategic. They are writing product plans on top of nonexistent teams.

Open-source speed usually beats custom pride

The third question is the least glamorous and often the most important: what work can you avoid?

Most products do not need custom everything. They need credible velocity. Authentication, payments, search, analytics, file storage, CMS tooling, and commerce infrastructure often have mature options already available. GitHub remains a good starting point because it shows you what the developer community has already solved, where the rough edges are, and how active the maintenance is. Older commerce systems like Magento still teach the right lesson as well: if your business is standard enough, standing on proven tooling is usually wiser than inventing a foundation.

That does not mean you blindly import libraries. It means you ask whether the thing you are about to build is core differentiation or expensive plumbing.

If you are building a B2B ordering product for distributors in Indore, your edge is probably not a homegrown auth system, a custom payment gateway, and your own notification pipeline. Your edge is the workflow: reorder speed, catalog clarity, margin visibility, and operational reliability. The more energy you spend rebuilding commodity layers, the less energy you have for that core.

There is also a PM lesson here about sequencing. You can begin with managed services and open-source components to get to market fast. Later, if scale, compliance, cost, or control genuinely demand it, you can replace pieces deliberately. Razorpay's payment reliability requirements are not the same as a seed-stage SaaS tool selling to 20 design agencies. Treating them as equivalent is how teams overbuild.

Scalability matters, but premature architecture is still waste

Every sloppy stack decision eventually gets justified with one serious-sounding word: scalability.

Scalability is real. Ignore it and you will regret it. But most teams invoke it too early and too vaguely. The question is not "will we scale someday?" Of course you hope you will. The question is "what scale risk is likely enough, soon enough, and expensive enough to justify present complexity?"

Most PMs confuse future possibility with current probability. A dispatch system like Swiggy's or a payments core like PhonePe's needs a different level of reliability planning from day one because failure is immediate and visible. A new B2B workflow tool with 30 pilot customers usually does not need microservices, multi-region infrastructure, and a platform rewrite before the first meaningful feedback loop.

Let me be direct about this: a simple monolith that ships and survives is better than a distributed architecture that never reaches users. The internet loves stories about elegant systems. Users only experience whether your product works.

This is why your stack recommendation should come with explicit thresholds. "We stay on this backend until we hit X latency problem, Y transaction volume, or Z operational burden" is a strong PM move. It replaces vague future fear with a measurable trigger for change.

Your job is to make the trade-off legible

You are not the architect. You are not supposed to out-code the engineering lead. That is not the standard.

Your standard is sharper than that: can you make the product consequence of a technical choice visible to the room? Can you surface what the company gains, what it delays, what it risks, and what it avoids?

In practice, a good PM stack conversation sounds like this:

• If we choose native mobile first, we gain better device access and notification reliability, but we delay desktop workflows and widen the hiring need.
• If we choose responsive web first, we gain speed and reach, but we accept weaker hardware integration and a less app-like repeat-use experience.
• If we keep the current backend, we ship the pilot in 10 weeks. If we rewrite now, we spend those 10 weeks buying technical confidence instead of user evidence.
• If we use existing tooling for auth, payments, or commerce, we move faster, but we accept some dependency constraints until scale proves otherwise.

That is the entire profession in one line. You turn hidden engineering trade-offs into product decisions the company can actually make.

Test yourself: The Pune logistics stack call

You are now in the room. Make the call.

Where to go next

• If you need to collaborate with engineers without drifting into ticket-pushing: Working with Engineering
• If your stack debate is really a discovery problem in disguise: User Research Methods
• If you need to turn product thinking into clearer build instructions: Writing PRDs
• If you want the strategic lens before the architecture argument starts: Product Vision and Strategy
• If you want the broader mindset behind making trade-offs like this: Product Thinking