The Osprey
The Osprey
Plan in development

FlightPath

Map the work from approved scope to launch without burying the team in project management overhead.

Next.jsTypeScriptSupabasePostgresStripeRechartsResendInngestSlack integrationSSO-ready authNext.jsTypeScriptSupabasePostgresStripeRechartsResendInngestSlack integrationSSO-ready auth
What it does

Built around a sharper problem.

Where it is headed

Roadmap, in motion.

building2
  • Project plan model
  • Timeline and milestone views
planned5
  • Project health rules
  • Email alerts
  • Slack notifications
  • FlightPlan import
  • SSO and business domain controls
later0
  • — nothing yet
Deep dive

The thinking behind it.

The idea

FlightPath is a Next.js SaaS app for the moment after a scope is approved but before the team is fully in execution mode.

That moment is usually messy. The estimate exists somewhere. The proposal exists somewhere else. The project manager creates a timeline. The team starts building a board. The client wants dates. Everyone wants to know what is due, what is blocked, and whether the project is still on track.

FlightPath turns an approved scope into a clear delivery plan. It is not trying to become a giant project management platform. It is trying to answer a smaller and more useful question:

What is supposed to happen, when is it supposed to happen, who owns it, and what needs attention right now?

Product position

FlightPath is a timeline and project health layer for scoped digital work.

It sits between estimating and execution:

  • FlightPlan defines the scope and budget.
  • FlightPath maps the timeline and delivery milestones.
  • FlightDeck handles day-to-day task movement.

FlightPath can work on its own, but it becomes more valuable when connected to the rest of the suite.

MVP shape

The MVP should focus on manual planning first.

A project lead should be able to:

  1. Create a business workspace.
  2. Create a project.
  3. Create a plan.
  4. Add timeline items.
  5. Add milestones.
  6. Assign owners.
  7. Set due dates and statuses.
  8. Identify blockers and risks.
  9. Send basic alerts.
  10. Generate a status summary.

The first version does not need complex dependencies, critical path logic, or drag-resizable Gantt bars. Editable dates and a strong visual timeline are enough.

Timeline model

A FlightPath plan contains timeline items and milestones.

Timeline items are work blocks:

  • Discovery
  • Architecture
  • Wireframes
  • Design
  • Development
  • QA
  • Launch

Milestones are checkpoints:

  • Discovery approved
  • Sitemap approved
  • Designs approved
  • Development complete
  • QA complete
  • Launch ready
  • Go live

Each timeline item can include:

  • Name
  • Description
  • Start date
  • End date
  • Owner
  • Status
  • Risk level
  • Notes
  • Related scope phase
  • Related milestone

Each milestone can include:

  • Name
  • Due date
  • Owner
  • Status
  • Client action required
  • Blocker notes
  • Alert settings

Project health

FlightPath should make project health obvious without making users configure a complex scoring system.

A simple MVP health model could be:

  • Green — no overdue items, no blockers, no high-risk milestones
  • Yellow — upcoming deadline, client waiting, timeline pressure, or medium risk
  • Red — overdue milestone, blocked critical item, or high-risk status

Project health should appear in:

  • Project overview
  • Timeline view
  • Weekly status report
  • Alerts
  • Dashboard card

This is one of the strongest parts of the product. Many teams have boards full of tasks but no quick read on whether a project is healthy.

Alerts and notifications

FlightPath should begin with email alerts and later expand to Slack.

MVP alert types:

  • Milestone due soon
  • Milestone overdue
  • Timeline item overdue
  • Status update requested
  • Owner assigned
  • Item marked blocked
  • Project marked at risk

The product should support alert rules at the workspace and project level. In an agency context, different teams will want different notification settings.

A later Slack integration can support:

  • Project channel notifications
  • Weekly project digest
  • Blocker alerts
  • Milestone reminders
  • Status request prompts

Business accounts, domains, and seats

FlightPath should use the same business account foundation as the rest of the Osprey software suite.

Business account requirements:

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

For example, a team at knockinc.com should be able to belong to the Knock workspace based on approved domain access. The workspace admin should control whether domain users can self-join, request access, or require a direct invitation.

FlightPath is especially likely to be used by multiple people in one company because project tracking only works when the right team members can see and update the work.

Authentication and SSO direction

The MVP should not overbuild enterprise auth, but the architecture should not block it.

Authentication plan:

  • Email/password or magic link for MVP
  • Google OAuth for fast team onboarding
  • Workspace invites
  • Domain claim and verification
  • SAML/OIDC SSO as a higher-tier option
  • SCIM-style provisioning later
  • Seat enforcement tied to active workspace members
  • Admin controls for disabling or removing users

This makes the product approachable for small teams while still credible for larger companies.

Seat and license model

FlightPath can be sold per workspace with seat limits.

Example tiers:

  • Solo — one user, limited active projects
  • Team — five seats, shared timelines and alerts
  • Studio — fifteen seats, Slack alerts, templates, client-ready reports
  • Business — custom seats, SSO, domain controls, advanced permissions

Seat billing should align with active workspace members. A business should be able to invite users, remove users, suspend access, and see how many licenses are currently active.

Status reporting

A weekly status report is a natural product artifact.

FlightPath should generate a project update with:

  • Overall health
  • Completed work
  • Current focus
  • Upcoming milestones
  • Risks
  • Blockers
  • Client action needed
  • Timeline changes

The first version can generate a draft inside the app. Later versions can email it, post to Slack, or create a client-facing link.

Technical approach

FlightPath should be a Next.js application using the same platform foundation as FlightPlan.

Suggested stack:

  • Next.js App Router
  • TypeScript
  • Supabase Postgres
  • Prisma or Drizzle
  • Recharts for health charts and summaries
  • Custom timeline UI first
  • Stripe for subscriptions and seat billing
  • Resend for email alerts
  • Inngest for scheduled reminders and digests
  • Slack integration later
  • SSO-ready auth layer

Important tables:

  • users
  • workspaces
  • workspace_members
  • workspace_domains
  • workspace_invites
  • auth_connections
  • plans
  • subscriptions
  • seats
  • projects
  • project_members
  • delivery_plans
  • timeline_items
  • milestones
  • alert_rules
  • notification_events
  • status_updates
  • activity_events

Coming soon

FlightPath is in development as part of The Osprey software suite. The first version is focused on timeline clarity, milestone ownership, and project health visibility.

I am looking for project leads, account managers, and delivery teams who want a cleaner way to keep scoped work moving.

Interested in shaping FlightPath?

Help test, fund, or pilot the next version.