Balancing Technical Challenges in a Startup

I’m not going to delve into the deluge of business decisions needed in a startup, we know that startups usually have to push for the MVP (Minimum Viable Product) that they can get out into the world whether it’s to customers or to investors to pull in enough cash to propel them to the next MVP. Ultimately they then iterate until the product itself brings in enough money to sustain itself.

What concerns me more the technical decisions & processes to get the MVP ready and out the door faster and more reliably.

Developer Experience

This might seem like an odd section to start out with, but I think it’s one of the most important.

You need to ensure that developing is smooth and simple, if it’s not then process and procedures get bypassed, corners are cut, and ultimately the product and morale suffers.

This won’t just affect your seasoned developers, but also any new starters who join the team in a world of chaos. Documentation rarely suffices here, with a small team moving so quickly it will often drift, but that doesn’t mean you shouldn’t try!

Here’s my top priorities when it comes to developer experience:

CI Pipelines must be reliable

A flaky pipeline is worse than no pipeline, any failures will be ignored once the team decides it’s flaky, even if they’re true failures. We know the story of the boy who cried wolf.

This applies to test pipelines as well as deployment pipelines.

Running projects locally must be simple

It should be easy to get a project running locally, all the existing developers should be doing it, so at the very least their approach should be automated in the repository to save them time. It will also speed up debugging if you know all of your developers are running things in the same way. If there’s an automated deployment (there should be!) then ideally it’ll be run the same way locally.

This will help foster a cross-functional & cross-repository/project team!

Technical Debt at the framework level must be dealt with quickly

This is technical debt that anyone who is running the project takes on, not just in a certain component in the codebase. If you can’t manage your dependencies, or you’re having to work around bugs in an old version of a framework then the whole team will suffer.

Automation

Unsurprisingly this is key. There will be many processes that will be a burden on a small team, and as you scale up the team the automation goes from being a useful tool to being used as documentation and onboarding assistance. New starters can browse the automated processes and learn about how applications run & how they are deployed. Existing team members have fewer new responsibilities as the automation takes care of processes that new team members wouldn’t know about.

We also shouldn’t forget that in any team it’s important that knowledge is shared, inevitably it won’t be until a team member is on leave, or no longer with the company when you realise that they’re the only one that knows how to carry out some process. In a small team this is even more likely, making automation so much more important.

Sharing Weaknesses

There will be things that you can’t automate yet, it might just be due to lack of time. Whatever the reason, the important thing is that there’s a place to share the blindspots and a place to air any concerns around existing processes.

This is vital not only to planning, but also for new team members to be aware of any potential pitfalls.

Infrastructure as Code

Depending on your developers this might drive them up the wall at first, but they’ll quickly realise the benefits when their service reliably deploys and they can easily make changes to how it is run.

Some developers will hardly need to touch it, and they’ll be grateful that they don’t even need to go near the dashboard of your Cloud Provider.

And while we’re here…

Splitting Cloud Infrastructure Accounts

By that I mean separate Cloud Provider accounts for different environments. At the very least you should have an account for your demo or production environment (depending on the stage of your startup), and an account for a development environment. Personally I wouldn’t be too comfortable without an environment mirroring production, but I digress…

Splitting these is good practice and also ticks a lot of the boxes from the Automation section. It’ll particularly help with ensuring your environments are reproducible and captured using Infrastructure as Code, with the development account being the only place where manual infrastructure changes should be permitted for testing purposes.

Monolith or Microservice

An age old debate that people write entire books on. Without context there’s no right answer…

Serverless?

Serverless can take away a lot of the pain of deployment, I’m a big fan of not having to worry about scaling, but I could write a whole blog on Serverless, and I probably will.

A quick breakdown though…

Positives

• No more worrying about scaling
• Fewer monitoring concerns (frequently restarted)
• Often a good solution to quickly deploy a whole new service that would’ve taken a team months otherwise

Negatives

• Debugging is a nightmare
• Logging can be even worse
• Libraries often break
• Libraries assume other libraries can handle serverless deployments
• Interacting with non-serverless services can cause concerns
• Cold starts can be very cold
• Non-portable

Build your own vs Off-the-shelf

This one is included in textbooks from the 90s and earlier. Pay for the tools your employees ask for, it’s cheaper than their time. Usually the point at which it starts getting expensive is when you should be making money anyway, at which point you can decide whether to pay more or to build your own.

Wrapping Up

I’ve barely touched the surface here, I’ve just gone into some things that have been important in startups I’ve worked in as well as startups I’ve heard about. I’d be interested in any opposing opinions, fresh ideas and ways to improve. Feel free to reach out to me on LinkedIn to discuss!

---

Cover photo by Slidebean on Unsplash