As a four-time founder, and three-time CTO, Zuber has experience guiding software startups through critical hypergrowth phases. Here are the 14 software building rules that he believes are key for successful technical leadership.


Find product-market fit.

Every choice you make must be in the service of getting the product in the hands of users as fast as possible.


Ensure technical decisions are in service of business decisions.

The definition of an engineer’s best work is the work that is best for the business.


Don’t do stealth mode.

Don’t build in secret, build in public. Don’t take your time making it perfect, build something imperfect and get feedback on it as quickly as possible.


Build a minimum viable product.

Your only strategy is to be wrong as fast as humanly possible so that you can find out what right is and start building it.


Defer decisions as long as possible. 

Plan your next step, build it, and get feedback. Then amend the plan. Repeat.


Let time do the work.

Usually we don’t even know that we’re making a monumental design decision at the time we make it because the alternate path hasn’t shown up yet. At the same time, correct solutions have a habit of revealing themselves if you can find a way to wait long enough.


Beware the esoteric tech stack.

There is no tech stack that will give you a leg up because it's new and different from what everybody else is using. If you are trying to build a cost-effective delivery business, then teaching new hires obscure programming languages, or managing the operational overhead that accompanies shiny new technologies is not where you want to be.


Product-market fit will paper over bad technical decisions.

Pragmatism always wins the day – build things that are simple, build things that are boring, and build things that are battle-tested.


Depend on uncertainty.

At any point, something crucial about your business could change. Build in a way that minimises the cost of being wrong and then watch change closely.


Write erasable code.

There is often a very this-or-that perspective in engineering: you either have a monolith or you have microservices. You have really well-crafted, abstracted, encapsulated code or you have spaghetti. But the truth is you're going to end up somewhere in the middle.

Getting comfortable with that is one of the levers you can use to drive your team to focus on things that matter and solve the most critical problems at any given time.


Invest in domain-driven design early.

If you’re going to make investments (and you are), it’s worth considering the cost of change upfront. If you happen to be integrating with other platforms, something that many businesses being built these days do, knowing what you own and making sure that you have control over it is very simple to do early and very expensive to add later.


Focus on CI/CD early.

The ability to move quickly and adapt to change is going to be tied very tightly to your ability to deliver. Setting up continuous integration/ continuous delivery (CI/CD) pipelines for your software is perhaps the most impactful decision you can make early on that will make your life and your team’s life much easier as you hit your stride and start to scale.


Buy, don’t build.

If you find that you are reinventing something that’s already been invented, know that your competition is not. They are focusing on the business you're trying to win. If it’s not a competitive differentiator or delivering new, unique value to users, do not build it.


Fight complexity.

Always keep driving toward product-market fit and focus on the decisions that will enable you to pivot as quickly, as often, and as cost-effectively as necessary. If you maintain focus on your highest leverage decisions as a technical leader, you will be in the privileged position of having the time and money to later untangle your speedy but strategic early decisions.

Cover image courtesy of Morning Brew on Unsplash

Back to top

Share this article