The journey of transitioning from a developer to a startup founder
By: Andrew Cachia
Tags: Scalability, Football, Startup, Tech, Developer Stories

The journey of transitioning from a developer to a startup founder Andrew Cachia Follow Jan 16 · 4 min read

Building a Scalable Product vs Building a Lean Startup

Moving from an employed developer to a startup owner involved one of the largest paradoxical mindshifts in my professional career.

The issue lies in the fact that the mindset of a startup founder versus that of a developer are in conflict with each other, like two heads constantly bashing against one another.

As a software developer, I know that building a robust foundation takes time. Scalability, modularity and good development practices are of the utmost importance to ensure long term robustness of the software.

However, as a startup founder, I want to get the product out to market as quickly as possible. This not only gives me an edge on the competition, but also allows me to test the market, get feedback on the product, pinpoint any issues, pivot if necessary, and ultimately recognize whether the market actually wants the product or not.

Developer mindset vs startup founder mindset

It’s a common and somewhat default reaction that once people get their “big idea”, they hide away keeping their product a well kept secret until the ‘big release day’ arrives. But remember, the last thing you want is to spend six months to one year building something…which never takes off!

So the question remains….where do you draw the line? How can you move quickly whilst not sacrificing quality? How do you ensure long term scalability whilst still keeping as lean as possible?

Whilst I can’t claim to have the perfect answer (is there even one, really?), I can suggest a number of tips that have helped guide me throughout this journey.

KISS (Keep It Simple Stupid)

You should be continuously asking yourself — “What is the absolute bare minimum functionality that the product requires?”.

Any ‘nice-to-have’ features should not be part of the first prototype or beta. The goal is for the customers to clearly understand what the product is trying to achieve or what problem it solves.

The same applies when designing the architecture. Having a blank slate when building @Leet, it was very tempting to begin designing a sophisticated microservice based architecture. Nowadays I thank myself for not following that approach for the maintenance nightmare that would have followed.

2. Do not re-invent the wheel

In my younger days, I used to be against paying for anything that I could build myself. Nowadays that I value time more than money, my view on that has flipped drastically.

If I could simply pay 10 euros a month to avoid a ton of effort and time on my behalf….yes please!

There are a huge number of services available in today’s market:

SaaS (Software-as-a-service): This could be an API up to a fully whitelabelled product. If a service already exists which solves most or part of what you are trying to achieve, and is within a reasonable budget, you should definitely consider.

IaaS (Infrastructure-as-a-service): Cloud service providers such as AWS and Azure all offer free tiers which help you get up and running very quickly without having to pay at the initial stages. Others like Digital Ocean offer free credit and are relatively cheap.

No code tools: As the NoCode movement is on the rise, more and more tools are being launched which require no coding and limited technical knowledge. Although these tools can be very efficient for rapidly launching a mockup or prototype, they tend to quickly fall apart once the number of users and website activity begins to increase. Adding specific customizations can also be tedious or impossible sometimes, depending on the scenario.

These tools should be used with caution and with understanding of the limitations.

3. Stick to what you know

Beware the learning curve! It’s tempting to want to explore the latest and greatest new programming language or database service. However, no matter how easy the online tutorials seem, it WILL take time to familiarize yourself with all the nooks and crannies. You will also be presented with challenges that will set you back quite a bit, which you know you could have easily solved with the tools you already know.

So UNLESS there is a clear and strong reason for you to favour a particular technology over another, please do yourself a favor and stick to the tools you’re experienced with.

4. Some shortcuts are acceptable/required to be taken. Others are not.

It’s up to you to use your better judgment here. Avoiding layers and layers of mappings, interfaces and abstractions in the initial version of the product is acceptable. Writing a bunch of spaghetti code for the sake of ‘speed’ is not.

5. If the product is “perfect” at launch, then you’ve taken too long!

You need to get used to getting comfortable with things not being perfect. It doesn’t matter if the product is not polished and still lacks a few features. As long as it solves the customer’s problems or adds value to their lives, it will be well received.

6. Remember, the technical challenges are the least challenging part of building a tech startup…

…so make sure you know what you’re getting yourself into 😉