What is in the product, and what comes later

A list of what a tool does not do is usually more useful than a list of what it might. This is ours.

In the product

Organizations, employee profiles, groups and reporting lines
Invitations, roles, a granular permission catalogue and seven record-level scopes
Time entries, a timer, daily and weekly views, and a calendar
Timesheet submission, approval, rejection and locking
Work schedules, holiday calendars, absences and missing-timesheet reminders
Leave requests, approval and configurable balances
Work items with your own types, statuses, priorities and custom fields
Labels anybody can add, built on the same typed fields
Workflows: which status moves each type allows, and what must be filled in first
Project milestones, with progress counted from the work filed against them
Rate cards, project budgets and invoices built from approved time
A service desk with queues, request types and SLA targets on your own working calendar
A customer portal where a contact raises and follows their own requests
Email to a queue address, which becomes a request and threads a reply onto it
Sub-items, links between items, saved searches, attachments and comments
Boards spanning several projects, with sprints and a backlog
Projects with membership
Distribution and timeline reports, utilization reporting and CSV export
A knowledge Library with collections, articles and revisions
An append-only audit trail
An Android app, with push notifications you control per type and per channel

How we decide what is next

Depth before breadth. Each capability above works properly before the next one starts, because a half-finished approval workflow is worse than no approval workflow.

Early-access organizations shape the order of the list below. If one of them is blocking you, tell us and it moves up.

Request early access

Deliberately not yet

Each of these is a decision with a reason behind it rather than an oversight.

Workflow screens, conditions and post-functions: Which status moves a type allows, and which fields must be filled in before a move, are built. The rest of what a workflow engine usually means is the part that needs a dedicated administrator, so it waits for a team that genuinely needs it rather than arriving as a tax on everyone.
Enterprise SSO (OIDC or SAML) and SCIM provisioning: The authentication-provider abstraction is built. The provider integrations sit on top of it.
Invoice PDFs, tax lines and credit notes: Rate cards, budgets and invoicing are built. A rendered PDF needs object storage running in production, and tax is a model that differs by country: both are their own piece of work rather than a finishing touch on this one.
An iOS application: The Android app is out. iOS is the same codebase and a different review process, a different signing story and a second store to keep current, so it ships when there is somebody asking for it rather than to complete a pair.
A public API and webhooks: A public API is a promise about a shape. The internal contract stabilizes before anyone builds against it.
Autonomous, unapproved agent actions: Every consequential AI action is human-approved. That changes only after an approval-gated track record, not before.