The 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 <a href="https://cleanbee.syzygy-ai.com/" rel="noopener ugc nofollow" target="_blank">https://cleanbee.syzygy-ai.com/</a> 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. Businesses want to conquer the market and engineers — try cool stuff and stretch their brains. Meanwhile, the industry produces new languages, frameworks, and libraries in such quantities that you will not be able to check them all. And, usually, if you scratch the shiny surface of the Next Big Thing, you will find a good old concept. Good, if you are lucky. One of the most exciting topics to argue about is the processes — whether you rely on <a href="https://trunkbaseddevelopment.com/" rel="noopener ugc nofollow" target="_blank">trunk-based development</a>, prefer a more monstrous <a href="https://www.endoflineblog.com/gitflow-considered-harmful" rel="noopener ugc nofollow" target="_blank">GitHub flow</a>, are a fan of <a href="https://www.agilealliance.org/glossary/mob-programming/" rel="noopener ugc nofollow" target="_blank">mobbing</a>, or find it more efficient to spend time in <a href="https://trunkbaseddevelopment.com/short-lived-feature-branches/" rel="noopener ugc nofollow" target="_blank">PR-based</a> code reviews. I have experience working in an environment where artifacts were thrown away on users without any standardized process. In case of issues, developers had a lot of fun (nope!) trying to figure out what version of components was actually deployed. On another spectrum is the never-ending queue to CI. After you create PR you have to entertain yourself in the nearest 30 minutes by betting whether the CI cluster will find a resource to run tests over your changes. Sometimes the platform team introduces new, exciting, and useful features that might break compatibility with existing boilerplate for CI. These may result in failing all your checks at the last minute, after an hour of waiting. I strongly believe that, as usual, it all depends on team maturity, the kind of software you are building, and various business constraints, for example, the existence of <a href="https://about.gitlab.com/handbook/engineering/error-budgets/" rel="noopener ugc nofollow" target="_blank">error’s budget</a> and the importance of <a href="https://enkonix.com/blog/time-to-market/" rel="noopener ugc nofollow" target="_blank">time-to-market</a> versus <a href="https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-sli-vs-slo-vs-sla" rel="noopener ugc nofollow" target="_blank">SLXs</a>. I think what is important is to have some agreed processes in place that everyone is aware of and follows. It’s also important to have the bravery to challenge and change it if there is evidence of a better alternative. <a href="https://betterprogramming.pub/architecture-of-modern-startup-abaec235c2eb">Visit Now</a>