In conversation with Editor Ankur Sharma, The News Strike, Nandagopal P, CEO of Asymmetri, CTO at Gacsym Ventures, and Limited Partner at Arya Ventures, highlights how today’s startup ecosystem is increasingly defined by premature complexity, with founders over-engineering solutions before validating real market needs and mistaking speed for progress. He underscores that scalable technology is rooted in disciplined early decisions rather than sophisticated architecture, and that the modern CTO’s role is driven more by business judgment than technical depth. He points out that many startups remain overly funding-driven, often losing sight of genuine problem-solving, while true product-market fit is reflected in organic user behavior rather than vanity metrics.
Question 1. Are most startups today over-engineering before truly understanding the problem they're solving?
Yes, and it's getting worse. I see this constantly: teams building multi-region distributed systems for a product with 200 users. Part of this is cargo-culting from big-tech playbooks that have no business being applied to early-stage companies. Part of it is founder insecurity disguised as ambition. If you're spending architecture time solving problems you don't yet have, you're usually avoiding the scarier thing: going out and genuinely stress-testing whether anyone needs what you're building.
Question 2. What separates scalable tech architecture from "just working" products in early-stage startups?
A "just working" product can still evolve cleanly if the person who built it made a handful of decent decisions early: a coherent data model, sensible service boundaries, some visibility into what's happening in production. The companies I've seen really suffer at scale are the ones where the early code has zero observability, where core domain logic is tangled into the UI layer, or where database schemas were never thought through. These aren't complexity problems. They're discipline problems. Scalable architecture in the early stage just means not making decisions today that cost you six months of re-platforming in eighteen months.
Question 3. How do you decide when to prioritise speed versus technical depth in product building?
I ask what would actually kill the company in the next 90 days. If you don't have product-market fit, slow shipping velocity is existential. If you're already onboarding enterprise customers and your security posture is a mess, that's the existential risk. Most early teams default to speed because it feels productive, but the real discipline is knowing the difference between speed that reduces uncertainty and speed that just creates more technical debt without learning anything. I've also found that teams who cry "we need to move fast" often have the messiest codebases, not the cleanest. Real speed requires enough discipline that you aren't constantly fighting your own previous decisions.
Question 4. Is the role of a CTO today more about technology or business judgment?
Business judgment, without question. I've met technically brilliant CTOs who nearly ran their companies into the ground because they couldn't connect infrastructure spending to commercial outcomes, or because they optimised for technical elegance in ways that killed the product roadmap. The best CTOs I know spend as much time thinking about where technology creates or destroys competitive advantage as they do on engineering specifics. They're often the ones in the room asking uncomfortable questions about whether a feature actually moves a business metric, or whether a rewrite is genuinely necessary or just an ego project.
Question 5. Has the startup ecosystem become too funding-driven and less problem-driven?
In patches, yes. There are periods when raising a round becomes a legitimising event that lets founders avoid the harder work of proving demand. I've watched companies raise tens of millions on a narrative and spend two years finding out the market didn't care. The founders who last are the ones who are genuinely irritated by an unsolved problem, not excited by the funding process. Capital is a resource. When it becomes the scoreboard, you lose the signal that actually tells you whether you're building something real.
Question 6. What early signals do you look for to assess whether a startup has real product-market fit?
I pay very little attention to usage numbers at early stage. What I want to see is behaviour that no one coached. Are users figuring out non-obvious use cases on their own? Do they get visibly frustrated when the product is down? Are they referring people without being asked? One of the clearest signals I've seen: when a customer tells you "we built our whole workflow around this" before you've even launched officially. The other telling signal is churn shape. With genuine PMF, churn tends to be segmented and explainable, not random.
Question 7. Are founders underestimating the complexity of scaling technology compared to scaling business?
Yes, but I'd frame it differently. The scaling problems are almost never about the technology itself. They're about the decisions baked in early that nobody documented, the implicit knowledge that lived in two engineers' heads who are now gone, and the data models that made sense for ten thousand users but create cascading issues at ten million. Technical scaling is really an organisational and decision-quality problem that just happens to manifest in the codebase.
Question 8. What are the most common blind spots founders have when building tech-led companies?
Two things stand out. First, mistaking product velocity for company building. You can ship fast and still be building the wrong thing, for the wrong people, with a team that's quietly burning out. Second, a surprising number of technical founders genuinely believe that a better product wins by default. Distribution and positioning are afterthoughts until it's too late. I've seen genuinely superior products lose badly to inferior ones built by teams who understood their go-to-market cold.
Question 9. If AI commoditises software development, what becomes the real competitive advantage?
Taste and restraint. When building is cheap, the decision of what not to build becomes enormously valuable. Companies that survive will have figured out a specific customer relationship, or proprietary data, or domain insight, that can't be replicated just by running the same models faster. Software was always the easy part of most businesses. The defensible parts were always the customer trust, the institutional knowledge, and the distribution. AI just makes that more visible.
Question 10. Is burnout in tech more a systems problem or a leadership failure?
Both, but leadership is accountable for the system, so the distinction doesn't get anyone off the hook. Most burnout I've seen isn't about workload alone. It's about people operating under sustained uncertainty with no agency and no visible progress. That's a design choice at the organisational level. Leaders who say "we hire adults, they manage themselves" are often the ones presiding over teams quietly falling apart. The best engineering cultures I've seen have high standards and real clarity: clear priorities, explicit tradeoffs, and leaders who absorb ambiguity upward rather than letting it trickle down and corrode the team.
Question 11. What kind of founders will succeed in the next 5-10 years that may fail today?
Founders who are genuinely comfortable operating with less certainty and more noise. The next decade is going to keep shifting the foundations: AI capabilities, regulatory environment, attention economics. Founders who need a stable playbook will struggle. What I'm watching for is people who have a point of view that's specific and defensible, who can hold conviction without becoming rigid, and who build trust quickly because trust is increasingly scarce in a world of abundant, cheap software. The winners won't just be technically sharp. They'll be genuinely curious about their customer in a way that doesn't turn off after they've raised their Series A.
