Setting up an issue tracker has a clear starting point: create projects, invite colleagues and add the first issues. The more demanding questions tend to arrive later. A team changes its approval process, introduces automation or needs to hand over a departing colleague's work. Someone has to explain why an issue changed status, or decide how an existing project should adopt a new workflow.
We're building Quevell with that everyday reality in mind. We want teams to manage their work, adapt their processes and understand what is happening to their issues, settings and data.
The product draws on its founder's 19 years in corporate IT, working with service operations, access management, integrations, administration and migrations. That experience brings a particular set of questions into focus: who will maintain the system, who can change it, how will they check the result, and what record will remain of earlier decisions?
Start with what someone needs to do
People open a tracker for specific reasons. An assignee needs to know what to do next. A manager needs to see where work has stalled. An administrator needs to adjust a process so that colleagues can keep working.
We find Amazon's Working Backwards approach useful here. Before building a product, teams describe it through a press release and a set of frequently asked questions. Who is it for? What problem does it solve? What will customers appreciate, and what might disappoint them? Andy Jassy describes this mechanism in his 2024 letter to shareholders. The useful part is the sequence: work out what should improve for the person using the product, then decide how to build it.
Consider automation. Being able to create a rule leaves an important question unanswered: how do you know what it will do to the issues already in your project?
In Quevell, you can check a rule against real data without saving any changes. The check shows which issues match and which actions would run. It sends no external calls. An administrator can inspect the proposed effects before enabling the rule.
That's the level of detail we aim for. A feature needs a clear purpose in someone's work, including what they need to do before using it and how they assess the result afterward.
Make changes understandable
Teams refine their working agreements as they go. They add an approval, remove an unnecessary step, split a project or change who is responsible. Quevell should support that evolution while keeping enough history to explain what changed.
Published workflows therefore have a revision history. You can inspect an earlier version, see who published it and when, and load it as a draft for a new publication. Returning to an earlier design becomes another deliberate, recorded change.
Each issue has its own history, and the company has an audit trail. When someone needs to find out who changed a setting or granted access, the system should hold the answer.
Stripe offers a useful example of considering the work affected by a product change. In its explanation of a new API release process, the company describes customers asking for more predictable updates so they could plan their engineering work. Stripe responded with a new release schedule and a redesigned changelog that made the impact on a particular integration easier to understand.
We share the principle behind that decision: a service should evolve with consideration for the people who depend on it.
In our own development process, changes go through automated checks and a separate staging environment before release. We document the reasoning behind architectural decisions. When a decision needs revisiting, its original purpose and tradeoffs are available to read.
Keep access and administration under control
A small team can settle many questions in conversation. As it grows, access and responsibility need to become more explicit.
In Quevell, project roles and issue-level restrictions determine access. Administrator rights can be granted for a defined period and expire automatically. Handover lets an administrator transfer work to a successor when a colleague leaves.
These decisions follow a practical expectation: people need enough access to do their jobs, and the company needs to understand who has that access and why.
Maintaining the tracker should also take a reasonable amount of effort. If a routine administrative operation requires visiting dozens of projects individually, that's a reason for us to reconsider the product's design. Our product principles explicitly call for reducing administrative work and avoiding artificial inconvenience intended to push customers toward an upgrade.
The same thinking applies to data. A company should be able to take the results of its work with it. Quevell currently supports issue exports as CSV, archives containing issues and attachments, and knowledge page exports as Markdown. The formats and limits are documented. A single export of the entire company is not yet available.
We don't sell customer data. The service has no advertising pixels, session replay or browser fingerprinting. Those choices are part of how we treat the information companies entrust to a working tool.
Try it with your own work
Quevell currently brings together issues and projects, boards, sprints, workflows, automation and a knowledge base. Its API allows teams to connect it to other systems.
We want a team to be able to assess the product through its own work: run a small project, configure the fields it needs, check an automation rule and review the history of its changes.
That's why five seats and one service account are free, with all features included, while the company remains active. There is no trial countdown. Additional seats are paid separately.
As Quevell develops, we want concrete working situations to guide it. When a user gets in touch, we want to understand what they were trying to accomplish, where they got stuck and how that affects the team. Understanding the situation helps us find a solution that can be useful beyond a single request.
Our goal is practical: teams should be able to use Quevell for years, change how they work and retain a clear understanding of what is happening.
This blog will explore the decisions and practices behind that goal: engineering, team management, access control, data and reliable systems. This first article introduces Quevell. The ones that follow should also be useful to people who use other tools.