I forgot a domain was auto-renewing. So I built a dashboard for my side projects.

I do a bunch of small things on the side. I wrote a website for a friend's thesis, took on a couple of commissioned full-stack jobs, and I have one actual side hustle that's trying to make money. None of them live on the same stack — I keep picking whichever provider has the most generous free tier for that specific thing.

The thesis site is on Firebase, the commissioned stuff is on another host, the side hustle is split across three providers. Different free plans, different dashboards, different emails. Last month I noticed a domain auto-renewing for a project I'd completely forgotten about. That was the moment I gave up trying to remember any of this in my head — or trying to keep it up in a Notion that I would never update.

So I built StackMemo. One board for every project, with connectors that hit the providers' APIs so the cost and KPI numbers update on their own.

This post is about a few of the design decisions that turned out to matter — written for anyone considering building something similar, or just curious how a small Next.js + Postgres app actually fits together when there are a lot of moving pieces.

The stack

• Next.js 16 (App Router) + TypeScript + Tailwind v4
• Postgres on Neon, raw pg (no ORM — I want to see the SQL)
• NextAuth v5 (credentials, GitHub, Google)
• Stripe billing for the paid tiers
• In-process cron via Next.js instrumentation.ts

1. The connector registry

Every provider — GitHub, Stripe, Neon, Cloudflare, Koyeb, Resend, Google Search Console today — implements the same interface and gets registered once. Adding a new provider is one new file plus one line in the registry.

// lib/connectors/types.ts
export type ConnectorImpl = {
  provider: ConnectorProvider;
  displayName: string;
  iconPath?: string;
  authType: "api_key" | "token" | "oauth";
  credentialsSchema: CredentialsSchema;
  setupGuide?: SetupGuide;
  kpiCatalog: KpiDefinition[];
  listResources(creds: ConnectorCredentials): Promise<ResourceOption[]>;
  sync(args: SyncArgs): Promise<SyncResult>;
};

// lib/connectors/index.ts
const registry: Partial<Record<ConnectorProvider, ConnectorImpl>> = {
  github,
  neon,
  cloudflare,
  koyeb,
  stripe,
  google_search_console: googleSearchConsole,
  resend,
  // "other" in the DB enum = the generic escape hatch (more on it below).
  other: customHttp,
};

The kpiCatalog is the bit that matters. Each connector declares which metrics it can fetch (github.stars, stripe.mrr, gsc.clicks, cloudflare.requests_24h...) and the user picks which ones they want active per project. Sync only fetches enabled KPIs, which keeps the API budget tight.

The interface intentionally returns SyncResult { kpis, warnings } instead of throwing on partial failure. Real-world APIs return 403 on plan-restricted endpoints all the time; treating that as a hard failure means a single locked-down KPI breaks the entire sync.

The marketing landing page reads from this same registry, so when I add a new connector, the chip shows up on the homepage marquee automatically — no second list to keep in sync.

2. Edge-safe auth split (Next.js 16 + NextAuth v5)

NextAuth v5 wants you to put your auth config in the Edge runtime so middleware can use it. But the full config wants the Postgres adapter and bcrypt for credentials login — neither of which work in Edge.

The fix is to split into two files:

// lib/auth.config.ts — Edge-safe (no pg, no bcrypt)
export default {
  providers: [GitHub({...}), Google({...})],
  pages: { signIn: "/login" },
  callbacks: { authorized: ({ auth }) => !!auth?.user },
} satisfies NextAuthConfig;

// lib/auth.ts — Node runtime (full version)
export const { handlers, auth, signIn, signOut } = NextAuth({
  ...authConfig,
  adapter: PostgresAdapter(pool),
  providers: [...authConfig.providers, Credentials({...})],
});

Middleware imports the Edge-safe config. Everything else imports the full one. This is the kind of footgun that's obvious in retrospect but eats half a day if you don't know about it.

3. Route groups for marketing vs app chrome

The first version had a single app/layout.tsx with the user header baked in. When I added the marketing landing page, that header showed up at the top of it — wrong vibe (the landing has its own nav). The fix was Next.js route groups:

app/
  layout.tsx              ← html/body/fonts only
  (marketing)/
    layout.tsx            ← marketing nav + footer
    page.tsx              ← /
    pricing/page.tsx      ← /pricing
  (app)/
    layout.tsx            ← app header with auth state
    dashboard/page.tsx    ← /dashboard
    projects/[id]/...

URLs are unchanged — route groups are invisible to the router. Each group gets its own chrome. The marketing pages don't import auth code at all, which means an unauthenticated visitor never hits a database query just to load the landing page.

I also had to update the middleware matcher so it only protects actual app routes — leaving /, /login, /signup, and the public share URLs (/p/[slug]) reachable without auth.

4. Encrypted credentials at rest

Connectors store API keys. Storing them in plaintext is a non-starter; KMS is overkill for a side project. I went with pgcrypto and a key in env:

// lib/crypto.ts
export function encryptCred(plaintext: string): Buffer {
  // pgp_sym_encrypt(plaintext, CONNECTOR_CRED_KEY)
}
export function decryptCred(ciphertext: Buffer): string { ... }

The key is intentionally separate from AUTH_SECRET — rotating one shouldn't invalidate the other. Generated once with openssl rand -base64 32.

5. In-process cron, no separate worker

The hourly KPI sync runs inside the same Node process as the web server. No separate worker, no managed cron service.

// instrumentation.ts (Next.js calls this once per worker on startup)
export async function register() {
  if (process.env.NEXT_RUNTIME === "nodejs") {
    const { startCron } = await import("@/lib/cron");
    startCron();
  }
}

Trade-off: scaling beyond one Node instance means the cron fires N times. For a side-project tracker that's a non-issue (the work is idempotent — overwriting a KPI value with the same number is a no-op). For something with heavier per-tick work I'd extract it.

6. The escape-hatch connector is an SSRF machine — treat it like one

Hand-coding a connector per provider doesn't scale to the long tail, so there's a generic HTTP connector: you give it a URL, an optional auth header, and a dot-path per KPI into the JSON response (data.subscribers.count), and the cron fetches it like any other connector.

Which means my server now makes requests to arbitrary user-supplied URLs on a schedule. That's a textbook SSRF vector — pointed at a cloud metadata endpoint or an internal service, it reads things no user should ever see. The safety layer is not optional:

• Resolve DNS first and reject private, loopback, and link-local ranges (10.x, 172.16–31.x, 192.168.x, 127.x, 169.254.x, ::1, fc00::/7)
• Follow at most a couple of redirects, and re-validate every hop against the same blocklist — the classic bypass is a public URL that 302s to an internal one
• http(s) only, ~5s timeout, ~1MB response cap
• Never surface raw response bodies in error messages

If you add a "just fetch this URL" feature to anything multi-tenant, budget as much time for this list as for the feature itself.

What I'd want to add

Eight connectors today, and the custom HTTP one covers anything with a JSON endpoint — but first-class connectors are nicer: proper KPI catalogs, setup guides, icons. Vercel, Plausible, Supabase, and Netlify are the current shortlist.

If you've ever lost track of a side-project subscription — what would you want a connector for first? I'd rather hear suggestions than signups right now.

You can poke at a live project without an account on the demo, browse other people's real stacks and costs on explore, or track your own — the free tier covers your first project.