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
- Timesheet submission, approval, rejection and locking
- Work schedules, holiday calendars and missing-timesheet reminders
- Work items: three types, four fixed statuses, comments and history
- Projects with membership
- Utilization reporting and CSV export
- An append-only audit trail
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.
Deliberately not yet
Each of these is a decision with a reason behind it rather than an oversight.
- Service desk, queues, SLAs and a customer portal
- An extension of the same work-item model, so most of its behaviour comes almost for free once the base is settled. Building it first would have meant designing that base around a guess.
- Sprints, backlogs, ranked boards, custom fields and custom workflows
- Four fixed statuses that work beat a workflow engine nobody has configured. We would rather add these against real usage than guess at the shape.
- File attachments, avatars and document storage
- Nothing in the product needs binary storage yet. The model and the security controls are designed, and they ship with the first feature that genuinely needs them.
- Enterprise SSO (OIDC or SAML) and SCIM provisioning
- The authentication-provider abstraction is built. The provider integrations sit on top of it.
- Project milestones, budgets, rate cards and invoicing
- These depend on a pricing model. A rate card in the schema before that decision is a guess we would have to migrate away from.
- Leave and absence management
- The time domain leaves an integration seam for it rather than guessing at the shape of someone else's policy.
- Mobile applications
- Responsive web first. The interface works on a phone; a native app is a separate commitment.
- 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.