Many teams fall into the trap of "technology stacking" at the beginning of the project: this uses serverless, which uses a hosted database, followed by a third-party certification, and then a hosted queue. Looks elegant and practically extremely scattered. The more services, the more complex the coupling, the longer the troubleshooting path, and the heavier the cognitive burden.
For small teams, it is more rational to centrally deploy, reduce dependencies, and converge the system on a small number of core components. For example, the backend uses Hono as a lightweight framework, runs unified in the Docker system, the database uses PostgreSQL, the reverse proxy uses Caddy, and the whole package is deployed to Hetzner's VPS. Data backups are placed on Cloudflare R2 at a controlled cost and with a clear structure.
The front-end can be deployed to Cloudflare Workers using TanStack Start, Edge Logic. In this way, the core computing is still concentrated on the controllable server, and the edge is only responsible for acceleration and lightweight processing. The entire architecture can basically cover more than a dozen dollars a month, which is enough to support most small and medium-sized businesses.
In contrast, the pure serverless solution, although it seems to be "zero operation and maintenance" in the early stage, the real situation is often the opposite. Environment variables are scattered across multiple platforms, permission systems are independent, and logs are distributed across different consoles. Each additional service adds a layer of complexity. When the project enters the medium term, the number of calls increases, traffic increases, and storage increases, and bills tend to expand rapidly.
More critical are the limitations. The serverless platform has boundaries in terms of execution time, resource constraints, cold start, connection management, etc., and often requires detours or the use of various "magic tricks" when encountering complex business. The technical debt was already buried when the architecture began to morph to accommodate the platform.
Of course, serverless is not completely worthless, it is suitable for extremely lightweight, event-driven, or highly volatile traffic scenarios. But for small teams pursuing stable cash flow and continuous iteration of functions, a controlled, centralized, and simple architecture tends to be more viable.
Technology is not a showcase, it's a service business. The more centralized the deployment, the fewer services used, the clearer the system, and the lower the maintenance costs. Projects that can really run for a long time are often not the most trendy ones, but the most restrained ones.