I forgot a domain was auto-renewing. So I built a dashboard for my side projects.
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:
- Queries all projects with enabled KPIs.
- Calls each connector’s
syncmethod. - 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
| Decision | Why it mattered |
|---|---|
| Connector registry | One source of truth for both UI and sync logic; easy to add new providers. |
| Edge‑safe auth split | Allows middleware to run on the Edge while still using full‑stack auth features. |
| Route groups | Clean separation of marketing vs. authenticated app UI without URL changes. |
| Encrypted credentials | Keeps API keys safe without the overhead of a full KMS solution. |
| In‑process cron | No 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!