NEXT.JS PLATFORMS AND PORTALS
Logged-in software, not a brochure with a password.
A portal is a different animal from a website. The moment there is a login there is session handling, role checks, data that one user may see and another may not, and a database that has to still be correct after a migration. I build these in Next.js with the App Router, server components for anything that touches data, and route handlers for the API.
The infrastructure is mine to run and I run it by hand. GCP or Jarvislabs VM provisioning and sizing, Docker, nginx as reverse proxy, DNS, Let's Encrypt renewal, secrets in env files that never enter a repo, nightly database dumps, a subdomain per service. I have done a live VM migration with the app up, and moved a production app from SQLite to Postgres without losing a row.
The limit is honest and worth knowing before you hire me: single VM, single tenant, deploys run manually because I would rather watch a release than trust an automated one I am not there to catch. That is fine for an internal tool with fifty users or a client portal with a few hundred. If you need multi-region failover and a platform rota on call, hire a platform vendor.
WHAT I DO
- Auth and roles — login, session handling and per-role guards enforced on the server, not UI that merely hides the button
- Data model — Postgres schema, indexes, constraints and migrations; SQLite only where a single writer is genuinely enough
- Route handlers as the API, with input validated at the boundary and typed responses the front end can trust
- The admin surface your team actually works in: create, edit, approve and audit the records the public side reads
- Server provisioning and operation — VM sizing, Docker, nginx, DNS, SSL, secrets, nightly dumps, and one restore rehearsed before launch
- Load notes — what breaks first, at roughly what concurrency, and the written procedure for bringing it back
- Handover document per environment: hostnames, ports, env keys, deploy commands, restore steps
HOW I WORK
- 01
MODEL
Entities, permissions and the queries each screen needs get settled on paper first, because a wrong schema is the one mistake that is expensive to undo later.
- 02
PROVISION
VM sized, Docker and nginx configured, DNS and SSL issued, database created with dumps scheduled — before a single feature is built on top of it.
- 03
BUILD
Auth first, then the admin surface, then the user-facing screens, so every feature is tested against real permissions from day one.
- 04
OPERATE
Deploy by hand, watch the logs, verify the restore path, then hand over the runbook that lets somebody else do all three.
BEST FOR
- Internal tools replacing the spreadsheet three people keep overwriting
- Client-facing portals where each client logs in and sees only their own records
- A marketing site that outgrew its CMS and now needs real data and permissions behind it
- Up to a few hundred users, where single-tenant is a feature rather than a constraint
NOT THIS
- No container orchestration platform and no declarative infra tooling. The stack is Docker plus nginx on one box, and a deploy is a command I run on purpose — there is no automated promotion step between environments.
- Not a mobile app. Portals here are responsive web; a native iOS or Android client is somebody else's job.
- Not the brochure site. With no login and no writes to a database, the marketing sites and landing pages page is faster and cheaper.
THE PROOF
Published case studies from digital experience work. Each one names the client and shows what was delivered.
STRAIGHT ANSWERS
REST OF DIGITAL EXPERIENCE
MAKE A
WISH.
Tell me what you're building. I'll tell you how loud it can get.
- /01
YOU WRITE
Tell me what you're building and what's in the way. Two lines is enough.
- /02
WE TALK
A 30-minute call, booked within 7 days. Real questions, no pitch theatre.
- /03
YOU GET A PLAN
Scope, timeline and an honest number, usually within a week.