FlightDeck

FlightDeck is a Next.js SaaS app for day-to-day project execution.

Boards are easy to build. The harder problem is keeping the work connected to the approved scope and timeline. A task card without context is just another item in a board. FlightDeck is designed around the idea that sprint work should still know where it came from.

If a task started as part of an approved scope, that connection should stay visible. If work is tied to a milestone, that should be visible. If a card is blocked, that should be able to affect the project’s health. If a sprint finishes, the team should be able to summarize what changed.

FlightDeck is the execution layer of the Osprey software suite.

It answers:

What is the team working on right now, what is blocked, what is done, and how does that relate to the scope and plan?

FlightDeck can work as a standalone kanban board, but the long-term value is in its relationship to FlightPlan and FlightPath.

• FlightPlan creates the approved scope.
• FlightPath creates the timeline and milestones.
• FlightDeck moves the cards through delivery.

The MVP should be a clean, fast kanban board with enough structure for real project delivery.

A user should be able to:

1. Create a business workspace.
2. Create a project.
3. Create a board.
4. Create columns.
5. Create cards.
6. Drag cards between columns.
7. Assign users.
8. Add due dates, labels, priority, and comments.
9. Create a sprint.
10. Attach cards to a sprint.
11. Close a sprint and move unfinished work forward.

The first version should not try to compete with Jira. It should be lighter, sharper, and easier for small teams.

A board contains columns and cards.

Default columns:

• Backlog
• Ready
• In Progress
• Review
• QA
• Blocked
• Done

Each board can be tied to:

• Workspace
• Project
• Sprint
• FlightPath plan
• FlightPlan scope

Each card can include:

• Title
• Description
• Assignee
• Due date
• Priority
• Labels
• Estimated hours
• Actual hours later
• Source scope item
• Related milestone
• Comments
• Activity history

Sprint support should be useful but not heavy.

MVP sprint features:

• Create sprint
• Set start and end date
• Add sprint goal
• Assign cards to sprint
• View active sprint
• Close sprint
• Move unfinished cards to next sprint
• Show completed cards

Later sprint features can include:

• Burndown chart
• Velocity
• Estimated versus actual hours
• Sprint summary
• Carryover tracking

This is where FlightDeck becomes more than another kanban board.

If connected to FlightPlan, an approved estimate row can become a task card.

Example estimate row:

• Phase: Design
• Task: Homepage design
• Role: Designer
• Hours: 12

FlightDeck card:

• Title: Homepage design
• Label: Design
• Estimated hours: 12
• Source: FlightPlan scope
• Related phase: Design

That preserves the connection between what was sold and what is being worked on.

If connected to FlightPath, cards can influence timeline health.

Useful connections:

• A blocked card can flag a milestone risk.
• An overdue card can affect project health.
• Completed cards can appear in a status report.
• Sprint summaries can feed weekly updates.
• Milestone cards can show timeline context.

The MVP can start with simple references and manual status. Automated sync can come later.

FlightDeck should be built for organizations, not just individuals.

Business account requirements:

• Business workspaces
• Workspace members
• Seat limits
• Pending invites
• Role-based permissions
• Claimed email domains
• Domain-based workspace discovery
• Optional SSO configuration

A business like knockinc.com should be able to manage a workspace where approved users with that email domain can request access or be invited. Admins should control access, remove members, and manage seats.

This is especially important for FlightDeck because boards become operational spaces. A company needs confidence that only the right people can see and modify the work.

FlightDeck should start simple and grow into business-grade auth.

Planned auth support:

• Email/password or magic link
• Google OAuth
• Workspace invites
• Domain-based workspace routing
• SAML/OIDC SSO for business accounts
• SCIM-ready provisioning later
• Role-based permissions
• Seat enforcement
• Admin controls for suspending users

The architecture should keep authentication, membership, and billing separate enough that enterprise access can be added cleanly.

FlightDeck is naturally seat-based.

Example tiers:

• Solo — one user, personal boards
• Team — five seats, shared boards, sprints, assignments
• Studio — fifteen seats, scope/timeline connections, reports, templates
• Business — custom seats, SSO, domain controls, advanced permissions

A paid seat should map to an active workspace member. Removed or suspended members should not retain access. Workspace admins should be able to see seat usage and upgrade when needed.

FlightDeck should be a Next.js application using shared suite infrastructure.

Suggested stack:

• Next.js App Router
• TypeScript
• Supabase Postgres
• Prisma or Drizzle
• dnd-kit for drag-and-drop
• Recharts for board and sprint reporting
• Stripe for subscription and seat billing
• Resend for notifications
• Inngest for reminders and background jobs
• SSO-ready auth layer
• Supabase Realtime later for live board updates

Important tables:

• users
• workspaces
• workspace_members
• workspace_domains
• workspace_invites
• auth_connections
• plans
• subscriptions
• seats
• projects
• boards
• columns
• cards
• card_labels
• labels
• sprints
• comments
• card_activity
• notifications

FlightDeck is in development as part of The Osprey software suite. The first build is focused on the board, card drawer, drag-and-drop movement, and sprint support.

I am looking for teams that want a lightweight execution board that connects back to the scope and timeline instead of becoming another disconnected task system.