NaavekNAAVEK

Live demo

Experience Naavek

This is the core of how Naavek works. A requirement card moves through a lifecycle, assigned to teams, discussed, and when all parties agree, it locks into a decision. Try it.

1
2
3
PS
REQ-0001
Requirement

API authentication method

System must support OAuth 2.0 and token-based authentication for all API endpoints accessed by third-party integrations.

Click + Assign to bring in teams

The three states

One card. Three moments.

1
Unassigned
PS
REQ-0001
REQUIREMENT

API authentication method

Requirement created, no teams assigned yet.

Assign

Requirement created. No teams assigned. Lives in a backlog until actioned.

2
Under discussion
PS
REQ-0001
REQUIREMENT

API authentication method

Two companies assigned. Awaiting acceptance.

2 pending

Companies assigned. Each company sees Accept and Reject controls. Status shows pending count.

3
Decision
PS
REQ-0001
DECISION

API authentication method

All companies accepted. Card is now locked.

Decided

All companies accepted. Strip desaturates, badge locks, text dims. The card is now immutable, a permanent record.

The key insight

The requirement becomes the decision. It doesn't spawn one.

Most tools separate requirements from decisions: two different record types, two different places to look. In Naavek, the same card transitions state. The history is preserved in place. That's what makes the audit trail automatic.

Before

Requirements in Relatics, decisions in email, approvals in PDF. Three sources of truth.

After

One card. One state machine. Every transition timestamped, linked, and searchable.

Explore the product

There's more to see

Ready to use the real thing?

Join the waitlist and we'll onboard you personally on your first project.

Join the waitlist