Tech blues in early stage startups

Too often, I see startups running into serious issues because their technology infrastructure and engineering discipline has not kept pace with the growth of the business. Most companies start out with the 2–3 founders and early engineers hacking up the initial tech to get the initial product out of the door. Then comes the funding, pressure to grow business quickly, release apps on new platforms, add features. Company hires more engineers to cope with up with this but what most founders don’t realise is that their initial architecture, code base, coding practices that worked when they were at prototype stage no longer works when they have 10–15 engineers with serious demands placed by the business. Result: Long iteration cycles, frustrated engineers, and frequent outages. Not something that you can afford for a long time. I understand it is often hard for the tech team to resist the pressure to just get things done somehow. Basically, you need to take 2–3 weeks to set your tech stack, processes in place before you resume the march for greater glory. Typically, this happens couple months after Series A when the company is trying to scale fast so it is important to set your VC’s expectation also when you are undertaking this exercise.

Now most of the below is not rocket science, but given our young ecosystem with majority first-time founders and engineers who don’t get drilled into these engineering best practices in their careers before, these issues creep up slowly but surely.

  • Code base has become a hairball with one monolithic design resulting in clashing code changes that at best take a lot of time/energy to coordinate and at worst can bring down the service. Plan: Time to hit pause button on new features etc for 1–2 weeks and re-architect your code for a tiered and API based design.
  • Lack of engineering processes with a complete free for all. Plan: Put in place basic engineering processes: peer code reviews, continuous build and integration, test and staging processes for developers to test new releases, tracker tools like Asana or Trello for better planning, A/B testing frameworks etc.
  • Lack of automation in analytics and dashboards. There are lots of reports being prepared by people running manual queries, collating data from multiple databases. So reports are either not there when you need them or you are wasting valuable human effort. Plan: Automate common/recurring reporting queries. Beyond basic scripting, this might also be a good time to invest in building your data analytics backend.
  • In some cases, it is also time to evaluate if you need to change all or parts of your stack. Sometimes, the tech founder picks a stack based on his comfort but sometimes it is not the most optimal choice. Maybe it is inadequate for the increasingly complexity, or you may not be getting enough engineers who are trained in it. In Indian context, I have seen the latter problem happens with more modern stacks like Erlang, Scala.

When you do the above steps, you should also put in place metrics that measure how the health of tech base is improving: frequency with which releases happen on schedule, number of regressions and release rollbacks, time spent on regression vs on building new features etc.

I have seen tremendous improvement in team’s morale and execution efficiency wherever this is done, though these are just the basics of putting in place an engineering culture that can make a truly great org.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.