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 https://cleanbee.syzygy-ai.com/ 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.
Our Simple Roadmap
Nowadays, the choice of frameworks is really wide, but again, due to some experience with Flutter, we decided to give it a go. Within mobile development, one of the important aspects to better decide on is state management.
Collect Doc
We collect require documents send for check
Check & Finalize
We check the document and send for final approval
Approve
After approve you’ll ready to use your software
“We are witnessing an amalgamation of technologies that is poised to redefine our world. I am truly exhilarated by the trajectory that IT solutions are taking as we peer into the future.”
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.
