Trade-offs leading tech at early-stage startups

If you're a first-time tech founder or lead at a startup, you'll find yourself spending an inordinate amount of time making trade-offs. You'll need to pick a tech stack that works for your team; decide how much time to invest in visual design; balance your vision with the most valuable thing you can deliver to your user right now.

This post intentionally confronts this controversial topic head on. I feel it's a topic that's not talked about nearly enough. Tech founders and leads often find out they'd spent countless hours on creating something no-one wants only after the fact (myself included). Having built tech from scratch at multiple startups and talked to other tech founders in the past, I've noticed that some (if not many!) first-time founders and tech leads find out the hard way that they may have taken the wrong turn when they were presented with a trade-off.

Here, I talk about the most common "questionable turns" taken that I've experienced for myself, heard about or seen others experience. These thoughts may be controversial and you might not agree with most of them but I will feel I've contributed something if you might agree with just one!

• Tech stack: Some founders spend lots of time thinking about the tech stack, trying to pick the "perfect" technologies. It's good to explore. But don't spend an inordinate amount of time thinking about it. Before I joined my first early-stage startup, I was given helpful advice (from my CTO at the time) to "just build". Your startup might not exist in 18 months. Pick things that work right now.
• Hire the right people: I was really lucky when we hired someone who was extremely talented at my first tech lead role. I learned things daily from him. He had opinions (something I've come to value a lot). We iterated fast. I've seen the opposite however too: hires who've struggled to push any code and shown not much engagement despite trying to accommodate. Founders inevitably need to make a decision whether or not to let that person go, so make sure to hire well (or be prepared for it to hurt!).
• Trust: Give everyone the benefit of the doubt. At the beginning, everything might be all over the place. That's ok. Introduce or suggest the right processes that you and others can trust. That way, structure will come and you'll be able to make progress. If there's distrust from the get-go, it'll be hard to make it work long-term. Everything will feel "transactional".
• Testing: One experienced CTO once told me that testing is overkill at a startup pre-Product-Market Fit (PMF). And I think he's mostly right: at many startups, if you're iterating fast, you'll be throwing away lots of code. Yes, there are some exceptions — code for financial transactions, mission-critical applications, etc. where bugs can be disastrous — but for most pre-PMF startups that are creating a few REST APIs and a React.js front-end, focusing on testing may be overkill. Start testing when your product starts to stabilise. Be comfortable with tech debt. You can address tech debt when you reach Series A and your team is growing (when there's an obvious need for tests). It's ok to do things that don't scale at first.
• Documentation: Only document as much as you need to communicate with your team. Creating a big project implementation plan may be a waste of time in a small, nimble team. Instead, make sure to communicate in daily stand-ups, comms tools, etc. Similarly, documenting code is secondary at an early stage. You may throw away lots of code and the API may change a lot. Note: this is not to be confused with good practices, such as good naming conventions and code structure, which are a must. Documenting code will become a productivity multiplier once you have more than a few engineers but not until then.
• Goals: Make sure to define goals. You might think building tech counts as progress. It is but only if it's contributing to your company's wider goals. Without goals, you'll have less alignment in the team (yet another risk you can't afford at an early stage) and you're leaving success to chance.
• Analytics: Similarly, make sure to install analytics from an early stage, tracking the most important metrics. I've seen founders regret not measuring early enough. That includes me!
• Design: Both UX and UI design are fluid, especially at the start. You're still trying to find PMF, so naturally your UX will evolve. UI design and the visual language will change as your branding becomes more clear. Therefore, spending an inordinate amount of time creating the perfect design system is a bit of an overkill. I would suggest sitting down with the designer to work out the most pragmatic path to a product that allows users to accomplish their jobs (if you're using JTBD). Often designers are just trying to paint the "ideal" picture. Designers are very pragmatic and will design around technical limitations if you flag them. Also, some product designers may prefer using existing design systems to iterate faster (such as Material, Bootstrap or Tailwind).
• Speak to users: You might be getting siloed in "tech", either because responsibilities are defined in binary or there's so much product development to do that you don't have time for other things. If it's the former: ownership doesn't mean others can't be involved. Speaking to customers can be driven by your co-founder but your team will benefit from your involvement as you'll better understand what product to build. If there's too much on your plate: ask yourself, would you prefer to do things the right way or do the right things? Speaking to users de-risks the possibility that you're building the wrong thing.

Here are some rule-of-thumbs that have helped me, with some of the trade-offs above:

• Pick speed and limit scope: The Product Management Triangle: you can only pick two of speed, scope and quality. Obviously pick speed, as iterating is key to developing product at an early stage. Of scope and quality, try to limit scope so as to minimise the sacrifices you make with quality. Also, limiting scope will help you iterate faster.
• Over-communicate: Always over-communicate your intentions. You might be a small team but it never hurts to share too much. It's never too early to introduce 1-on-1's. If silence is the norm in your startup, ask yourself if that's ok. If silence is the manifestation of lack of trust or "we have nothing to talk about but work", then it might need addressing. Your opportunity cost is your time, so make sure that whatever you're working towards is communicated!
• Be pragmatic: Not everything is black-and-white. So making a rule in the first week and expecting it hold for the next months is unrealistic. Take information as it comes and act on the information. The startup that processes the information most efficiently (the advantage of being a startup!) often makes the most progress.

These are just some of my thoughts around tech founder trade-offs. Some may be controversial but I hope there may be some things that you could relate to, from your current or past experience.