Tikr by Konabos
Tikr is the time-tracking and professional-services system we built to run Konabos. This page is what it does, what it costs, and where it’s going. There is nothing to sign up for.
Internal toolIn daily useBuilt with AI, owned by humansBy Konabos
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 on a roadmap we did not control. 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.
Five years ago, building this would not have made sense. Developer time was too expensive and the feature gap with off-the-shelf tools would have taken a year to close. That equation has changed. With Claude Code and AI-assisted development, the repetitive work on internal tools collapses dramatically and the team can focus on the decisions that actually require judgment. We wrote about how that shift played out across our migration tool, Krios, and Tikr in the launch post (opens in new tab).
We built Tikr the way we would build a product. The architecture is multi-tenant from day one, every query is scoped by organizationId, roles and rates and budgets all live on a permission matrix that would survive paying customers. We made that choice because anything less honest would have rotted under us as Konabos grew. We also made the choice not to sell it. Tikr is not a SaaS. It runs Konabos, and the operational learning flows into the client work we ship. That is the trade we are happy with.
Three jobs, in order of importance.
If recording time is a chore, people skip it, and the data underneath everything else gets unreliable. Tikr is built so a week of time entries takes minutes, not an hour.
Every entry carries a snapshot of the rate at that moment, every project carries a budget, every client has a margin. The answer to “are we profitable on this engagement?” is a number on a screen, not a question for the finance team.
Tikr started as time tracking. It now handles invoicing, allocation, and integrations with the systems we already live in. The architecture assumes we will keep adding capability, and that we will keep doing it ourselves.
Did you Tikr today?
That is the daily test. The name comes from “tick,” the smallest unit of time. If logging time is not a habit, none of the architecture matters. We designed for the ritual first.
Tikr is deliberately not a surveillance tool. There is no screen recording. There is no keystroke logging. There is no idle detection. There is no productivity score. There is no inference about how someone is working from how they are typing. Tikr is also not for sale. It is built like a product so it would survive being one, but Konabos is not a software vendor. There is no signup, no waitlist, no demo.
Konabos does not want those tools. We did not build them. The data Tikr collects is the data the team enters. Nothing more. The AI features that exist (you’ll see them below) are narrowly scoped, opt-in, and never trained on Konabos data.
Everything in this section is shipped and in daily use.
A few screens from daily use.
Tikr was built with AI assistance. The repetitive work (schema scaffolding, API routes, form validation, component boilerplate) compressed dramatically. The work that mattered (domain decisions, data model, rate snapshot logic, the permission matrix) stayed with us. That distinction is the whole point.
The AI features inside Tikr are narrowly scoped. Time-entry descriptions can be cleaned up before save (you review, you save). Blog-post angles can be suggested from anonymized weekly themes (client and project names are stripped before anything leaves the app). That is the list. There is no timesheet scoring, no productivity inference, no training on Konabos data, no AI deciding what is billable.
This is the same governance we ask clients to follow on their own stacks. If AI helped build it, a human owns it. If it runs in production, it is reviewed like any other system. If it drives a decision, it is validated. We wrote about why this matters in AI Is Rewriting Sitecore. Are We Ready? (opens in new tab), what happens when nobody enforces it in Nobody Is Stopping Me (opens in new tab), and what the identity-level answer looks like in practice in Your AI Agents Are Running Without Guardrails. Auth0 Has an Answer (opens in new tab).
Harvest. $10 per user per month.
Tikr. $20 a month, all in.
We are saving hundreds every month, and the gap widens with every new hire. (Hosting, database, email, AI features.)
The real cost of Tikr is not the bill. It is the time we spend building and maintaining it. We think that is worth it because the tool fits the work, and because what we learn building Tikr (about AI in production tools, about multi-tenant architecture, about the operations of a services firm) flows directly into the client work we ship.
We build Tikr in phases. We work on what is most useful next, and we ship when it is good enough to use. No hard dates.
Because the questions we get on social are genuine, and because how an agency runs itself says more about it than any case study does. Tikr is one of the more honest answers we can give to “how does Konabos actually work?” so we would rather show it than hide it.
Our goal is to solve our own problems first. If what we built helps someone else think through their own buy-versus-build call, that is a good outcome. If you are building something similar, or wondering whether to build or buy, find Akshay on LinkedIn (opens in new tab). He will tell you what worked and what did not.