Evaluate a SaaS Architecture Like a Staff Engineer

FAQ

How do you evaluate a SaaS architecture like a staff engineer?

A staff engineer doesn't evaluate whether a SaaS codebase works today, they evaluate what it costs to change tomorrow: a pricing rewrite, a payment provider swap, a team that triples, a framework they cannot trust. Run five checks. Where billing logic lives and how many files a pricing change touches. Whether RBAC is a first-class layer or a flag scattered through components. Whether any external dependency can be swapped without touching product code. Whether the test suite catches a regression before a customer does. Whether the technology has been supported for a while, and how trusted it is by the community.

Where should billing logic live in a SaaS codebase?

In one catalog the rest of the product reads from. Products, prices, entitlements, trial flags. Checkout, invoices, emails, and the billing UI shouldn't keep their own copy of the amount. A useful test: pick a real pricing change (annual vs monthly, or grandfather $29 while new signups pay $39) and count the files you would open. Small number means the catalog is doing its job. Large number means the amount has leaked.

How do you know if RBAC is a first-class layer?

There is a closed set of scopes, roles map to those scopes, the API refuses the mutation before the resolver does work, and the UI hides the control using the same scope. isAdmin in a sidebar is not a layer. If a new hire can ship a permissions hole by copying a flag from the nearest component, it is scattered. Read a settings page and the matching mutation side by side. If only one of them actually checks, you found it.

What does it mean to swap an external dependency without touching product code?

Product code talks to a contract (sendEmail, createSubscription). Vendor SDKs live behind that contract, not in resolvers and not in invoice helpers. Swapping still means writing an adapter, that part is real work. It shouldn't mean rewriting invoice preview or every call site that imported the vendor's types. If you can't find the boundary, you can't estimate the swap, you can only estimate a rewrite.

How do you know if the test suite will catch a regression before a customer does?

Ask whether the change from the other checks would go red in CI. A new price that leaves an old amount on a receipt. A missing scope on a mutation. Suites that only replay the old happy path, or seed $29 and snapshot $29, stay green while production is wrong. Flaky tests you skip don't count.

Why pick Frameworks like Express or Passport over newer frameworks?

Because you have to live with the choice. Express has been the Node HTTP default for a long time, so the bugs are known bugs and the next hire has already used it, and Passport is not pretty, but the strategies are documented, the failure modes are old, and people still answer questions about it. Next.js on Vercel can feel like the default in 2026 and still leave you debugging cache that works on your laptop and evaporates on a serverless instance. New is not the same as trusted, trusted means the community still shows up, and a security questionnaire does not become a history lesson.