Startup Tech Series #1 - Choosing Technology Stack Principles
In this first post of the series, I identify a few key principles that you need to keep in mind, as a startup CTO, when choosing your technology stack and allocating your technology resources (time & money)
Starting a new business is exciting and challenging, finding the right product for the right market at the right time with the right people is an alignment that is hard to achieve. All starting businesses are inherently a complex system, with many moving pieces, interacting under uncertain rules and conditions, their friction creating value or issues for your embryonic organization. As a startup leader, your daily goal is to manage available resources that will help fuel your startup growth, allocating them to the most positively impactful spot. Everything adds up to time and money at the end of the day, but one aspect of every modern startup that usually grab a big resource portion is the technology stack supporting your startup.
This blog series will go through various choices you need to make as a startup CTO to maximize your usually scarse resources and deliver as much value as possible to your organization. There are so many options out there, it's often very time consuming to get started, if not utterly impossible for anyone not stuck reading tech blogs for 8 hours per day! But before you choose any technology, from hosting platform, and tech acquisition to in-house development and product deployment strategy, you need a canvas that will reflect the goal, the culture and the needs of your organization.
Everybody is talking about Agility as the best way to deliver software and I agree that there are very good principles in this movement that should be adopted by all organizations, but the capacity of a team to be Agile or the actual cost of Agility for your organization is mostly a function of your technology choices. You can't really dissociate your Agile development process from your system architecture. Some choices will give you more flexibility which will fuel your Agile process, reducing the cost of changing and adapting. This is a big principle for a startup. You should always assume that change is part of your life, not an exception to your normal activities. Changes must be embraced, with a product team identifying and prioritizing which one will be applied to your system. But embracing changes also means to be able to modify your system to absorb these changes with minimum resource consumption (time, money, skills, licenses, etc). In my experience, the flexibility of your architecture resulting from your technology choices, is the key enabler to Agility. With a ridig architecture, you can be Agile, but the cost of each change will be higher, even prohibitive sometimes.
Another key principles you need to take into account is that everything you build in-house is another rock you put in your organization's backpack. Be assured that this new rock will slow you down one day when you need to move fast! So as a pricinple, you need to minimize the number of technology components you are responsible for. The more you can delegate responsibility the better. Always assume that developing something in-house, even if it seems to be a time or budget saver when you take the decision, will cost you more down the road. The only exception to this rule is if you're talking about a core business component, something that differentiate your organization or a component where you can't find a decent solution out there. This last reason should be considered a technical debt and you should strive on replacing this in-house component with another solution as fast as you can.
Let me be clear, each and every component you develop in-house forces you to commit on designing, coding and debugging it but also on evolving it to your organization changing ecosystem, to support it, to document it, to keep available talent in-house to understand it and to operate it at the right level of availability and scalability.
If you're not a tech startup, you might be able to delegate 100% of your operation needs, but as soon as you use technology to differentiate yourself in your market, you need to assume that you will have to develop some software or hardware) in-house. In this context you will still need to apply the same principles of flexible architecture and least in-house development to these in-house components. It means choosing existing frameworks or libraries over building from scratch, so choosing a development platform with a rich ecosystem matching your industry needs. You might be tempted in using the latest bleeding-edge framework, but I would greatly advise against it. You will quickly realize that you will have to commit more resources (responsibility) to a bleeding-edge component/framework or library. You really need to properly assess your needs and make sure that the improved or innovative features provided by the bleeding-edge component are worth your extra committment. Most of the time, going with a platform that is popular in your industry or ecosystem will be beneficial as you'll have easier access to talent and consulting resources and these vendors will be better equipped to support you effectively.
To conclude this first post, let's say that you need to need to reduce your resource commitment toward technology to the minimum needed to support your system agility, which includes the flexibility of your architecture as well as the capacity of your process to adapt quickly and cheaply to changes, while keeping your technical debt to a minimum to avoid pushing expenses forward which will slow you down at the worst possible moment in your startup lifecycle.