Architecture advice ages badly, so let me be clear that this is what I would reach for today, for the kind of products I build, and not a law of nature. Your constraints might point somewhere else. That is fine.
Boring is a feature
The most underrated property of a stack is how few surprises it gives you at 2am. I would rather ship on tools that are slightly out of fashion and deeply understood than on the newest framework with three blog posts and a Discord. Postgres over the exotic database. A typed language over a clever one. Choose technology you can debug when it breaks, because it will break.
TypeScript end to end
Sharing types between the client and server removes a whole class of bugs that used to need tests. When the API contract is a type both sides import, a breaking change becomes a compile error instead of a 500 in production. That single property has saved me more time than any framework feature.
I lean on this everywhere, including the validation layer. Parse incoming data into typed shapes at the boundary and the rest of your code can trust it, which is also a quiet security win along the lines of my developer security checklist.
The edge is worth it, with limits
Running code close to users, on something like Cloudflare Workers, makes a real difference for latency, and the pricing model is hard to argue with. I host static sites and small APIs there happily. This very portfolio runs on that setup.
The catch is that the edge is not a normal server. No long-lived connections, tight CPU limits, a different runtime. It is excellent for request-response work and a bad fit for heavy background jobs. Know which half of your app belongs where, and do not try to force everything into one box.
Rendering: pick per page, not per app
The static-versus-dynamic debate is mostly a false choice. A marketing page should be static and cached at the edge. A dashboard should be dynamic and personalized. A blog can be static with the data pulled at build time, which is exactly how the posts you are reading get published. Modern frameworks let you mix these per route, so use that instead of picking one rendering strategy for the whole site.
Where AI fits in the stack
If your product has an AI feature, it is just another service in your architecture, with the same concerns as any external dependency: latency, cost, failure handling, and the fact that its output cannot be trusted blindly. I keep the model behind a clean internal API so I can swap providers, cache responses, and add guardrails in one place. The engineering details of that live in practical AI engineering, and if the feature involves autonomous agents, the safety constraints from agentic AI in cybersecurity apply directly.
What I would skip
Microservices for a team of three. You will spend more time on the network between services than on the product. Start with a well-organized monolith and split it only when a specific part actually needs to scale on its own.
And resist adopting a tool because a big company uses it. Their problems are not your problems. The right architecture for most projects is smaller and more boring than the conference talks suggest, and that is usually the point.