Onboard — One Intake. Every Request. Ready for Day One.
Inspiration
Starting a new job should be exciting, not exhausting.
Imagine walking into your first day, receiving your laptop, and being ready to contribute—only to discover you can't log in. You contact IT, get it fixed, and then discover you can't access the application you need. Another request, another delay, another person to follow up with.
Meanwhile, your manager is coordinating requests across different systems, and IT support is responding to issues as they appear.
This was the problem that inspired Onboard.
During our experience with the Ontario Public Service (OPS), we explored the challenges of employee onboarding and internal transfers. What stood out was how fragmented the process could become: employee information entered repeatedly, service requests managed separately, knowledge passed between people, and limited visibility into whether someone was actually prepared to begin their work.
For ThunderHacks II's Main Track, we revisited this experience through the lens of Version 1.0 versus Version 2.0.
Our Version 1.0 was a fragmented, difficult-to-track, reactive onboarding process.
Our Version 2.0 became Onboard—a centralized, transparent, and proactive approach to employee transitions.
Our goal was simple: make it easier for managers to prepare new employees for their first day, while reducing unnecessary delays, repetitive work, and last-minute surprises.
What It Does
Onboard is a web-based employee onboarding and internal-transfer coordination platform designed primarily for managers and team leads.
Instead of manually preparing several disconnected requests, managers enter employee information once. Onboard uses that information to prepare relevant service-request drafts, organize transition requirements, and provide visibility into outstanding work.
One Intake, Multiple Requests
A manager creates a New Hire or Internal Transfer case with information such as the employee's role, department, start date, and requirements.
Onboard generates editable request drafts that the manager can review, modify, and selectively include before bulk submission.
In our current MVP, bulk submission is simulated and persisted internally. Integration with enterprise platforms such as ONRequest or ServiceNow is planned for a future deployment.
Day-One Preflight
One of our most important features is Day-One Preflight.
A completed IT request doesn't necessarily mean an employee can perform their first assigned task.
For example, an account might have been provisioned, but the employee's ability to sign in has not yet been verified.
Onboard connects first-day work tasks with their required prerequisites, including account access, equipment, application permissions, important contacts, and knowledge.
Managers can identify unknown or blocked requirements, record verification evidence received from employees or service owners, and monitor readiness as those requirements are resolved.
Readiness is calculated through server-side rules, rather than simply treating closed tickets as proof that an employee is ready.
Knowledge Handoffs
Onboard also includes a Starter Brief feature that helps structure handoff notes into more useful information for incoming employees.
Our MVP uses a rule-based organizer, with curated fictional examples demonstrating the richer handoff experience we envision.
Future AI-assisted generation could provide more context-aware synthesis through an organization-approved enterprise AI service or privately hosted model, with appropriate data-protection controls.
Supporting Internal Transfers
Onboard isn't limited to new hires.
When an employee transfers between departments or ministries, the system can prepare transition-specific requests and highlight previous access that may need to be reviewed or removed.
This helps coordinate both sides of a transfer: gaining what the employee needs for the new role and reviewing permissions associated with the previous one.
How We Built It
We developed Onboard as a full-stack web application using:
- React, TypeScript, Vite, and Tailwind CSS for the frontend.
- Node.js and Vercel Functions for the backend API.
- Neon PostgreSQL for persistent transition cases, tickets, prerequisites, and audit events.
- Zod for server-side request validation.
- Database transactions and server-enforced workflow rules to keep case changes consistent.
- Signed demo sessions to protect prototype operations.
We designed the application around a connected workflow:
Employee Intake → Ticket Preparation → Manager Review → Simulated Submission → Day-One Preflight → Readiness Verification
Rather than building a frontend that only looks functional, we implemented persistent case records, editable ticket drafts, ticket lifecycle transitions, evidence-backed prerequisite verification, and audit history.
We also created two fictional demonstration scenarios: Maryam Arif, a new hire facing unverified application access, and Jim Halpert, an internal transfer requiring new-role setup and previous-access review.
Both scenarios can be used to create editable, persistent cases that follow the same backend workflow as manually entered employees.
Challenges We Faced
Turning a Prototype into a Working Application
One of our biggest challenges was moving beyond a frontend demonstration into a real database-backed application.
Early versions could display generated requests, but some interactions weren't correctly connected to persistent records. This meant that certain buttons appeared disabled, and local-only generated tickets couldn't support the full submission and readiness workflow.
We traced these problems through frontend state management, backend configuration, and session handling, then removed misleading local-only success paths.
The result was a more reliable system where meaningful workflow actions depend on validated, persistent data.
Building Reliable Database Workflows
We initially explored Supabase for persistence before migrating to Neon PostgreSQL.
This required adjusting the database access layer, migrations, environment configuration, and integration tests.
We also encountered and corrected a database date-conversion issue during live verification.
Making Readiness Meaningful
We initially approached onboarding completion through traditional request statuses.
But we realized that a fulfilled request and a verified first-day capability are not the same thing.
This led us to develop task-level prerequisites, verification evidence, accountable owners, and server-calculated readiness.
An important design decision was ensuring that closing a ticket does not automatically verify an employee's ability to perform a task.
Keeping the Prototype Honest
We also had to establish clear boundaries between what we could demonstrate during a hackathon and what would require enterprise access.
We don't have authorized access to a live ONRequest environment, production employee identities, or an approved AI provider for confidential handoff information.
Instead of pretending those integrations were operational, we built functioning internal workflows and clearly labelled simulated capabilities.
What We Learned
This project taught us that automation is only useful when it improves the actual experience of the people involved.
We learned to think beyond individual features and consider the entire employee transition: the manager preparing requests, IT fulfilling them, the employee confirming they can work, and everyone needing visibility into unresolved problems.
We also gained practical experience with database transactions, API validation, state synchronization, session management, integration testing, and debugging real full-stack failures.
Most importantly, we learned that successful onboarding isn't just about completing administrative tasks—it's about coordinating the people, tools, access, and knowledge that allow an employee to contribute.
Accomplishments We're Proud Of
We're particularly proud of transforming our original onboarding concept into a working, database-backed application rather than stopping at a static prototype.
Our implemented MVP includes persistent new-hire and transfer cases, editable request bundles, simulated bulk submission, server-validated fulfillment states, audit history, and evidence-based Day-One Preflight.
We also tested key workflows against a live PostgreSQL database and added automated coverage for critical business rules and user interface interactions.
Another accomplishment was building a system that can handle both fictional demo scenarios and arbitrary valid employee entries through the same workflow.
What's Next for Onboard?
Our longer-term vision is to make Onboard a practical coordination layer that organizations can integrate with their existing employee and service-management systems.
Future enhancements include:
- Enterprise service-desk integration: Authorized submission and status synchronization with systems such as ONRequest or ServiceNow.
- Employee self-service: Secure, role-specific experiences where incoming employees can confirm access, acknowledge handoffs, and report blockers directly.
- Enterprise authentication: Organizational single sign-on and fine-grained access permissions.
- Privacy-conscious AI handoffs: AI-assisted Starter Brief generation using approved enterprise APIs with no-training commitments or privately hosted models.
- Automated notifications: Alerts for outstanding approvals, approaching start dates, and unresolved readiness requirements.
- Production security and scalability: Stronger organizational controls, monitoring, and infrastructure appropriate for real employee information.
Our Vision
Employee transitions shouldn't depend on repeatedly chasing requests, guessing what's complete, or discovering missing access on the first day.
Version 1.0 was fragmented, difficult to track, and reactive.
Onboard makes Version 2.0 centralized, transparent, and proactive.
Because getting someone hired is just the beginning.
Getting them ready is what matters.
Built With
- git
- github
- javascript
- neon
- node.js
- postgresql
- react
- tailwindcss
- typescript
- vercel
- vite
Log in or sign up for Devpost to join the conversation.