Crucial points and objections

The three points that matter

1. Agents work under the same rules as people, and you can see what they did. Every change records who made it and whether an agent did, without anyone declaring it.
2. The workflow asks for evidence, not trust. An issue can be held until its plan is verified, its code has reached a branch, and its time is logged. Quasar checks these itself.
3. From plan to client in one tool. Quotes, reviewed and accepted documents, frozen documentation releases and public guides come from the same project data.

Built with itself

The strongest evidence for Quasar is how Quasar itself is built.

Everything lives in Quasar. Every piece of Quasar's own work is tracked in Quasar:

• every feature, bug and task;
• every plan made before the code was written;
• every architectural decision;
• every document, including this guide.

Agents do the work, under its rules. AI coding agents pick up the issues. They record a verified plan before writing code, move the work through the same workflow Quasar offers its customers, and have their working time measured by its clock. One architect supervises: decides what is built, reviews, and accepts.

The workflow is tested on its own builders. The workflow that demands evidence from agents is enforced on the agents that build Quasar. Every rule in it was learned on Quasar's own work first, and every limit described in this guide is met by its makers before anyone else.

Measurable, and dated. As of version 2026.10.15:

• more than 19,000 automated tests, at 100% coverage, run before a change is accepted;
• new versions ship days apart.

Young, and honest about it. Quasar is a young product built by a single architect with AI agents. It is less mature than trackers with years and large teams behind them, and it says so in this guide. What it has instead is a product whose every rule has been lived by its makers before being offered to anyone else.

This guide is an example. An agent wrote it from the project's own documents and decisions. A person reviewed it and accepted it as a release revision before it became public.

"Our tracker already has an MCP server."

Most trackers have one by now. It gives an agent access. What the agent must prove before work moves on stays a matter of configuration and of people watching.

In Quasar that policy is part of the workflow:

• a plan verified against the files it examined;
• code Quasar has seen reach a branch in the repository;
• time measured by Quasar's own clock and confirmed by a person.

Around it:

• every change an agent makes is marked automatically;
• every write can be retried without duplicating;
• every refusal tells the agent which rule to satisfy.

See Comparison with alternatives.

"You are a small vendor. What if you disappear?"

Your work does not depend on us being reachable:

• Quasar can run on your own infrastructure, the same product as the hosted service.
• An organization's data can be exported in full at any time.
• Documents and releases export to PDF, Word, HTML and Markdown, readable without Quasar.

"The interface is English only, and desktop only."

True today. The interface was designed from the start to be translated: every word on screen comes from translation files, not from the code. English came first as the common language. Now that Quasar is reaching its market, the next steps on the roadmap are languages, starting with European ones, Italian and French first.

Content was never limited to English:

• documents can be written in any language, each marked with its own;
• built-in document templates already exist in English and Italian.

The interface is designed for desktop screens; there is no mobile app.

"There is no Slack, no webhooks, no integrations."

True. Quasar has no chat integrations and does not call other systems when something changes.

What it has is a complete REST API and an MCP server: any script, CI job or AI agent can read and do everything a person can, under that person's permissions. Integrations are built on that today.

"How do we migrate our existing issues?"

There is no ready-made importer from other trackers yet. Data can be brought in through the REST API, which accepts the same operations as the interface, safely retryable. An agent connected over MCP can also move work across item by item, following the project's rules.

"Can we trust an agent with write access?"

You decide how much it can do, and you can always see what it did:

• Its permissions are its person's. A key acts only with its owner's permissions; a project the owner cannot see does not exist for the agent.
• Read-only, enforced. A read-only key is enforced by the database itself: it cannot write.
• Nothing silent. Every change is attributed to the key's owner and marked as an agent's.
• Evidence first. The workflow can hold work until the agent provides evidence.
• Acceptance. Quasar's agent contract tells agents to accept documents only on a person's word. To make it impossible, give the agent a key whose owner is not a project lead.
• Time. An agent's time becomes a cost only when a person confirms it.

"Where is our data, and who can see it?"

• The hosted service runs in the European Union, on Amazon Web Services in Ireland.
• Organizations cannot see each other. Isolation is enforced by the database's row-level security, not by application code alone.
• Operator access is limited and recorded. Inside the application, the operator of the service can look into an organization only through a "view as" session: read-only, as a member it chooses, for at most an hour, marked with a banner, and recorded in your organization's audit log.
• Self-hosting puts your data wherever you run it.

"It is another tool for the team to learn."

People use a conventional web interface, with a glossary and step-by-step guides inside the application.

The bigger difference is that the agent can guide the person. An agent connected to Quasar learns the project's rules on its own when it connects. It can then do the operations itself or walk a person through the interface step by step, whichever they prefer.

This guide is an example: it is written so an AI assistant can read it, find the relevant chapter from its summary, and answer a newcomer's questions.