The CI/CD Pipeline Audit I Wish Someone Made Me Do Sooner

MACROGEN — Mon, 21 Sep 2026 21:32:53 +0000

Most teams don't design their CI/CD pipeline once and leave it. It grows organically — a script here, a manual approval step there, a workaround for that one flaky test nobody's fixed — until eighteen months later you have a pipeline that technically works but that nobody fully understands anymore.

Here's a rough audit checklist that's caught real problems before they turned into outages.

Who can actually deploy, and how would you know?

Ask your team: if a deploy went out at 3 a.m. and broke something, could you tell who triggered it and why, without digging through Slack? If deploy permissions are scattered across five people's personal access tokens instead of a service account with proper audit logging, that's worth fixing before it's the reason an incident postmortem takes three days instead of three hours.

How long does a rollback actually take?

Not "how long should it take" — actually time it. Trigger a rollback in staging and watch the clock. Teams are often surprised to learn their "quick rollback" involves a manual database step nobody automated, or a cache that needs to be flushed by hand. If nobody's timed it recently, that number in your head is probably wrong.

Are your environments actually identical?

"Works in staging" followed by a production failure is almost always an environment drift problem — a different Node version, a missing environment variable, a dependency that got pinned in one place and not the other. Infrastructure-as-code helps, but only if staging and production are both built from the same definitions rather than staging being hand-configured once and forgotten.

What happens when a test suite gets slow?

There's a predictable lifecycle: tests get slow, someone adds a skip flag "temporarily," and six months later half the suite is skipped and nobody remembers why. A slow pipeline is a signal, not just an inconvenience — it usually means either the test suite needs pruning or the infrastructure running it needs a second look.

Is your monitoring watching the right things?

Uptime monitoring is table stakes. The gap that catches teams off guard is usually deployment-correlated monitoring — being able to see "error rates spiked 4 minutes after deploy X" without manually cross-referencing timestamps. If that correlation takes more than a glance, it's worth wiring up.

Worth doing before the pipeline tests you instead

None of these questions require exotic tooling to answer. Most of it is just sitting down and actually testing assumptions that have been sitting unchallenged for a while. Worth doing before the pipeline decides to test them for you.

Macro-Gen works through this kind of infrastructure and pipeline review with teams regularly — happy to compare notes if you're in the middle of one.

The MVP Features That Are Actually Just Multi-Tenancy in Disguise

MACROGEN — Mon, 21 Sep 2026 21:31:57 +0000

When people talk about "MVP scope," it's usually framed as a features conversation — what to cut, what to keep, what can wait until v2. But some of the decisions hiding inside that conversation aren't really about features at all. They're architecture decisions wearing a feature costume, and they're a lot more expensive to walk back than a UI tweak.

Here are a few that show up disguised as "small" scope questions.

"Can users belong to more than one workspace?"

This sounds like a small toggle. It's actually a foundational question about how you model the relationship between users and tenants. Bolt this on after launch and you're often looking at a schema migration touching every table that references a user, not just adding a join table. If there's any chance of this in year one, it's worth deciding the data model up front even if the UI for it ships later.

"Do we need custom roles per customer?"

Early on, "admin" and "member" covers almost everyone. Then one enterprise prospect asks for a "billing viewer who can't touch settings" and the two-role system doesn't bend easily. Permissions systems are one of those things that are far cheaper to build with some flexibility from the start (even if you expose only two roles at launch) than to retrofit once real customers depend on the existing behavior not changing.

"Should each customer get a subdomain?"

This one seems cosmetic — acme.yourapp.com feels like a branding nice-to-have. But once you commit to subdomain-based tenancy, it touches routing, SSL certificate provisioning, session handling, and sometimes your auth flow. Deciding this after a handful of customers are already live on a shared URL structure means a migration, not a config change.

"What happens when a customer wants to export everything and leave?"

Nobody wants to build this for an MVP, understandably. But designing your data model with clean tenant boundaries from day one makes an eventual export/delete flow straightforward. Design it without that boundary, and "delete this one customer's data" turns into a research project through years of accumulated joins and shared tables.

"Do we support one plan or several?"

A single flat price is the right call for validating an MVP. The trap is baking that assumption into billing logic in a way that assumes exactly one price forever — no fields for plan tier, no separation between "what a customer is billed" and "what a customer is entitled to." That separation costs almost nothing to add early and saves a rebuild later.

Not over-engineering — just noticing the disguise

None of this means over-engineering the MVP — the goal is still to ship something small and learn fast. It just means noticing which "small" decisions are actually architecture decisions before they get made by default.

Macro-Gen helps SaaS teams work through exactly this kind of scoping before the first migration gets written.

DEV Community: MACROGEN