Navbatly — A Support Desk SaaS for Agencies, Built on Laravel and Inertia.js

We built the tool we kept wishing we had

Every agency that sells support hours ends up with the same patchwork: a project tracker for the work, a timer or a spreadsheet for the hours, and a document for the client at the end of the month. We had that patchwork too, and month-end meant rebuilding the same numbers by hand for every client.

So we designed Navbatly around the thing the other tools leave out: the client's contract. Every request becomes a ticket numbered per client, like HBL-12, and every hour logged on it counts against the right contract in the month it was worked.

Problem one: tracking support hours

Time is logged on the ticket as client contact (calls, meetings, emails) or delivery (building, fixing, testing), and each entry is included in the plan, billable on top, or no charge. Change how a ticket is charged and it applies to new time, so a month you have already reported never changes under you. A month's hours export to CSV for invoicing.

Problem two: carrying hours over

A support plan holds a monthly allowance, with unused hours rolling into the next month up to an optional cap. When a month runs over, the agency chooses what happens: show it, bill it, carry it into next month or write it off. Goodwill hours go in as an adjustment with a reason, and terms can change from a chosen month without rewriting the months before.

Problem three: a client report in one click

Each ticket gets one plain-English line for the client, written once while the work is fresh. At the end of the month the report is already there: work completed and in progress, the hours for each, and the hours used and left on the plan. It goes to the client's contacts by email or as a private link with no sign-in, and Navbatly reminds the team if a month's reports have not gone out.

Why not Linear, Notion or a help desk?

We tried to make our existing tools do it first. Linear is excellent for product engineering, but it is built around issues and cycles, not a client's monthly allowance, so hours ended up in issue titles. A Notion database could hold anything, but every rollover rule, client view and report would have been ours to build and maintain. Service desks and time trackers each cover part of the job, and the gaps go back into a spreadsheet. The full story is in why we built Navbatly instead of using Linear or Notion.

The feature we did not plan: Client Clock

Once the hours were right, the next pattern was obvious: much of our late work was waiting on the client. Client Clock puts what we need — copy, files, access or an approval — on the ticket, asked of one person, with its own count of days waited. The client sends it from a private link without signing in, reminders go out on set days, and a project's target date moves later by every day it waited.

Why Laravel and Inertia.js

Navbatly is a Laravel application with an Inertia.js front end. Laravel handles routing, sign-in, permissions and the billing rules; Inertia renders the screens as a fast single-page interface without a separate API to version and secure. For a product whose value is in its rules — which month an hour counts in, how rollover is capped, who may change a contract — keeping those rules in one codebase was the deciding factor.

The same rules sit behind Navbatly's MCP server. Connect Claude or another MCP assistant, sign in with a Navbatly account — no API key to copy — and it can find and update tickets, log time, ask clients for what is needed and pull a client's report, with exactly the permissions that person has in the app.

Running Karve Digital on Navbatly

We moved our own client support into Navbatly before launch. On 28 October 2026 it held five clients (Karve Digital itself included), four monthly support plans and 139 tickets, 112 of them resolved, with 36 hours 55 minutes logged in October across 45 time entries. The work on Navbatly itself runs as one of those contracts, so we meet every rough edge first.

Much of the ticket and time work now goes through Claude. Even this case study was planned as tickets in Navbatly, opened and closed from Claude through the MCP server.

Building a SaaS product of your own?

This is the work we do for clients: product design, a Laravel application with a modern interface, an MCP server for AI assistants, and the marketing site that explains it all. See our SaaS development service, or try Navbatly yourself.