Skip to content

Projects, work, time and approvals on one model

Four capabilities that only work properly together, which is why they share one model instead of an integration.

Time tracking

Correct time beats convenient time. We accept some interface complexity to avoid an ambiguous timestamp.

How time gets captured

  • A one-click timer, with one running timer per person per organization.
  • Manual entry by duration, or by start and end.
  • A weekly grid, a daily view, and a per-project rollup.
  • Billable flag, activity category, and a free-text note.

Why the time maths is trustworthy

Every entry stores a UTC instant, the employee's IANA time zone, and the business date, together. That is what makes an overnight shift and a daylight-saving transition ordinary arithmetic rather than a defect discovered in April and October.

Attribution is offered, never demanded

A time entry needs an employee, a work date, a duration, and an activity category. Project and work item are optional, always. Plenty of organizations track time against categories and nothing else, and a product that refuses to record an hour without a ticket number is unusable for them.

Organizations that want stricter attribution can require it: project mandatory, project mandatory for billable time, or a description required when no work item is chosen. The default is permissive and the policy is yours.

Approvals

Approval is a state machine with a permanent decision log, not an informal nod in a chat thread.

The timesheet approval state machine A period moves from draft to submitted to approved to locked. A submitted period can be rejected back to draft, which requires a comment. An approved period can be reopened by an administrator, which is recorded. Draft Submitted Approved Locked rejected (comment required) reopened (administrative, recorded)

Approved data is immutable

Once a period is approved it is not silently editable. A correction is a new, attributable event, so the history explains itself later. Self-approval is refused unconditionally, including for organization owners.

Chasing is the system's job

Missing-timesheet detection is schedule-aware and holiday-aware, and it notifies people in their own local morning rather than the office's. Managers approve a week for their reports in one screen.

Every change is auditable

Who, what, when, before and after, for every entry and every state transition. A rejection requires a comment, because "rejected" with no reason is a message somebody then has to chase in another tool.

Permissions

"Admin or not" is how accounts become over-privileged and how data leaks between teams. LynxSprint is built on a granular permission catalogue with record-level scopes.

Seven record-level scopes

A permission answers what you may do. A scope answers whose records. Own, direct reports, the whole reporting line, groups you lead, projects you belong to, projects you lead, and the organization.

The org chart is explicit

Reporting manager relationships and group membership are first-class records with effective dates, so approvals route to the right person instead of the person someone remembered to configure.

Multi-organization people are first-class

A person is one identity. Their employment in each organization is a separate profile with its own roles, state and data, so contractors and fractional staff do not need duplicate accounts.

Record-level scopes, narrowest first
  1. Own records yourself
  2. Direct reports people who report to you
  3. Reporting line the whole tree beneath you
  4. Led groups groups you lead
  5. Member projects projects you belong to
  6. Led projects projects you lead
  7. Organization everyone, by explicit grant

Isolation is treated as a safety property

Tenant isolation runs in four independent layers rather than one, and the outcome is simple to state: a request for another organization's data is indistinguishable from a request for data that does not exist. The security page covers what those layers guarantee.

Work and projects

Enough structure to plan and attribute work, and no more. The bounds below are deliberate, and naming them is more useful than implying a depth that is not there.

What is included

  • Three types: story, task and bug.
  • Four fixed statuses: open, in progress, blocked, done.
  • A generated project-scoped key, never reused.
  • Title, description, priority, assignee, reporter, estimate, due date.
  • Comments, status history and audit events.
  • A project list, a "my work" view, and an optional fixed-column board.

What is not

  • Configurable workflows and custom fields.
  • Sprints, backlogs and ranked drag-and-drop boards.
  • Parent/child hierarchy, links, watchers and labels.
  • File attachments.
  • Service-desk queues, SLAs and a customer portal.
  • Milestones, budgets, rate cards and invoicing.

Several of these are on the roadmap, which says which ones and why they are not first.

Projects stay minimal on purpose

A project has a code, a name, a status, a billable flag, a client name, dates, and members. Members exist because project membership is one of the record-level scopes. Budgets, rate cards and milestones wait for a pricing model decision we have not made yet.

See it on your own data

Tell us how your team runs today and we will come back with timings.

Request early access