For years, Konabos ran on Harvest. It did the job. Time tracking, basic reporting, invoicing hooks. Every consultancy needs a tool like that, and Harvest was the default. We paid the subscription every month and moved on.

Then we stopped.

Not because Harvest got worse. Because we did. Every time we wanted a feature that fit how Konabos actually runs, we were waiting. Waiting for a roadmap we did not control. Waiting for a generic answer to a specific problem. Paying for features we did not use and missing the ones we did. We were exporting data, stitching spreadsheets, and building mental models outside the system. The tool was no longer helping us run the business. We were working around it. That is the moment you stop using a tool and start compensating for it.

So we built our own. We call it Tikr.

The Problem Was Never Time Tracking

Time tracking tools solve a generic problem. Consulting companies do not have generic problems.

We needed to answer questions that tools like Harvest were never designed for. Are we actually profitable on this project. Are our rates aligned with reality or just assumptions? Where is time being spent versus where value is created? How do we connect delivery, finance, and operations into one view?

If time is the fundamental unit of a services business, then every downstream number depends on getting that unit right. Time to cost. Time to revenue. Time to utilization. Time to profitability. When the tracking tool sits in isolation from the rest of the stack, every one of those calculations requires manual stitching. That is where hours get lost and where arguments start.

At some point, you realize something uncomfortable. You are not running your system. Your system is running you.

The Name

Tikr comes from "tick," the fundamental unit of time. The daily test is simple: did you Tikr today? If the tool does not pass that test, none of the architecture matters. People will find a way around it. We designed for the ritual first.

What It Actually Does

Tikr started as a time tracking replacement. It is becoming a full professional services management system. Today it handles authentication with email and OAuth, six built-in roles with granular permissions, client and project management, budget tracking with monthly resets, running timers, weekly timesheet grids, submission and approval workflows, an eight-tab admin dashboard covering billability through compliance, time reports with CSV export, and draft invoicing from unbilled time.

One technical detail worth calling out: rate snapshots. When someone logs time, we capture the hourly rate at that moment. If rates change next quarter, historical entries stay accurate. That sounds small. It is the difference between a clean profitability report and an argument in a meeting.

The architecture is multi-tenant from day one. Every query is scoped by organizationId. Strict TypeScript, no any types allowed. Next.js App Router with Server Components by default. Boring, reliable choices underneath. The interesting work happens on top.

Why We Could Do This Now

Five years ago, a small consultancy could not have built its own PSA platform. The math did not work. Developer time was too expensive, and the feature gap with Harvest would have taken a year to close. Internal tools felt like a distraction from client work.

That equation has changed. We are deep into Claude Code and AI-assisted development. Not as an experiment. As the way we build. Tikr was not a two-year engineering project. It was a focused sprint where the repetitive work, the schema scaffolding, the API routes, the form validation, the component boilerplate, was compressed dramatically. The work that mattered, the domain decisions, the data model, the rate snapshot logic, the permission matrix, stayed with us.

This is the same pattern we have been describing in every piece of content we put out this year. The AI migration tool that moves full websites into Sitecore in under 45 minutes. The AI-first CMS experiment we ran in one evening. The Figma-to-Sitecore workflow for a pharma client. Krios, the headless CMS we built from scratch with a schema-first architecture. In every case, the story is the same. AI handles the repetitive assembly work. Humans own the decisions that require judgment.

Tikr is that same philosophy applied to our own operations. We are not using a different set of tools than our clients. We are showing what happens when a consultancy runs its own playbook.

Responsible AI Starts With the Team Using It

We have talked about this in our other posts and webinars. The conference talk in Sydney. The blog post on governance gaps in Sitecore. The webinar on vibe coding. The repeated observation that AI is generating production code, marketing content, and personalization logic faster than most enterprise teams can govern it.

The risk is not AI. The risk is unowned AI output.

So even with Tikr, we follow the same rules we talk about publicly. If AI helped build it, a human owns it. If it runs in production, it is reviewed like any other system. If it touches business-critical workflows, it is tested and validated.

That is a harder path than buying. It is also a more honest one. We are asking clients to think carefully about how AI is reshaping their platforms. The least we can do is hold ourselves to the same standard on our own stack.

Solving Our Problems First

Here is the part that matters. We did not build Tikr to sell it. We built it because we needed it.

That distinction changes everything about how the product evolves. Every feature goes in because someone on the team hit a wall with the existing workflow. The dashboard tabs exist because a leadership question needed an answer we could not get fast enough. The rate snapshot logic exists because a historical report was wrong and we had to fix it. Phase 2 is prioritizing Azure DevOps integration because linking time entries directly to work items is a daily friction point for our delivery team.

There is a discipline in building for yourself that is hard to replicate when you are building for a market. You cannot fool yourself about adoption. Either the team uses it daily or they do not. If they stop using it, you know within a week. The feedback loop is immediate and unforgiving.

This is a different philosophy than building SaaS. When you build SaaS, you chase the average user. You build features that demo well. You optimize for onboarding. When you build for your own team, you optimize for the person who has been using it every day for six months and needs one more thing. That is a healthier design constraint.

What This Says About Where We Are Going

Konabos has always been a judgment-focused consultancy. Senior people, small teams, architectural accountability. The positioning has not changed. What has changed is the tooling underneath.

Tikr is a signal. We are not a traditional agency that bought into AI because the market demanded it. We are a practitioner team that rebuilds its own operational stack when the existing tools stop fitting. We did it with the migration tool. We did it with Krios. We are doing it with Tikr. We will do it again next quarter with something else.

Most companies are still renting their operating system. Time tracking. Project management. Reporting. Operations. And then they wonder why everything feels disconnected. AI is quietly changing that. Not by replacing systems. By making it viable to build the right ones.

Did you Tikr today? Ours did. And tomorrow it will do something it could not do last week. That is the difference.

Let's gooooooo!

Related reading on how we work:

- AI Is Rewriting Sitecore. Are We Ready? (governance and the responsible AI question)
- The Implementation Cost Problem Nobody Wants to Talk About (the AI migration tool)
- Do We Even Need a CMS Anymore? (the AI-first CMS experiment)