DEV Community: MACROGEN

Multi-Tenant SaaS with Postgres Row-Level Security: A Practical Guide

MACROGEN — Sun, 11 Oct 2026 21:49:39 +0000

Almost every SaaS product has to answer one early question: how do we keep one customer's data away from another's? Get it wrong and you have a data leak. Get it overcomplicated and you slow down every feature.

This post covers the common options and walks through one of the most practical: a shared schema protected by Postgres row-level security (RLS).

The three common tenancy models

Model	Isolation	Cost and ops	Good for
Shared schema (`tenant_id` column)	Logical	Cheapest, simplest to run	Many small tenants
Schema per tenant	Stronger	Migrations multiply	Tens to hundreds of tenants
Database per tenant	Strongest	Most expensive	Compliance-heavy or large customers

Most early-stage products start with the shared schema. The risk is simple: one forgotten WHERE tenant_id = ? leaks data. RLS moves that rule from application code into the database, so it can't be forgotten.

Step 1: Add a tenant column

CREATE TABLE invoices (
  id         uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id  uuid NOT NULL,
  amount     numeric(12,2) NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX invoices_tenant_idx ON invoices (tenant_id);

Index tenant_id on every tenant-scoped table. Nearly every query will filter on it.

Step 2: Enable row-level security

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.current_tenant', true)::uuid)
  WITH CHECK (tenant_id = current_setting('app.current_tenant', true)::uuid);

A few details matter here:

USING controls which rows you can read, update or delete.
WITH CHECK controls which rows you can insert or update into.
Table owners bypass RLS unless you use FORCE ROW LEVEL SECURITY.
Superusers and roles with BYPASSRLS always bypass it, so your application should connect as a normal, limited role.
If the setting is missing, current_setting(..., true) returns NULL, the comparison is false, and no rows are returned. That is a safe default.

Step 3: Set the tenant for each request

Set the tenant inside a transaction, using set_config with true so it only lasts for that transaction. This also matters if you use a connection pool, because a setting that leaks to the next request would be dangerous.

// db.js
import pg from "pg";
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });

export async function withTenant(tenantId, fn) {
  const client = await pool.connect();
  try {
    await client.query("BEGIN");
    await client.query("SELECT set_config('app.current_tenant', $1, true)", [tenantId]);
    const result = await fn(client);
    await client.query("COMMIT");
    return result;
  } catch (err) {
    await client.query("ROLLBACK");
    throw err;
  } finally {
    client.release();
  }
}

And a route that uses it:

app.get("/invoices", async (req, res) => {
  const rows = await withTenant(req.user.tenantId, async (db) => {
    const { rows } = await db.query("SELECT id, amount, created_at FROM invoices ORDER BY created_at DESC");
    return rows;
  });
  res.json(rows);
});

Notice there is no WHERE tenant_id in that query. The database applies it.

Step 4: Test the isolation

Write a test that proves tenant A cannot see tenant B's rows. This is the most valuable test in a multi-tenant app.

test("tenants cannot read each other's invoices", async () => {
  await withTenant(tenantA, (db) =>
    db.query("INSERT INTO invoices (tenant_id, amount) VALUES ($1, 100)", [tenantA]));

  const rows = await withTenant(tenantB, async (db) =>
    (await db.query("SELECT * FROM invoices")).rows);

  expect(rows).toHaveLength(0);
});

Common pitfalls

Connecting as a superuser or table owner silently disables RLS. Check your app's role.
Forgetting to enable RLS on new tables. Add a check to CI that lists tables with a tenant_id column but no policy.
Session-level settings with pooling. Always use transaction-scoped settings.
Background jobs and admin tools. They need an explicit, audited way to set the tenant (or a separate role).
Unique constraints. Usually they should include tenant_id, for example UNIQUE (tenant_id, email).

When RLS isn't enough

RLS gives strong logical isolation, but it doesn't solve noisy neighbours (one tenant using all the resources), per-tenant backups or restores, or data-residency requirements. If a customer needs those, schema-per-tenant or database-per-tenant may fit better for them, and many products end up with a hybrid.

What tenancy model are you using, and what made you pick it?

Further reading: SaaS Development

Native vs Cross-Platform in 2026: Questions to Ask Before You Choose

MACROGEN — Wed, 30 Sep 2026 19:12:48 +0000

"Should we go native or cross-platform?" comes up at the start of almost every mobile project. The honest answer is that it depends, but it depends on specific, answerable questions. Here are the ones that actually decide it.

1. How much of the app is platform-specific?

If the app leans heavily on the camera, Bluetooth, background processing, AR, widgets or the newest OS features on release day, native (Swift / Kotlin) avoids a layer of bridging and plugin maintenance.

If the app is mostly forms, lists, dashboards and API calls, which describes most business apps, cross-platform handles it comfortably.

2. What does your team already know?

A strong JavaScript/TypeScript and React team will be productive in React Native quickly, and can often share logic with a web app.
Flutter uses Dart, which is easy to pick up, and gives very consistent UI across platforms because it draws its own widgets.
Separate iOS and Android specialists make native realistic.

The best framework is often the one your team can maintain for years, not the one that wins benchmarks.

3. How important is identical UI on both platforms?

Flutter renders the same pixels everywhere, which is great for strongly branded designs. React Native and native apps use platform components, which feel more "at home" on each OS but differ slightly between them. Decide which your users and designers actually want.

4. What's the performance profile?

For typical business apps, modern cross-platform frameworks are more than fast enough. Performance becomes a deciding factor mainly for:

Heavy graphics, games or real-time video
Complex animations on low-end devices
Intensive on-device processing

Even then, both Flutter and React Native let you drop down to native code for the hot paths.

5. What's the long-term cost?

Two native codebases mean roughly two sets of features, bugs and releases. Cross-platform usually reduces that, but you take on dependency risk: plugin quality, framework upgrades and lag behind new OS features.

Ask: Who maintains this in three years, and how?

A quick decision guide

Situation	Leaning
Business app, small team, tight budget	Cross-platform
React/web team, shared logic with web	React Native
Highly branded, pixel-consistent UI	Flutter
Deep hardware or OS integration	Native
Graphics-heavy or performance-critical	Native (or cross-platform plus native modules)

Final thought

There's no universally right answer, only a right answer for your project, team and budget. Write down your answers to the five questions above before anyone mentions a framework name, and the choice usually becomes obvious.

Which way did you go on your last project, and would you choose the same again? Let me know in the comments.

I work at MACROGEN, where we build native and cross-platform apps. You can see our mobile app projects here.

This article was created with the help of AI and reviewed for accuracy by the author.

Building Offline-First Mobile Apps: A Practical Guide to Sync Queues

MACROGEN — Tue, 29 Sep 2026 20:31:54 +0000

Users don't care whether they're on a train, in a lift or in a building with terrible signal. They expect your app to work. Offline-first design treats the network as optional: the app reads and writes locally, then syncs when it can.

Here's a pattern that works well in practice.

1. The local database is the source of truth for the UI

The UI never waits on the network. It reads from and writes to a local database (SQLite, Realm, WatermelonDB, Drift and so on). Network responses update the local database, and the UI reacts to those changes.

This alone makes an app feel dramatically faster, even online.

2. Queue every change in an "outbox"

When the user makes a change, write it locally and add an entry to an outbox table in the same transaction:

type OutboxItem = {
  id: string;           // unique ID, generated on the device
  entity: "task";
  action: "create" | "update" | "delete";
  payload: unknown;
  createdAt: number;
  attempts: number;
};

A background sync worker then processes the outbox in order:

async function flushOutbox() {
  const items = await db.outbox.orderBy("createdAt").toArray();
  for (const item of items) {
    try {
      await api.send(item, { idempotencyKey: item.id });
      await db.outbox.delete(item.id);
    } catch (err) {
      await db.outbox.update(item.id, { attempts: item.attempts + 1 });
      break; // keep ordering; retry later with backoff
    }
  }
}

Trigger it when connectivity returns, when the app comes to the foreground, and on a timer.

3. Make requests idempotent

Mobile networks fail in awkward ways. A request can succeed on the server while the response never reaches the phone, so the app retries. Without protection, that creates duplicates.

Send the outbox item's ID as an idempotency key. The server stores keys it has already processed and returns the original result for repeats instead of applying the change twice.

4. Decide on a conflict strategy up front

If two devices edit the same record offline, something has to give. Common options:

Last write wins. Simple, but can silently discard edits.
Field-level merge. Only fields that were actually changed get overwritten. This suits forms and profiles well.
Ask the user. Best for high-value data like documents or orders.

Whatever you choose, store an updatedAt or version number on each record so conflicts can be detected rather than guessed.

5. Show sync status honestly

A small "Saved on device, syncing…" indicator builds far more trust than pretending everything reached the server. Surface failed syncs clearly so users aren't surprised later.

Quick checklist

[ ] UI reads only from the local database
[ ] Writes and outbox entries happen in one transaction
[ ] Retries use exponential backoff
[ ] Every request carries an idempotency key
[ ] Conflict strategy is documented and tested
[ ] Sync status is visible to the user

Offline-first takes more thought up front, but it pays off in reliability and user trust. Have you built offline sync before? What caught you out?

I work at MACROGEN, where we build iOS and Android apps. Some of our mobile work is here.

This article was created with the help of AI and reviewed for accuracy by the author.

Multi-Tenancy in SaaS: Choosing Between Shared Tables, Schemas and Separate Databases

MACROGEN — Tue, 29 Sep 2026 01:15:45 +0000

One of the first big decisions when building a SaaS product is how to keep each customer's data separate. Get it wrong and you either leak data between tenants or end up with an architecture that can't scale. Here are the three common approaches and when each one makes sense.

1. Shared database, shared tables

Every table has a tenant_id column, and every query filters on it.

Pros

Cheapest to run and simplest to deploy
One migration updates every tenant
Easy cross-tenant reporting for your own analytics

Cons

One forgotten WHERE tenant_id = ... and you have a data leak
A single noisy tenant can slow everyone down
Harder to offer per-customer backups or data residency

2. Shared database, schema per tenant

Each tenant gets its own schema (tenant_acme.invoices, tenant_globex.invoices), and you switch the search_path per request.

Pros

Stronger logical separation
Per-tenant restores are easier

Cons

Migrations must run once per schema, which gets slow with thousands of tenants
Connection pooling becomes trickier

3. Database per tenant

Each tenant gets a completely separate database.

Pros

Strongest isolation, and a natural fit for enterprise customers and data residency requirements
Noisy neighbours are no longer a problem

Cons

Highest cost and operational overhead
Fleet-wide migrations and monitoring need proper tooling

Making option 1 safer with Row-Level Security

Most early-stage products start with shared tables. You can remove the "forgotten WHERE clause" risk by letting PostgreSQL enforce isolation with Row-Level Security (RLS):

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

Then, at the start of each request's transaction, set the tenant:

BEGIN;
SET LOCAL app.current_tenant = '6f1c2a9e-...';
SELECT * FROM invoices;  -- only this tenant's rows come back
COMMIT;

A few things to watch out for:

Table owners bypass RLS unless you use FORCE ROW LEVEL SECURITY, and superusers always bypass it. Your app should connect as a separate, non-owner role.
Use SET LOCAL inside a transaction so the setting can't leak to the next request on a pooled connection.
Index tenant_id (usually as the first column in composite indexes), or performance will suffer as you grow.

Which should you pick?

A sensible default for most new SaaS products:

Start with shared tables plus RLS. It's cheap, simple and safe enough.
Design your code so the tenant context is resolved in one place (middleware, not scattered queries). That makes moving to another model later much less painful.
Offer database-per-tenant as an enterprise tier if customers ask for dedicated infrastructure.

How are you handling multi-tenancy in your projects? I'd love to hear what's worked, or not, in the comments.

I work at MACROGEN, where we build SaaS platforms. You can see some of our SaaS work here.

This article was created with the help of AI and reviewed for accuracy by the author.

A Practical Full-Stack Architecture for Production Apps (React, Next.js, Node.js & Express)

MACROGEN — Fri, 25 Sep 2026 07:54:18 +0000

A Practical Full-Stack Architecture for Production Apps (React, Next.js, Node.js & Express)

Every "how to build a full-stack app" tutorial online teaches you how to build a to-do list. Almost none of them teach you what to do when that to-do list turns into a real product with real users, real auth, real edge cases, and a client asking "can we add X" every second sprint.

This is the architecture pattern we default to when building production web apps with React, Next.js, Node.js, and Express — not because it's the only way to do it, but because it scales cleanly from a 2-week MVP to a platform handling real traffic, without a rewrite in between.

The Core Decision: Where Does Next.js End and Express Begin?

This is the question that trips up most teams early on. Next.js ships with API routes out of the box, so it's tempting to build your entire backend inside pages/api (or app/api if you're on the App Router) and call it done.

For small apps, that's fine. For anything with real business logic — background jobs, webhooks, complex auth, integrations with third-party services — we split it:

/apps
  /web        → Next.js (frontend + BFF layer)
  /api        → Express (core backend, business logic, DB access)
/packages
  /shared     → shared types, validation schemas, constants

Why split it at all?

Next.js's API routes run in a serverless-friendly environment, which isn't always ideal for long-running jobs, websockets, or heavy background processing.
A dedicated Express API can be deployed independently, scaled independently, and reused by other clients later — a mobile app, a partner integration, whatever comes next.
It keeps your frontend team's mental model simple: Next.js handles UI, routing, and light data-fetching glue. Express owns the actual business logic and data layer.

If you're building something genuinely small and won't need to reuse the backend elsewhere, keeping everything inside Next.js is a completely valid call. Just know it's a decision, not a default.

Folder Structure That Doesn't Fall Apart at Scale

A structure like this tends to hold up well as the codebase grows:

/apps/api/src
  /modules
    /users
      users.controller.ts
      users.service.ts
      users.routes.ts
      users.schema.ts
    /billing
      billing.controller.ts
      billing.service.ts
      billing.routes.ts
  /middleware
    auth.middleware.ts
    error.middleware.ts
  /lib
    db.ts
    logger.ts
  app.ts
  server.ts

The key idea: organize by feature/domain, not by technical layer. A "controllers/", "services/", "routes/" split at the top level looks tidy in a demo repo, but it means every new feature touches three unrelated folders. Six months in, nobody can find anything. Grouping by module keeps related code physically close together.

A Minimal but Realistic Express Setup

// app.ts
import express from "express";
import { errorMiddleware } from "./middleware/error.middleware";
import { authMiddleware } from "./middleware/auth.middleware";
import { userRoutes } from "./modules/users/users.routes";

const app = express();

app.use(express.json());
app.use("/api/users", authMiddleware, userRoutes);

app.use(errorMiddleware); // always last

export default app;

A few things worth calling out:

Error middleware goes last, always. New devs on the team forget this constantly, and it silently breaks error handling across the whole app.
Auth is middleware, not a helper function sprinkled into every controller. It should be impossible to accidentally forget to protect a route.
Validation happens at the edge, before anything touches your service layer. We use zod for this — schemas double as TypeScript types, so your validation and your types never drift apart:

// users.schema.ts
import { z } from "zod";

export const createUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1),
});

export type CreateUserInput = z.infer<typeof createUserSchema>;

The Frontend Side: Next.js as More Than Just Pages

On the Next.js side, the biggest architectural decision is how you fetch and cache data. With the App Router, Server Components let you fetch data directly on the server without shipping a client-side fetch waterfall — which matters more than people expect for perceived performance.

A pattern that works well:

// app/dashboard/page.tsx
import { getUserData } from "@/lib/api";

export default async function DashboardPage() {
  const user = await getUserData(); // runs on the server
  return <DashboardClient initialUser={user} />;
}

// components/DashboardClient.tsx
"use client";
import { useState } from "react";

export default function DashboardClient({ initialUser }) {
  const [user, setUser] = useState(initialUser);
  // interactive UI logic here
}

Server Components handle the initial data fetch with zero client-side loading spinner. Client Components take over for anything interactive. Mixing these deliberately — rather than marking everything "use client" out of habit — is one of the easiest performance wins available in a modern Next.js app.

Auth: The One Place Not to Get Creative

Roll your own auth once, learn why you shouldn't, and after that most teams land on one of two approaches:

A managed auth provider (Auth0, Clerk, Supabase Auth) — faster to ship, less to maintain, worth it for most products.
JWT-based auth with refresh tokens, issued by your Express API, verified via middleware on protected routes.

If you go the JWT route, the pattern that avoids the most footguns is: short-lived access tokens (15 minutes or so) stored in memory on the client, and a long-lived refresh token stored in an httpOnly cookie. It's slightly more setup than storing a token in localStorage, but it closes off an entire category of XSS-related token theft.

Deployment: Keep the Two Halves Independently Deployable

Because the frontend and backend are separate apps, they can (and should) deploy independently:

Next.js app → Vercel, or a container on AWS/Fly.io if you need more control over server-side behavior.
Express API → containerized with Docker, deployed to AWS ECS, Fly.io, or Railway, sitting behind a load balancer.
Shared package → published internally or symlinked via a monorepo tool (Turborepo, Nx) so both apps stay in sync on types and validation without copy-pasting code between repos.

This also means your API can scale independently from your frontend — useful the moment you have a traffic spike on one side but not the other, which happens more often than people expect (a marketing campaign spikes frontend traffic; a batch job spikes backend load — rarely both at once).

The Actual Lesson Here

None of this is exotic. There's no framework magic, no clever trick. The architecture that survives contact with a real product is almost always the boring one: clear boundaries between frontend and backend, code organized by feature instead of by layer, validation that can't be skipped, and auth that nobody "gets creative" with.

Most of the pain in full-stack projects doesn't come from picking the wrong framework — it comes from structure that made sense on day one and stopped making sense on day ninety. Deciding on these boundaries early, even for something that starts small, saves a rewrite later.

I'm part of the team at Macro Gen, a Christchurch-based dev studio building full-stack web apps, SaaS platforms, and cloud infrastructure with this same stack. If you're working through a similar architecture decision or want a second opinion on your setup, happy to chat — drop a comment or find us on Facebook.

Multi-Tenancy in SaaS: The Architecture Decision You Can't Undo Later

MACROGEN — Fri, 25 Sep 2026 07:52:14 +0000

Multi-Tenancy in SaaS: The Architecture Decision You Can't Undo Later

Most early architecture decisions in a SaaS product are reversible. Wrong framework? Migrate it. Wrong hosting provider? Move it. Wrong multi-tenancy model? That one's expensive to fix once you have real customers and real data sitting in production.

If you're building a SaaS platform and haven't explicitly decided how tenant data is isolated, you've actually already made the decision by default — usually the one that's easiest to type, not the one that scales best. Here's a practical breakdown of the three real options, when each one makes sense, and what we typically default to when architecting SaaS platforms on PostgreSQL, MongoDB, and AWS.

The Three Real Options

1. Shared Database, Shared Schema (Row-Level Isolation)

Every tenant's data lives in the same tables, distinguished by a tenant_id column.

CREATE TABLE invoices (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  amount NUMERIC NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_invoices_tenant ON invoices(tenant_id);

Pros: Cheapest to run, simplest migrations (one schema to update, ever), easiest to query across tenants for internal analytics.

Cons: One bad query without a WHERE tenant_id = ? clause and you've got a serious data leak. This is the model where a single missing filter is a headline-worthy incident, not a minor bug.

The fix most teams reach for is enforcing isolation at the database level instead of trusting every developer to remember the filter every time — Postgres Row-Level Security does exactly that:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

Set app.current_tenant at the start of every request (from the authenticated session), and Postgres enforces isolation even if a developer forgets the WHERE clause. This single feature is, in our experience, the difference between "safe shared-schema multi-tenancy" and "multi-tenancy that's one code review miss away from a very bad day."

2. Shared Database, Schema-per-Tenant

Each tenant gets their own Postgres schema within the same database:

CREATE SCHEMA tenant_acme;
CREATE SCHEMA tenant_globex;

Pros: Stronger isolation than row-level, still relatively cheap to run since it's one physical database. Backups and per-tenant data export are cleaner.

Cons: Migrations become a loop instead of a single command — you're now running your migration script against every tenant schema, which gets slow and error-prone past a few hundred tenants. Connection pooling also gets trickier since schema-switching happens per request.

This tends to be the right call for B2B SaaS with a moderate number of larger customers (tens to low hundreds), especially where customers explicitly ask about data isolation for compliance reasons — schema-per-tenant is much easier to explain in a security questionnaire than "we use a WHERE clause."

3. Database-per-Tenant

Each tenant gets a fully separate database, sometimes even a separate instance.

Pros: The strongest isolation available short of separate infrastructure entirely. Easiest model to reason about for compliance-heavy industries (health, finance, government contracts) and the only option in this list where "delete this tenant's data completely" is a single DROP DATABASE rather than a targeted deletion job you have to trust.

Cons: Expensive, and operationally heavier — connection management, monitoring, and backups all multiply per tenant. Cross-tenant analytics (e.g. "average usage across all customers") requires a separate data pipeline rather than a simple query.

This is usually reserved for enterprise tiers — a single "Enterprise" plan tenant gets database-per-tenant while your standard tiers stay on shared-schema, giving you the best of both without paying enterprise infrastructure costs for every free-tier signup.

Where MongoDB Fits

For SaaS products with more flexible, document-shaped data (activity feeds, configuration objects, event logs), we often pair Postgres for core transactional data (billing, users, tenants) with MongoDB for high-volume, schema-flexible data. Tenant isolation in Mongo typically follows the same three patterns — a tenantId field with proper indexing for the shared-collection model, or separate collections/databases per tenant for stronger isolation:

db.events.createIndex({ tenantId: 1, createdAt: -1 });

db.events.find({ tenantId: currentTenant, createdAt: { $gte: startOfMonth } });

The same rule applies here as in Postgres: never trust application code alone to filter by tenant on every query. Build the check as close to the data layer as possible — a repository/query-builder layer that automatically injects the tenant filter is far safer than hoping every engineer remembers it in every service file.

File Storage: Isolating Tenants in S3

This one gets overlooked constantly. If tenants upload files — documents, images, exports — namespace every object by tenant from day one:

s3://your-app-uploads/{tenant_id}/{resource_type}/{file_id}.pdf

Combine this with per-tenant scoped IAM policies or presigned URLs generated server-side (never client-side) so a tenant can only ever generate a signed URL for objects under their own prefix. Retrofitting this after tenants already have thousands of files under a flat structure is a genuinely painful migration — worth getting right before your first real customer uploads anything.

So Which One Should You Actually Pick?

If you're building an MVP and don't yet know your customer profile: start with shared schema + Row-Level Security. It's the cheapest to run, fast to build, and RLS closes off the scariest failure mode. You can migrate specific large or compliance-sensitive tenants to their own schema or database later — this is a much easier migration to do selectively than to do a full switch of your isolation model after the fact.

If you already know you're selling to enterprise or regulated industries from day one, it's worth designing for schema-per-tenant or database-per-tenant from the start, even though it's more setup — retrofitting isolation once you have production data and paying customers is a significantly bigger project than building it in from the beginning.

The Real Takeaway

Multi-tenancy isn't a checkbox — it's a decision that touches your database schema, your query layer, your file storage, your backup strategy, and eventually your compliance story. The teams that get burned are almost always the ones that let the isolation model happen implicitly (usually shared-schema with no RLS and a prayer that nobody forgets a WHERE clause) instead of choosing it deliberately.

Pick the model that matches who you're selling to today, build in the database-level safety net regardless of which model you choose, and revisit the decision explicitly once your customer base or compliance requirements change — not after an incident forces the conversation.

I work on SaaS architecture at Macro Gen, a Christchurch-based dev studio building SaaS platforms end-to-end on Postgres, MongoDB, and AWS. If you're mid-decision on your own multi-tenancy model, happy to compare notes — drop a comment or find us on Facebook.

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.