JITR

JITR began with a problem my co-founder and I knew firsthand. We had worked night shifts, reception desks, check-ins, closing shifts and other roles where an absence could put immediate pressure on the people still working.

Staffing problems rarely arrive as one dramatic event. More often, a manager covers the shift, someone loses a day off, or the rest of the team absorbs the extra work. The operation continues, but the cost accumulates quietly.

We had also experienced the other side of that process: receiving a message on a day off asking whether we could cover. The request might be optional, but declining could still carry a sense of guilt. Managers were spending time contacting people individually, while employees had no clear way to signal when they were available and willing to work.

JITR grew from the idea that the people, shifts and trust already existed. What was missing was visibility, consent and timing.

The schedule sits at the centre of JITR. A business can organise workplaces, departments and recurring positions, then generate and adjust its roster without rebuilding each week from the beginning.

When a gap appears, the same schedule entry can move through a defined coverage path:

Plan the shift
Create the position once, assign it where possible and keep its history attached to the schedule.

Offer it to the team
Team Cover notifies relevant employees and lets them indicate whether they are available and interested. Managers can see the responses without contacting everyone individually.

Open it to the marketplace
If the existing team cannot cover the shift, it can be opened to workers outside the company through the JITR Marketplace.

Choose and confirm
The manager reviews the interested workers, selects the best fit and confirms the assignment. The final decision remains with the business.

Employees use the same platform to view their schedules, record availability, request time off, arrange shift swaps, receive notifications and communicate with their workplace.

The first version of JITR centred on connecting businesses with available workers for individual shifts. As the product developed, it became clear that external cover was only one part of the problem.

A staffing gap begins inside the normal operation of a business. It is connected to the schedule, the existing team, availability, time off and the decisions that led to a shift becoming open. Treating the marketplace as a separate system would lose that context.

JITR therefore expanded into the day-to-day workflow around the shift. Businesses can plan recurring rosters, manage employees and manager permissions, handle time-off and swap requests, offer open shifts internally and escalate them to the marketplace when necessary.

Time clocks extend that record from planned work into completed work. Employees can clock in through their phone or a shared kiosk, with optional geofencing for location-aware attendance. Managers can inspect work sessions, correct mistakes without erasing the audit history and export worked hours for further payroll processing.

JITR originally focused on stable workplaces such as hotels, restaurants and cafés. Supporting contractors and field-service teams introduced a different planning model.

A stable workplace is organised around departments, recurring positions and ordinary shifts. A temporary worksite is organised around dated assignments, project instructions and optional daily reports. Forcing both into the same model would make either the roster or the worksite workflow unnecessarily complicated.

The two planning models remain separate, but share the systems that should feel consistent: employee calendars, time clocks, attendance records, notifications and reporting. An employee sees where and when work is expected without having to understand how it was represented internally.

My role has been on the technical side of JITR, translating operational knowledge into the product and building the platform across its frontend and backend.

The backend is built with Java 21 and Spring Boot, with PostgreSQL and Flyway providing the data model and migration history. It contains the business rules for scheduling, eligibility, availability, assignments, attendance, subscriptions and permissions. An OpenAPI contract connects it to the frontend and keeps the two codebases aligned.

The interface is built with Next.js, React and TypeScript. React Query manages server state, Zustand handles shared client state, and the complete interface is available in Icelandic and English. Capacitor provides the native mobile shell and access to device capabilities such as push notifications.

Much of the engineering work is not visible in an individual screen. Overnight shifts, time zones, overlapping assignments, concurrent manager actions, corrected clock events and changing permissions all have to preserve a coherent history rather than simply updating the latest value.

JITR is live at jitr.is and remains under active development. Businesses can use a free scheduling foundation or add more advanced controls for worksites, time tracking and reporting.

Current development is moving toward deeper operational reporting and Júlíus, a manager-facing assistant that can inspect live schedule data, find staffing gaps and prepare actions for approval. The aim is not to replace management decisions, but to reduce the navigation and manual coordination required to carry them out.