Just a note that "bootstrapper VCs" are coming up that fund ideas whose revenue will eventually be in the <100 million dollar range, usually 10 or 20 million. Such examples include TinySeed, Earnest Capital, Indie.vc, Lighter Capital, and others.
So this question might have some interesting answers if we take this knowledge into consideration as well, as some of the ideas here could potentially be funded by these VCs even if not by traditional ones.
> There were a lot of sad panda hats when you guys started to transition away.
For us as well. It was so nice to have things work one day and the next and the next, although I guess they wouldn't have worked today.
Favorite firefighting moment was when wdc lost half the fiber in ~ 2014, and we had to move all of our traffic out, so that there was capacity. Our guy asked why we had to move? and your guy said something like 'Because if you guys move, we only need one customer to move.' :D
Having TL'ed both Frontend and Backend at Google, I don't think it's front first or back first. It's "contract first", and here is why:
- Assuming PRD and UX are ready. The Frontend team take a look and come up with the Frontend data model they want. The focus is on making sure it's easiest for them to maintain and develop the client side.
- The Backend team take a look and come up with the Storage data model that is flexible enough for short term future. The Backend should anticipate the growth of the product and try not to be put in a situation where they have to redesign the database/infrastructure.
- Then both teams meet to negotiate the "Contract", which is the API layer. In some case, the API is more similar to the Frontend data model. In some case, the API is more similar to the Storage data model. In other case, there is a translation layer between Storage <-> API <-> Frontend (not as desirable, but not the end of the world). There are standard on how API should be designed (https://aip.dev/).
- When the contract is established, both teams can run more independently to each other, release at different times, and only needs to sync when there is a need for the contract to change. The API is designed to be easily extended, but not changed or deleted. The Backend team doesn't care if the Frontend data model exists. The Frontend team doesn't care what kind of Storage the Backend uses. It's an abstraction.
The complexity of the project can't be entirely eliminated. A good TL makes explainable trade offs on which parts of the system bear the complexity. It's their job to think not only about the architecture, but also how the development can be sustained in the future. This is especially true when the product is developed by a medium-large team. The focus is no longer on having the leanest/optimal code base. The focus is on making sure many parts of the system can move more independently, in parallel, and that it's scale-able to the growing business needs. It's a classic case of Amdahl's Law applicable to real life.
Of course, this is not always applicable to small projects that is never intended to have more than a couple engineers. Even then, when I work on solo full stack projects, I still unconsciously do this contract first approach.
So this question might have some interesting answers if we take this knowledge into consideration as well, as some of the ideas here could potentially be funded by these VCs even if not by traditional ones.