Useful Links

The Programming Architecture of a Modern Startup

The Tech side of startups can sometimes be very fluid and contain a lot of unknowns. What tech stack to use? Which components might be overkill for now but worth keeping an eye on in the future? How to balance the pace of business features development while keeping the quality bar high enough to have a maintainable codebase?

Here I want to share our experience building latest new website from the ground up — how we shaped our processes based on needs and how our processes evolved as we extended our tech stack with new components.

Start Shaping the Process

What we have at the start:

  • Less than a dozen developers — in-house team and temporary contractors who want to and can work asynchronously
  • Completely greenfield project — no single line of code has been written yet. Requirements are vague, but they already started shaping into something
  • Tech-wise — the clear need for a backend that should talk with mobile clients
  • Some simple web frontend — static pages should be enough! (nope)

We have started simple — code at GitHub and a PR-based flow with a single requirement — to have tickets split table to be delivered in 1–3 days. This required some practice of story slicing, and it seems that a sense of visible fast progress is shown through the ability to move tickets to Done. This can be a great motivational factor for the team to onboard that idea.

How did we get into Terraform?

The backend, a part of the DB, also should have some object/file storage. Sooner or later, we also should have DNS so that our services are ready to play with the big cruel world.

The choice of cloud provider was purely based on existing expertise within the team. We already use AWS for other projects, so we decided to stick with it. For sure, it is possible to do everything in the AWS console, but as times go, things become a classic big ball of mud that everyone is terrified to touch, and no one remembers why this bit exists at all.

The choice of cloud provider was purely based on existing expertise within the team. We already use AWS for other projects, so we decided to stick with it. For sure, it is possible to do everything in the AWS console, but as times go, things become a classic big ball of mud that everyone is terrified to touch, and no one remembers why this bit exists at all.

More than 3000+ companies trusted us and collaborated with us

© 2024 – All rights reserved