FlightPlan

FlightPlan is a Next.js SaaS app for the part of project work that usually happens before the project management tool ever opens: estimating, scoping, pricing, caveats, assumptions, and internal alignment.

Most digital projects still start in a spreadsheet. Someone breaks the work into phases, guesses at hours, adds roles, edits rates, drops in caveats, copies the total into a proposal, and hopes the team remembers why those numbers were chosen three weeks later.

FlightPlan keeps the flexibility of a spreadsheet but gives the estimate a real product structure. The working estimate can be edited by multiple people. The client-facing scope can be locked. Alternate versions can be duplicated. Roles and rates can be reused. Caveats can be standardized. The final output becomes something closer to a productized scope document than a fragile spreadsheet.

FlightPlan is not trying to replace every proposal tool, spreadsheet, or project management platform. It is focused on one valuable moment:

Before a team agrees to the work, everyone needs to understand what is included, how much it costs, what assumptions are being made, and what happens when the scope changes.

That is where FlightPlan lives.

The first version is built for agencies, studios, freelance teams, and internal delivery teams that price work by phase, sprint, role, and effort. It should feel familiar to anyone who has ever estimated a website, product sprint, CMS build, integration project, or digital campaign.

The MVP starts with the smallest useful workflow:

1. Create a business workspace.
2. Create a project.
3. Add one or more scopes.
4. Break a scope into phases.
5. Add line items for each phase.
6. Assign roles, rates, hours, notes, caveats, and optional status.
7. Review totals and blended rate.
8. Lock the scope.
9. Generate a clean client-ready view.

The important part is that the locked scope becomes a frozen artifact. The team can duplicate it into a new version, but the approved version should stay intact.

A FlightPlan estimate is organized around phases. A default web project might include:

• Discovery / audit
• Site architecture
• Wireframes
• Visual design
• Development
• CMS implementation
• QA
• Launch
• Project management

Each phase contains estimate rows. A row can include:

• Task or deliverable name
• Role
• Hourly rate
• Estimated hours
• Line item cost
• Notes
• Internal notes
• Caveats
• Included / optional status

The math is intentionally straightforward:

• Line cost = hours × hourly rate
• Phase total = sum of phase line costs
• Scope total = sum of included phase totals
• Optional total = sum of optional items
• Blended rate = total cost ÷ total hours

The first version does not need to be Google Sheets. It needs to be good enough for a small team to contribute without losing the thread.

MVP collaboration includes:

• Workspace members
• Project members
• Role-based permissions
• Last edited metadata
• Internal notes
• Scope-level comments
• Activity log
• Locked state

Later versions can add live multiplayer editing, row-level comments, and approval workflows.

FlightPlan should be built as business software from the beginning. A single user can create a workspace, but the real value is in letting a company use it together.

The account model should support:

• Individual users
• Business workspaces
• Workspace members
• Seat limits
• Pending invites
• Role-based permissions
• Claimed email domains
• Workspace discovery by domain
• Optional SSO configuration

A company like knockinc.com should be able to create a workspace, claim or configure that domain, and allow approved users with that business email address to join under the company account. The workspace owner or admin should control whether matching-domain users are automatically allowed, require approval, or must be invited.

This matters because FlightPlan is not just a solo estimating tool. It is meant to become part of an agency or studio’s operating system.

The MVP can start simple with email/password, magic links, and Google login. The app should still be modeled so SSO can be added without rewriting the product.

Planned authentication requirements:

• Email/password or magic link login
• Google OAuth
• Workspace invites
• Domain-based signup routing
• SAML or OIDC SSO support for higher-tier accounts
• SCIM-ready user provisioning later
• Workspace role mapping
• Seat enforcement at invite and activation time

The product does not need enterprise SSO on day one, but it should have a clear plan for it. SSO can become part of a Studio or Business tier once the product has enough traction with teams.

FlightPlan should use a seat-based pricing model for business accounts.

Example tiers:

• Solo — one user, unlimited personal projects
• Team — up to five seats, shared projects and scopes
• Studio — fifteen seats, custom templates, branded exports, approval workflow
• Business — custom seats, SSO, domain controls, priority support

Licenses should be tied to active workspace membership. Invited users should not consume a paid seat until they accept the invite or become active, depending on the billing preference.

Useful license states:

• Active
• Invited
• Suspended
• Removed
• Domain-eligible
• Pending approval

This allows a business to keep control of who has access without needing manual billing work every time someone joins or leaves.

The output document is the moment where FlightPlan becomes more than a spreadsheet.

A locked scope should render as a polished page with:

• Project name
• Client name
• Scope version
• Summary
• Phase breakdown
• Deliverables
• Estimated hours
• Total cost
• Blended rate
• Optional items
• Assumptions
• Caveats
• Exclusions
• Approval block

The first version can be a branded web page with print styles. PDF generation can come later.

FlightPlan should be a Next.js app with a modular product architecture.

Suggested stack:

• Next.js App Router
• TypeScript
• Supabase Postgres
• Prisma or Drizzle
• TanStack Table for the editable estimating interface
• Stripe for subscriptions and seat billing
• Resend for transactional email
• Inngest for background jobs
• SSO-ready auth through a provider that supports OAuth now and SAML/OIDC later

Important tables:

• users
• workspaces
• workspace_members
• workspace_domains
• workspace_invites
• auth_connections
• plans
• subscriptions
• seats
• projects
• scopes
• scope_versions
• phases
• estimate_items
• roles
• caveats
• comments
• activity_events

FlightPlan is currently in development as part of The Osprey software suite. The first build is focused on the estimate table, scope model, and locked document experience.

I am looking for pilot users who estimate project work manually today and want a cleaner way to move from rough numbers to approved scope.