A large company can afford a platform team to absorb the operational cost of an ambitious stack. A small independent team cannot — every extra service, framework, or piece of infrastructure is something the same one or two people have to understand, secure, monitor, and eventually replace. That constraint should drive stack decisions more than what's popular or technically interesting.
Questions worth asking before adopting anything
- Who maintains this if it breaks at 2am? If the honest answer is "whoever is available," prefer boring, well-documented tools with a large community over cutting-edge ones with a small one.
- What does this replace, and is that replacement worth the migration cost? Swapping a working tool for a marginally better one has a real cost in time and risk that needs to be weighed against the actual benefit.
- Does this need to run somewhere we operate, or can it be a managed service? For a small team, offloading operational burden to a managed service (hosting, authentication, database) is usually the correct trade of money for time.
- What's the actual failure mode? Understand what happens to users if this specific piece of the stack goes down, and whether that failure mode is acceptable.
A bias toward fewer moving parts
It's tempting to add a framework, a state management library, or a custom build pipeline because a tutorial or a larger company uses it. For a small team, the more relevant question is whether the current, simpler approach is actually failing — not whether a more complex approach exists. Static hosting instead of a server where a server isn't needed, a managed authentication service instead of building one, and a single, well-tested build tool instead of a custom pipeline are all examples of trading theoretical flexibility for lower day-to-day maintenance.
Where it's worth spending complexity budget
Not every corner should be cut. Security-relevant configuration — Content-Security-Policy headers, authentication flows, handling of user data — deserves real attention even in a minimal stack, because the cost of getting it wrong is much higher than the cost of a slightly more complex configuration. The goal isn't to minimize complexity everywhere; it's to spend the team's limited attention on the parts that matter and avoid it everywhere else.
Revisiting the decision
A stack decision made for a two-page site is not necessarily still correct once that site has twenty pages and a growing set of interactive features. It's reasonable to revisit tooling choices periodically rather than assume the original decision is permanent, as long as each change is justified by an actual, current limitation rather than novelty for its own sake.