AI Onboarding Assistant

Status

In development — final pre-launch verification

Platform

Web (Next.js/Supabase)

Type

Production-Grade

Focus

AI-generated onboarding plans, dual-surface product (manager + new hire)

One of the biggest pain points for any new hire is figuring out how to actually feel productive, caught-up, and ready to contribute — often well past the official onboarding period. Even with a checklist to follow, new hires frequently don't know what's really expected of them, what's considered best practice on the team, or who to even ask.

It starts with what the manager already has — a job description and a short guided questionnaire — and turns that into a real onboarding plan: phased goals, concrete tasks, and clear completion criteria, generated for the specific role instead of pulled from a generic template. The new hire opens a workspace built around a single daily focus instead of a wall of tasks, and when something isn't clear, an AI chat answers using their actual plan, their actual role, and their actual questions — not boilerplate advice. On the other side, the manager gets a dashboard that shows real progress: which phase a new hire is in, what's been completed, where they might be falling behind — without turning into a tool for watching someone's every move.

• Decision 1

  Two structurally separate surfaces, not one app with roles.

  Manager and new-hire experiences are enforced as distinct at the middleware, API, and database layers — not just hidden by conditional UI. Manager visibility is deliberately limited to task completion and phase progress; something like a new hire's last login is never queried, by design.

• Decision 2

  The AI chat is grounded, not generic.

  Every response is assembled server-side from the new hire's actual setup answers, phase goals, tasks, and job description. Responses route through four tiers, and every message logs which tier fired — without logging the content itself. Product visibility and user trust, balanced deliberately rather than defaulted.

• Decision 3

  I didn't call it "live" until I proved it.

  The first deploy looked successful, so I went back and checked anyway. Turned out several environment variables were never actually set, a mock flag had quietly stayed on in production the whole time — meaning the real API had never once been called — the database was still pointing at localhost, and the auto-deploy pipeline was broken. None of that showed up until I actually looked. The real decision wasn't fixing those things. It was refusing to trust "looks deployed" and checking the data layer myself before I'd call it done.

22 of 23 planned build phases are complete — accounts, AI-generated onboarding plans, manager approval, the new-hire workspace, phase progress, plan adjustments, alerts, a daily digest, and payments. I'm in the final stretch now: double-checking everything actually works the way it's supposed to before calling it launched.

That final check already paid off — it caught real issues that a quick glance would have missed, including a deploy that looked fine but wasn't fully live. Each one got tracked down and fixed before anything shipped.