Project Management ATLAS

A project tool is easy to build badly. Boards and cards are a solved interface, and the second you add an AI assistant to one, the assistant becomes the most interesting and most dangerous part of the product: it needs to read across projects, boards, tasks, calendars, and personal items to be useful at all.

The obvious implementation is to give the AI tooling a service-role database connection so it can answer anything. That also means every private board in the workspace is one prompt away from being readable, and the permission model you spent weeks on now applies to the UI only.

Every data path in the application, including the assistant's tools, goes through the Supabase session client, so Postgres row-level security applies to the AI exactly as it applies to the person typing. There is no privileged read path for convenience. When the assistant cannot see a private board, it is because the database refused, not because a prompt asked it not to look.

Above that sits a capability layer: a single module that answers "can this user do this thing" for the whole product, so role checks are one decision rather than dozens of scattered conditionals. Board membership, team scopes, and managed task statuses all resolve through it.

Schema changes are hand-written numbered SQL migrations rather than a generated diff, applied through a migration runner with a status command, and guarded by a database guard script that refuses to point development at production.

The assistant runs in two modes. Workspace mode reads the user's real tasks, boards, personal items, and marketing calendar through the tools described above. Ask-anything mode reaches outward instead, with Tavily-backed web search and a URL fetcher.

Fetching URLs on a user's behalf is a server-side request forgery primitive if you implement it naively, so the fetcher validates its targets rather than trusting the string it was handed. Both modes are rate-limited separately, because a web search and a workspace query do not cost the same thing.

Input is multimodal: images, PDFs, audio, video, and YouTube links, routed to a model that can actually handle the modality rather than a single default.

The product surfaces share one shell: sidebar, breadcrumbs, command palette, and mobile navigation, with commands registered per permission so the palette never offers an action the user cannot perform.

Some smaller decisions that mattered more than they sound: undo-capable toasts on the two destructive deletes that were previously silent, restoring the original row identifier rather than inserting a copy; unsaved-change protection on the create dialog; and a per-user density setting, because the people living in this tool all day and the people opening it once a week want different information density.

Authorisation is the part of this product where a regression is invisible until it is a breach, so it is checked from two directions. Unit tests under Vitest cover the capability decisions and row-level-security write helpers. Alongside those sit standalone check scripts that run against a real database and assert behaviour rather than intent.

check:access-matrix     who can read what, as a matrix
check:isolation         cross-tenant isolation
check:board-roles       board-scoped role enforcement
check:grants            grant resolution
check:deprovision       access removal on offboarding
check:deactivation      deactivated-account behaviour
check:task-lifecycle    task state transitions
check:marketing-*       calendar access, channels, recurrence

Automated accessibility checks with axe run against the shell, and there are dedicated passes at 200% and 320% zoom. Those found four real defects that manual review had missed.

• Single organisation, permanently. This is not a multi-tenant SaaS and the roadmap does not pretend otherwise. Teams, roles, guests, and module activation all exist, but scoped within one organisation. That decision removed an entire class of work.
• Build, do not fork. Adopting an existing open-source project engine would have meant running two backends and inheriting network copyleft. The existing stack already had auth, row-level security, and the AI layer, so the open-source tools became reference designs for data models rather than a foundation.
• No privileged AI read path. Slower to build, and it means the assistant sometimes has to say it cannot see something. That is the correct answer.

In active development and deployed behind sign-in for one organisation, which is why there is no public link on this page and no product screenshots: the data in it belongs to a business, not to a portfolio.

The source is public. Between August and September the first three roadmap phases reached production: a custom-fields engine with twelve field types validated in the database, four layouts rendered from one saved-view model, and goals kept separate from the work they measure. Milestones, an optional agile mode, and an inbox followed. Before the last modules were switched on, a read-only audit of production found all 79 tables under row-level security.

Next are a deeper marketing calendar, forms and intake, and automation rules. Those are planned, not built.