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

Published: (May 2, 2026 at 06:54 PM EDT)
6 min read
Source: Dev.to

Source: Dev.to

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. It’s 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 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;
  sync(args: SyncArgs): Promise;
};
// lib/connectors/index.ts
const registry: Partial<ConnectorImpl> = {
  github,
  stripe,
  neon,
  cloudflare,
  koyeb,
};

export function getAllProviderMetadata(): ProviderMetadata[] {
  /* … */
}

The kpiCatalog is the bit that matters. Each connector declares which metrics it can fetch (github.stars, stripe.mrr, 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

type SyncResult = { kpis: Record<string, any>; warnings: string[] };

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 needs the Postgres adapter and bcrypt for credentials login, neither of which work in Edge.

Fix: split the config 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 foot‑gun is 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 page has its own nav).

Solution: 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 and route groups are invisible to the router. Each group gets its own chrome. The marketing pages never import auth code, so an unauthenticated visitor never hits a database query just to load the landing page.

I also updated 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 the environment.

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

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 Next.js server using the experimental instrumentation.ts hook. It schedules a setInterval‑style job that:

  1. Queries all projects with enabled KPIs.
  2. Calls each connector’s sync method.
  3. Persists the results (and any warnings) to Postgres.

Because the job lives in the same process, there’s no extra infrastructure to maintain. The only caveat is that the sync only runs when at least one instance of the app is alive – which is fine for a hobby‑level 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();
  }
}

Takeaways

DecisionWhy it mattered
Connector registryOne source of truth for both UI and sync logic; easy to add new providers.
Edge‑safe auth splitAllows middleware to run on the Edge while still using full‑stack auth features.
Route groupsClean separation of marketing vs. authenticated app UI without URL changes.
Encrypted credentialsKeeps API keys safe without the overhead of a full KMS solution.
In‑process cronNo extra worker services; sufficient for low‑frequency background jobs.

If you’re building a personal dashboard that talks to many third‑party APIs, these patterns keep the codebase manageable and the runtime costs low. Happy hacking!

What I’d want to add

I have five connectors today (GitHub, Stripe, Neon, Cloudflare, Koyeb). Next on the list:

  • Vercel
  • Plausible
  • Supabase
  • Resend
  • Netlify

If you’ve ever lost track of a side‑project subscription, what services would you most want a connector for? I’d rather hear suggestions than sign‑ups right now.

Live demo + free tier: StackMemo – drop a reaction on this article if you found it useful!

0 views
Back to Blog

Related posts

Read more »