DEV Community

Mythex
Mythex

Posted on Fully Autonomous

Why a new hire's first week falls apart, and the small onboarding app that fixes it

At a 20 to 150 person company, onboarding usually works like this. Someone in HR or ops has a checklist in a Google Doc. A week before the start date they send a few emails: IT for a laptop, the manager for a first-week plan, payroll for the paperwork. Then the new person shows up on Monday and at least one of those things didn't happen.

The laptop is there but has no accounts. The manager is at an offsite. The I-9 is half done. The new hire spends the first morning reading the employee handbook PDF and wondering if they made a mistake.

None of this is because people don't care. It's because onboarding is a process with five or six owners, and the checklist only lives in one person's head and one person's doc. This article explains where it breaks, what a small onboarding app needs to fix it (much less than an HR suite), and how to build one in an afternoon with an AI app builder, including the actual prompts.

Where onboarding actually breaks

If you look at the last five hires and ask "what went wrong in week one?", the answers fall into a few buckets.

Tasks with no owner and no date. "Set up Slack" is on the checklist, but nobody is assigned and nobody knows it has to happen before Monday. Everyone assumes someone else did it.

Tasks that depend on other tasks. IT can't create accounts until HR confirms the legal name and start date. The manager can't book the welcome lunch until the start date is final. When the first task slips, everything after it slips silently.

No single view of "who starts when." With two or three hires a month, HR knows the dates. With eight a month across three teams, nobody can see at a glance who is starting next week and what's still open for each of them.

The new hire is left out of their own onboarding. They get a stream of emails from different people with different links: sign this, read that, upload your ID. They can't see what's done and what's left.

Nothing is learned from the last hire. Every onboarding is rebuilt from the doc. Nobody tracks that the laptop is late every time, or that new salespeople always wait three days for CRM access.

A shared spreadsheet helps a little. An onboarding app with owners, due dates relative to the start date, and a view per role fixes most of it.

What a small onboarding app needs (and what it doesn't)

You don't need a full HRIS to fix week one. You need five things.

  1. A template of tasks per role. "Every hire" tasks (paperwork, accounts, handbook), plus extra tasks for "sales" or "engineering" or "warehouse." Each task has an owner role (HR, IT, manager, payroll, new hire) and a due date expressed relative to the start date, like "5 days before" or "day 1."
  2. A new-hire record. Name, role, team, manager, start date, work location. Creating it copies the template tasks and calculates the real dates.
  3. A view per owner. IT sees only IT tasks across all upcoming hires, sorted by due date. Managers see only their own hires. HR sees everything.
  4. A new-hire page. The person starting sees their own checklist: what to sign, what to read, who their buddy is, and where to be on Monday.
  5. A "what's late" list and a weekly summary. Overdue tasks, grouped by owner, so the Monday HR check-in takes two minutes.

What you can leave out at first: performance reviews, payroll, benefits enrollment, e-signature workflows. Your payroll provider (Gusto, Rippling, ADP, Justworks) already handles the legal forms. Link to it from the checklist instead of rebuilding it.

Building it, step by step

Here's how this looks in Mythex, an AI app builder where you describe the app in plain language and it writes the code, gives it a Postgres database, and publishes it. The same plan works with any builder or with a developer; the prompts below just make the steps concrete.

Step 1: describe the data and the roles

Start with one prompt that sets up the structure. Being specific about owners and relative dates saves a lot of back-and-forth later.

Build an employee onboarding app for a 60-person company. Data: onboarding templates (name, e.g. "Every hire", "Sales", "Engineering"), template tasks (title, description, owner role: HR / IT / Manager / Payroll / New hire, due offset in days relative to start date, link), new hires (name, personal email, role, team, manager, start date, location), and onboarding tasks copied from the templates when a new hire is created, with a real due date, status (to do / done / blocked), owner, and a note. Roles for staff: Admin (HR), IT, Manager, Payroll. HR can see and edit everything.

The first version usually gives you the tables, a list of new hires, and a form to add one. Check that creating a new hire really copies the tasks and calculates dates. Ask for a fix if it doesn't:

When I add a new hire with template "Every hire" + "Sales", copy every task from both templates and set the due date to start date plus the offset. Show the count of tasks created.

Step 2: give each owner their own view

Add a "My tasks" page. IT users see only tasks with owner IT for hires starting in the next 30 days, sorted by due date, with overdue ones in red at the top. Managers see only tasks for their own direct reports. Each task has a one-click "Done" and a "Blocked" button that asks for a reason.

This is the screen that changes behaviour. IT doesn't need to read the onboarding doc any more; they open one page on Monday and work down the list.

Step 3: the new-hire page

Add a page for the new hire that shows only their own tasks with owner "New hire", plus a welcome block: start time, address, who to ask for, their manager and buddy, and a short first-week schedule. It should work well on a phone.

A practical question here is how the new hire gets in before they have a company account. Two common options: send them a private link that only shows their own checklist, or create their company email a week early and let them sign in with it. Decide which before you build, and tell the builder which one you want. Mythex doesn't come with a ready-made login product: the agent builds sign-in into your app using your database or a provider you choose, so say exactly how you want people to get in.

Step 4: the late list and the weekly summary

Add an HR dashboard: hires starting in the next 14 days, each with a progress bar, and a list of overdue tasks grouped by owner. Add an "Export summary" button that produces a short text I can paste into Slack every Monday.

If you want this sent automatically, ask for an email or Slack message every Monday at 9am. That needs an email provider or a Slack webhook, which you'll connect once.

Step 5: improve the template from real data

After two or three hires, look at which tasks were late or blocked most often. Then move them earlier in the template. "Order laptop" at minus 5 days was late three times? Make it minus 10. This is the part spreadsheets never do, because nobody looks back at old tabs.

Add a report: for each template task, how often it was completed late in the last 90 days, and the average days late.

What the team gets

When the app is published, it has its own URL (or your domain, like onboarding.yourcompany.com), its data lives in a real Postgres database instead of a doc, and you can keep changing it by describing what you want.

For HR and ops teams the bigger point is ownership. The app reflects how your company onboards people, with your roles and your order of steps, instead of the generic flow of a large HR suite.

Honest limits

  • It's not your HRIS or payroll. I-9, W-4, state forms, benefits enrollment and direct deposit belong in your payroll provider. Link to them from the checklist; don't rebuild them.
  • Account creation isn't automatic. The app tells IT what to create and when. Actually creating Google Workspace or Microsoft 365 accounts from the app needs their admin APIs and careful permissions. Possible later, not in the first afternoon.
  • Personal data needs care. Keep only what onboarding needs. Don't store Social Security numbers or ID scans in a side app if your payroll provider already holds them.
  • Someone has to own the template. Budget 30 minutes a month to update tasks when tools or policies change.
  • If you already pay for Rippling, BambooHR or Workday, check their onboarding modules first. A custom app makes sense when you don't have one, or when your process (shift workers, multiple locations, client-site starts) doesn't fit theirs.

For teams

On the Free plan you can build and try the whole thing. For one person building, Pro is $25/month. If several people in HR and ops will build and edit apps, the Business plan (from $50/month) adds a shared team workspace, roles, members-only apps that only signed-in colleagues can open, and Google Workspace SSO, so the IT and manager views stay inside the company. There's a page on HR and people-ops tools with more examples, and current prices are on the pricing page.

Whatever you use, start with the last hire who had a bad first week. Write down what went wrong, turn each item into a task with an owner and a date, and you have the first version of your template before you build anything.

Top comments (0)