DEV Community

Aleix Morgadas
Aleix Morgadas

Posted on • Updated on

Which best practices can you afford in a Startup and which you cannot?

Even though what we understand as Best Practices might vary person to person, team to team and company to company depending on their context, I will assume some of them during this post to create the debate 😊


Anyone working in a tech startup, without a huge budget at least, is familiar with some of the next situations:

  • "We need this as soon as possible"
  • "There's no time for testing, we need to work on this other thing"
  • "Why dedicate two weeks to improve X, if we might need to close in next month?"
  • etc.

It's true that those situations might be seen as tension between "product management" and "engineering", as an example, where someone wins and another loses.

I like to see them in another way, we are all collaborating to deliver a product to the customers, but we need to make tradeoffs in the different delivery areas. There's no I win you lose. We all win or we all lose.

A Delivery area is engineering, UX, Product Design, Marketing, ..., anything needed to deliver the product.

That being said, everyone, in their own area of expertise, has an opinion about what's the best and what's not acceptable.

Between that spectrum, there are some best practices that we might consider required and others optional. But which ones are required that really help in the product success and which didn't really help that much compared to others?


From the engineering point of view, I consider the next Best Practices as required:

  • Test-Driven Development:

IMHO, the most important practice by far.

  • Continuous Delivery: A simple Continuous Delivery pipeline really helps in

    • Faster Feedback Loop, the tests break sooner
    • No human factor to deploy the solution to production
    • Team can see the results of their daily work in the development environment
    • Be confident in releasing to production soon and often, being able to push fixes faster and without human factor most of times

CD

It at least requires some sort of testing, without testing the feedback loop is longer than it should be.

  • Trunk Based Development

I consider that be working in one thing at a time, and always working in the trunk branch really helps in smaller iteration cycles.

  • Essential Monitoring

Have a way to see how your system is behaving in terms of how many 2XX, 4XX and 5XX responses codes there are per day/week helps you react faster in case you broke something, without needing to constantly check the application in case it broke something.


And you? Do you consider some other best practices to be more crucial? Which is your opinion about it?

I do agree that it does depend on each case, but I do think there are some that really are required 😁

Top comments (0)