There’s no glamour in working in early-stage startups. Low budgets, uncertain environments, and fast product iterations are completely normal on a daily basis. However, there are a lot of amazing (and complex) challenges to face, especially when the company starts a hypergrowth strategy.

On the engineering side, those challenges could be even more complex: teams must scale fast, hiring new engineers/managers is a tough task, and systems architecture must evolve and adapt to the new reality.

After working for Yellow — the largest micro-mobility company in LatAm with bikes, scooters and electric bikes — since day one, I’ve reflected on our actions in those situations and what I would or wouldn’t repeat in the future.

Giving some context: we started the company with five engineers who had already worked together at other companies. Then we scaled-up teams to 20 engineers, went through a merger with Grin — a Mexican company with a completely different culture — and reached 10MM rides on our platform in less than one year.

It’s worth mentioning that everything I’m pointing out here is based on this experience. The idea is to give some input to help others with technical decisions on early-stage startups.

Don’t start with hype technologies

Also known as “don’t use some technology just because other company did.”

I think this might be a cliché, but some early-stage startup engineers I’ve been talking to try to replicate some successful recipes from huge companies like Nubank or Netflix. However, although they have a lot of valuable things that we should learn, other companies have a completely different reality.

Early-stage startups must focus on product improvements, and technical decisions must support those changes rapidly. Therefore, you should manage to have a few technical debts by creating simple implementations.

Don’t be seduced by hype technologies at the beginning, be focused on launching your product most safely.

People come first. Always.

As one of the company’s first engineers, you might think that your teammates are as motivated as you. You might think they are aligned with the strategy and have a sense of urgency about how fast the company should move.

If you think like that, maybe you’re wrong.

Don’t assume everyone is on the same page. Some ceremonies, like one-on-one meetings and a weekly meeting with the whole company, are good to get an alignment and even better to know each other. Remember: providing context is crucial.

Communication is one of the most severe problems in software engineering, and we sometimes neglect that, especially in early-stage startups. That happens due to the focus on product launches and numbers the company wants to achieve.

Try to create an open environment where everyone feels comfortable sharing feedback or giving suggestions. It can be vital for the company, especially regarding culture building and engineers retention.

The data team must work very closely with the engineering

During the development process, many changes are deployed to production frequently. Those changes can affect the data structure of the applications and can lead to huge problems if the communication doesn’t work across the teams.

Misalignment between engineering and data teams means the company’s data is unreliable. As simple as that. And it gets worse: all teams can take wrong decisions because of that. “Been there, done that”.

Everyone must have a high-level understanding of how the systems produce the data and measure the indicators. Hence, I suggest including the data team in the engineering & product decisions. And vice-versa.

That’s the best way to turn your data into meaningful, valuable, and successful business decisions.

If you can use third-party services, use them

One of the most valuable resources in an early-stage startup is time, and you don’t have it. More than that, you don’t have enough people working to create and maintain every infrastructure piece.

With third-party services, you can save a huge amount of work and benefit from focusing only on your core rules. In addition, most of them have special offers for startups so that you can use them for free.

Some useful services for most startups: NewRelic, AWS & Metabase.

Deployments must be easy from day zero

Things change so fast in early-stage startups. Code is not different. We can move quickly and change many things with a good deployment process.

At Yellow, we’ve achieved that by using third-party services — in this case, CodeBuild and CodePipeline on AWS — and brought us a secure way to test new features and fix bugs rapidly. Also, the cost-benefit ratio for development is pretty good, in our case, just one day.

Deployment reliability will help you a lot in the short term.

Finally, you need to enjoy the ride. Nothing makes sense if you don’t. There’s a lot of work to do, but seeing your product used by early customers is priceless.