A Founder’s Guide to Technical Architecture with Subbu Balakrishnan

SubbuTechStarsFounderRetreat

You don’t need to be a technical founder to drive smart decisions on your architecture. Subbu Balakrishnan, CTO at Apres and a longtime technologist, explains the fundamentals of architecture and the natural trade-offs startups founders must take at different stages of development.

Your product’s technical architecture isn’t a one-and-done project. It’s an iterative process that often goes  in cycles — and you don’t need to be highly technical yourself to ask smart questions and drive key decisions about your product’s underlying technology. 

Subbu Balakrishnan, current CTO at Apres and a veteran technologist, says that founders should be prepared to make trade-offs in their technical architecture, and rebuild that architecture a few times throughout the life of the company.

Register here for Subbu’s full webinar on technical architecture to get insights on:

  • Building Your Initial Stack
  • Go-to-Market Models
  • Innovating and Inerating 
  • Informed Risk-Taking
  • Growth vs. Efficiency

“The theory is that you’ll build something three or four times,” says Balakrishnan. “You’re going to build something initially to have an MVP or a proof of concept. Then you might need a version of it that lets you just focus on measurement and iteration. Once you’ve built something that you think people like, then it needs to scale.” 

The proof-of-concept stage, the iterative phase, and the scaling phase each come with different needs, and accordingly, come with differing technical demands that founders should be aware of, no matter your level of technical proficiency. 

“There's a certain level of understanding of how the functionality comes together -- that is non-negotiable.” - @apres_io Click To Tweet

“There’s a certain level of understanding of how the functionality comes together — that is non-negotiable,” he adds. “A nontechnical founder is better informed if they understand that their product is made of these pieces that need to work together.”

The trade-offs in technical decision-making sometimes simply boil down to what you want to spend money and effort on building now versus later. But there are risks in sacrificing time and efficiency, or missing out on an opportunity because you waited too long. 

“The nontechnical founder is more informed if they understand: How does data flow, what needs to happen...and what's easy to do versus what might take some time.” - @apres_io Click To Tweet

“The nontechnical founder is actually more informed if they understand: How does data flow, what needs to happen, and what functionality needs to take place, and what’s easy to do versus what might take some time to do,” Subbu adds. “Having that I think gives founders a sense of informed risk-taking.”

Founders should always ask themselves: What’s the purpose of building a feature? 

“A feature might be: I want to do inventory optimization, and inventory optimization for retailers is a great revenue generator,” Subbu says. “But it’s hard to determine, should we spend 8 or 10 weeks and hire some engineering and do this right now? Or can we test out the idea in the form of metrics that are produced by hand? Arguably, most of these trade-offs are about whether this is the time to do so.”

“Founders should be constantly tuned in to what stage of development they’re in, and what their needs are.” - @apres_io Click To Tweet

In the bigger picture, the trade-offs might also be framed as growth versus efficiency: a constant cycle of acquiring customers, receiving feedback, innovating and iterating — and then focusing on efficiency again. Founders should be constantly tuned in to what stage of development they’re in, and what their needs are. 

“It’s a constant cycle,” Subbu says. “We’re just repeating these three things, and you need to know where you are, so if you’re in the growth mode of things, then you’re less concerned with efficiency.” 

When you find yourself with a stable and dedicated customer base, it may be time to turn your focus to efficiency again: Thinking about costs such as AWS bills, your profitability outlook, and whether you have the right analytics, tracking or other features in place to continue on sustainably. 

“It seems obvious, but your engineering staff are a little bit more focused on making things faster so that your customers are happy, or you’re maximizing your revenue per customer, so to speak,” Subbu adds. “And then there is a stage when you’ve decided now that you need a new set of features — maybe you need to innovate and go back to the first step — because you want to go back to the same set of customers and try to grow them again. And this is a different model altogether.”

Share With Your Network

Looking for startup advice, connections, and insights?

Tap into a global network that enables you to answer questions, build relationships, and gain the perspective you need to move faster.
Peer mentorship with fellow tech founders
Pitch practice with Tier 1 VCs
Accelerator grade discounts