Why we built Navbatly instead of running client support in Linear or Notion

Support hours that add up, hours that roll over, and a client report in one click: the three jobs our tools could not do together, and what we built in Laravel instead.

Engineering7 min readPortrait of Oybek Khalikovic, CTO at Karve DigitalBy Oybek Khalikovic
Isometric blueprint illustration: a kanban board, a spreadsheet grid and a stopwatch on the left, their tangled cyan lines converging into one calendar block with an hour gauge, whose unused hours flow forward into the next month's block.

We built Navbatly because none of the tools we used could do three things together: track support hours against each client's monthly plan, carry unused hours into the next month, and turn the month's work into a simple report the client can read. Linear, Notion, help desks and time trackers each did part of it. The gaps were filled by a spreadsheet, rebuilt by hand every month.

What month-end looked like before

Our support clients are on monthly plans: a set number of hours for updates, fixes, checks and small improvements. Before Navbatly, that work lived in Linear. Each issue carried its hours in the title, like "[2 hours]", sub-issues held the internal breakdown, and a label marked the month. At the end of each month, for every client, someone had to:

  • pull the month's issues and re-read every title to add up the hours;
  • decide, line by line, what was included in the plan and what was billable;
  • rewrite each technical issue title as a sentence a marketing manager would understand;
  • work out how many unused hours carried into next month, from last month's sheet;
  • build a spreadsheet, check the totals and email it.

None of those steps is hard. Together they are slow, easy to get wrong and repeated for every client, every month — and they happen after the work, when the details are already fuzzy.

Pain point 1: support hours that don't add up

The question clients ask most is simple: how many hours have we used this month? Answering it should take a glance, not a recount. The trouble is that most tools track time against a task, while an agency sells time against a contract. When the contract is not in the tool, every total has to be rebuilt outside it.

Pain point 2: hours that should roll over

Rollover sounds trivial: unused hours move into next month. In practice it has rules. Is there a cap? When a month runs over, do you bill it, carry it forward or write it off? If the plan changes in March, does February's report change too? Every one of those rules lived in our heads and a spreadsheet, which is exactly where you do not want billing rules to live.

What we wanted instead: a statement per contract showing hours available, carried in, used and left, month by month.
What we wanted instead: a statement per contract showing hours available, carried in, used and left, month by month.

Pain point 3: no one-click report

Clients do not want a ticket export. They want one page: what was done, in plain English, and the hours included and billable. We wanted to press one button at month-end and send it. Instead, the report was a new document every time.

Why Linear didn't fit

We like Linear, and we still think it is one of the best tools for product teams. It is built around issues, projects and cycles, which is exactly right for shipping software. It is not built around a client's monthly allowance, a rollover cap or an overage policy, and giving clients a view of their own work means bringing them into a tool designed for engineers. So we bent it: hours in issue titles, sub-issues for the breakdown, and a spreadsheet at the end.

Why not Notion?

Notion can be shaped into almost anything, and that was the problem. A database of tickets with formulas for hours and rollover is possible, but then we would own a homemade app: per-client permissions, monthly snapshots so old reports never change, first-response targets, reminders to clients. We build software for a living. If we were going to own all of that, we would rather own it properly.

What about help desks and time trackers?

Help desks count tickets; time trackers count hours. When we compared them for Navbatly's own comparison pages, using the vendors' documentation as read on 28 October 2026, we found no native monthly hour allowance, rollover or overage in Jira Service Management, and Harvest's help centre described budgets that reset monthly but no rollover or overage. Customers also need to log in to follow their requests in Jira's portal. So agencies end up running two tools and a spreadsheet.

To be fair, each is stronger than Navbatly at its own job. Jira Service Management's SLA tooling goes much further, and Harvest invoices and takes payments, which Navbatly does not — it exports hours as CSV for whatever does.

What we built instead

Navbatly puts the contract at the centre. A client has one or more contracts — a support plan, a project budget or hourly work — and every hour logged on a ticket counts against one of them, in the month it was worked, as included, billable or no charge. Rollover, caps and overage are settings on the plan, not formulas in a sheet. Each ticket carries one plain-English line for the client, so the monthly report builds itself while the work happens.

The one-click report: hours used and left, billable and no-charge time apart, and each piece of work as one plain-English line.
The one-click report: hours used and left, billable and no-charge time apart, and each piece of work as one plain-English line.

Clients never need an account. Each gets a private link to send requests, deliver what we have asked for and read their report. That link is also where Client Clock lives: the count of days each project has waited on the client, with target dates that move to match.

Why Laravel and Inertia.js

We chose Laravel with Inertia.js because Navbatly is mostly rules, and we wanted those rules in one place. Laravel owns routing, sign-in, permissions and the billing logic; Inertia gives the team a fast single-page interface without a separate API to build, version and secure. Passkeys and two-factor sign-in, CSV exports and printable reports sit on the same foundation.

That decision paid off when we added the MCP server. Because the app and the assistant go through the same checks, Claude can open tickets, log time and pull a report for exactly the teams and role the user has — no API keys, no second permission model.

What changed for us

Month-end is now a review, not a rebuild. On 28 October 2026 we were running five clients, four monthly support plans and 139 tickets through Navbatly, with 36 hours 55 minutes logged in October. The build story, with screenshots, is in the Navbatly case study.

Should you build your own tool?

Usually not. If an off-the-shelf tool covers most of your process, adapt the process. We built Navbatly because the missing piece — the client's contract — sat at the heart of how we sell, and because building SaaS is our job. If your team is in the same spot, try Navbatly, or talk to us about SaaS development for your own idea.

Questions
Can Linear track agency support hours?

Linear is designed for product teams' issues, projects and cycles. It is not built around a client's monthly allowance, rollover or overage, so agencies usually pair it with a time tracker and a spreadsheet to produce client reports.

How should an agency handle rollover of unused support hours?

Agree the rules up front: whether unused hours roll over, the cap, and what happens to overage (show it, bill it, carry it forward or write it off). Then count each hour in the month it was worked, so earlier reports never change when terms do.

What should a monthly support report include?

One plain-English line per piece of work, split into completed and in progress, the hours for each, and the hours used and left on the plan, with billable and no-charge time shown separately. Skip internal ticket subjects and notes.

What is Navbatly?

Navbatly is a support desk for web agencies and freelancers, made by Karve Digital and built on Laravel and Inertia.js. It tracks tickets and hours against each client's contract, handles rollover, sends a plain-English monthly report and has an MCP server for Claude.

Talk to the people
who wrote this.

Let's Talk
Start a project