Software that stays out of the way
Krrim is project management for teams who would rather spend the afternoon shipping than administering the tool they ship with.
Why we built it
Every team we worked with had the same shape of problem. The tool they used was either too simple to hold a real backlog, or powerful enough that somebody ended up owning it full time — maintaining workflows, explaining fields, and reconciling reports that measured different things under the same name.
Krrim is our answer to that. It is opinionated where it can save you a decision, configurable where teams genuinely differ, and deliberately quiet everywhere else.
Who builds it
Krrim is built and operated by Pybex Technology Private Limited, a product engineering company. We build and run our own products — Krrim is one of them, and we use it to build the others.
That last part matters more than it sounds. Every feature on this site is one our own team relies on, which is a much harsher test than a roadmap.
The principles behind the product
Six rules that explain most of Krrim's less obvious choices — including the ones people occasionally argue with.
Usable before it is configured
A new project arrives working. Nothing in Krrim requires a setup project before you can add real work — and teams that configure first almost always configure the wrong thing.
Refuse to guess
The critical path leaves out tasks it has no dates for. Standup history is never recomputed. A confidently wrong answer is worse than an honest absence, because people act on it.
One definition, one place
Cycle time is computed once and read everywhere — in the chart, in the export, through the API. Two implementations of a metric eventually disagree, and then nobody trusts either.
Safe by construction, not by convention
Workspaces are separated by database schema. Guests see only what they were given. The public API is an allowlist. Each of these is structural rather than a rule someone has to remember.
The API is a first-class surface
Scoped tokens, signed webhooks, rate-limit headers on every response, and a published retry curve. The documentation is written by the people who wrote the code.
Built for the second year
Anything can look good on a fresh workspace. The features that matter are the ones that hold up against a backlog with two years of history in it.
Where to go next
If you want to know how the product works, the guides are written for people using it rather than evaluating it. If you are deciding whether to build against it, start with the developer documentation. If you are working through a security review, the security page covers the architecture and the sub-processors.
And if none of those answer it, write to us. A person replies.
See whether it fits how you work
Free to start, and nothing needs configuring before you can add real work.
Free to start · No credit card required