Skip to main content

Waypoint — Implementation Plan

Version: 1.1 Date: July 2026 (originally drafted March 2026 — see Section 7) Author: Pete Carroll, Founder — Traxs Group LLC Status: In Progress — M0–M5 complete, M6 nearly complete (one blocked item)

1. Overview​

This document defines the implementation sequence for Waypoint v1. The goal is to ship a working, valuable product as quickly as possible while maintaining architectural integrity. We build the foundation first, then layer features on top.

Target: Private beta Q1 2027 · General Availability Q2 2027 Developer: Pete Carroll (solo) Ticket prefix: WAY-NNN (separate Linear project)

Progress note (v1.1): Actual pace has significantly outrun the original week-by-week estimate in Section 4 — M0 through M5, plus three of four M6 tickets, are complete well ahead of the original 10-week mark for that scope. The plan's sequencing and milestone boundaries have held up well; only the calendar estimates were optimistic-to-conservative, not the structure itself.

2. Guiding Principles​

  1. Infrastructure before features — scaffold the full solution, deploy the skeleton, then build features
  2. Vertical slices — each milestone ships a complete working feature end-to-end (API + frontend), not layers in isolation
  3. Executive Dashboard last — it depends on everything else; build the data sources first
  4. RoundTrip integration is an enhancement — every feature works standalone first
  5. Same patterns as RoundTrip — no architectural experiments; consistency over novelty

Held up in practice: Principle 4 was tested directly during M6 — WAY-026 (AR aging) turned out to be the first feature where "works standalone first" isn't a simple toggle. See its entry below and Section 5.

3. Milestones​

Milestone 0 — Infrastructure & Scaffold ✅ Complete​

Target: 1 week Goal: Everything is deployed and running before a single feature is built.

WAY-001 — Solution scaffold ✅​

WAY-002 — Database setup ✅​

WAY-003 — Azure infrastructure ✅​

WAY-004 — Entra setup ✅​

WAY-005 — Frontend scaffold ✅​

WAY-006 — ADO pipelines ✅​

Milestone 0 complete when: A logged-in user sees an empty Waypoint shell at traxswaypoint.app with working auth. — Met.

Milestone 1 — Workspace & Onboarding ✅ Complete​

Target: 1 week Goal: Tenant provisioning, workspace settings, and onboarding flow working.

WAY-007 — Tenant provisioning ✅​

  • Note: the original job's idempotency check only verified the Workspace record existed, not the folder structure — a partial failure between the two SaveChanges calls could have permanently skipped folder seeding on retry. Fixed during M5 (each piece now checks its own existence independently). Also extended to seed default Revenue/Expense categories during M6, using the same pattern.

WAY-008 — Workspace settings ⚠️ Partially complete​

  • Backend (GET/PUT /v1/workspace) fully built and working, including FinancialYearStart.
  • The settings page UI itself was never built despite being listed here — only discovered when M6's P&L overview needed to read FinancialYearStart. A minimal single-field UI (fiscal year start only) was built as a prerequisite for WAY-025. The full form (company name, industry, logo upload, timezone) is still outstanding — tracked as a standalone follow-up so it gets built properly rather than as an afterthought.

WAY-009 — Onboarding flow ✅​

WAY-010 — User management ✅​

Milestone 1 complete when: A new tenant can sign up, complete onboarding, and invite a second user. — Met, with the workspace settings UI gap noted above as a tracked follow-up rather than blocking.

Milestone 2 — HR Lite — Employee Records ✅ Complete​

Target: 2 weeks Goal: Employee records, certifications, and documents working end-to-end.

WAY-011 — Employee CRUD ✅​

WAY-012 — Employee UI ✅​

WAY-013 — Certifications ✅​

WAY-014 — Certification alerts ✅​

WAY-015 — Employee documents ✅​

Milestone 2 complete when: Owner can manage full employee records including certifications with automated expiry alerts. — Met.

Milestone 3 — HR Lite — Leave Management ✅ Complete​

Target: 1 week Goal: Leave requests, PTO tracking, and leave calendar working.

WAY-016 — Leave requests ✅​

  • Also added CancelLeaveRequest beyond the original scope — a reasonable, low-risk addition once building the state machine made the gap obvious.

WAY-017 — PTO management ✅​

  • Manual PTO adjustment is tracked as its own audit-trail entity (PtoAdjustment — hours, reason, who made it, when) rather than a bare balance mutation, and the leave history view unifies leave requests and adjustments into one chronological timeline rather than two separate lists.

Milestone 3 complete when: Owner can manage all employee leave with PTO balance tracking. — Met.

Milestone 4 — Team Management ✅ Complete​

Target: 1 week Goal: Team roster and weekly schedule working.

WAY-018 — Team sync from HR ✅​

  • This ticket surfaced a significant, unplanned gap: Waypoint's domain-event dispatch pipeline (raising an event and having something actually consume it) had never been ported over when the solution was scaffolded in M0 — every domain event since M2 had been silently captured and discarded. Building the event handlers this ticket calls for required first building the entire dispatch mechanism (ported from RoundTrip's SharedKernel), verified end-to-end with a throwaway logging handler before trusting it with real logic.
  • Also added EmployeeUpdatedEvent (keeps the team roster's name/role in sync when an employee record is edited — not in original scope, but the roster would otherwise silently go stale) and a LeaveCancelledEvent handler alongside the planned LeaveApprovedEvent one.
  • Added a drift-detection and self-healing system beyond the original ticket: a banner on the roster page surfaces any employee who failed to sync (with a manual "Sync Now" action), plus a nightly Hangfire job as an automatic safety net. Built after recognizing that dispatch failures are now caught-and-logged rather than propagated (a deliberate choice so a side-effect failure doesn't make the primary action look like it failed) — which meant something needed to actively watch for the resulting drift instead of assuming it away.

WAY-019 — Team UI ✅​

Milestone 4 complete when: Owner sees full team view with leave integrated into the schedule. — Met, on a substantially more solid foundation than originally scoped, since the dispatch pipeline itself now underpins every future domain event in the product.

Milestone 5 — Document Management ✅ Complete​

Target: 2 weeks Goal: Document library and knowledge base working end-to-end.

WAY-020 — Folder management ✅​

  • Known open gap: DeleteFolder's "cannot delete non-empty folder" check currently only verifies there are no subfolders — it does not yet check for documents inside the folder, since DocumentRecord didn't exist until WAY-021 shipped afterward. This was flagged explicitly at the time and has not yet been revisited. Still needs a second condition added to close this gap — as written today, a folder containing documents could be deleted, orphaning their metadata.

WAY-021 — Document library ✅​

  • Includes full version history and soft-delete-with-30-day-purge (a nightly reconciliation job), matching the ticket as written.
  • Move-between-folders was added beyond the original scope, once it became clear there was no way to relocate a document after upload.
  • Office document (docx/xlsx) preview was deliberately scoped out — browsers can't render these natively, and the available workaround (Microsoft's Office Online Viewer) requires transiently sending file content to a third-party service, which wasn't judged an acceptable default for potentially sensitive company documents. Tracked as a follow-up if genuine file-upload-based preview is wanted later.

WAY-022 — Knowledge base ✅​

  • Includes a proper read-only article view (distinct from the editor) — not in the original ticket, but a clear gap once it was obvious staff would want to read guides without being dropped into an editing toolbar.
  • The rich text editor was extended beyond the base ticket with tables, task lists/checkboxes, underline, and highlight — TipTap's free core, not a paid add-on.
  • Inline image support in articles is external-URL-only for now (paste a link), not upload — the same reasoning as the docx/xlsx preview decision: every existing SAS URL pattern in the app is time-limited, and embedding one permanently in stored article HTML would silently break after expiry. Real upload needs a deliberately different (longer-lived or public) storage strategy, tracked as a follow-up.

Milestone 5 complete when: Owner can organize company documents in folders and write knowledge base articles. — Met, with the DeleteFolder gap above as the one real loose end worth closing before it causes a real problem.

Milestone 6 — Financial Overview 🚧 Nearly complete (3 of 4)​

Target: 2 weeks Goal: Revenue tracking, expense entry, P&L, and AR aging working.

Prerequisite, built ahead of the plan's ticket list: admin-managed Revenue and Expense category settings (create/rename/deactivate, seeded with sensible trades-business defaults). Neither the original plan nor the Linear tickets specified where categories came from — building this first, before WAY-023/024, avoided either aggregate referencing placeholder strings.

WAY-023 — Revenue entries ✅​

  • Named RevenueEntry in code (not bare Expense/Revenue) for symmetry with ExpenseEntry.
  • Money value object ported from RoundTrip's existing implementation, adapted to Waypoint's plain-record convention (RoundTrip uses an Ardalis ValueObject base class Waypoint's SharedKernel never adopted).
  • The "RoundTrip import marker" is a reserved Source field (Manual today) — confirmed as scope, not a live integration, before building; no actual RoundTrip data import exists yet.

WAY-024 — Expenses ✅​

  • Named ExpenseEntry for the same symmetry reason as above.
  • Added a Vendor field (mirrors Revenue's Client) — the original ticket had no equivalent "who did you pay" field at all, which read as an oversight given how central that is to real expense tracking.
  • Receipt upload follows the same SAS URL request/confirm pattern established in WAY-021, reusing the existing waypoint-documents container.

WAY-025 — P&L overview ✅​

  • First domain service in the codebase (FinancialSummaryService — gross profit and margin % calculation), first use of Recharts, and first CSV-download response from the API.
  • Correctly respects the tenant's actual FinancialYearStart setting rather than assuming a calendar year — required building the minimal workspace-settings UI slice noted under WAY-008 above as a same-session prerequisite.

WAY-026 — AR aging 🚫 Blocked — not started​

  • Cannot be built before Milestone 7. There is no way to check "is this tenant connected to RoundTrip," or to call the actual Command Center API endpoint, without WAY-027's ICommandCenterClient and Integrations table. This is a genuine sequencing dependency, not a priority deferral.
  • Real scope gap identified: unlike the M7 dashboard widgets that can simply hide themselves when RoundTrip isn't connected (they describe RoundTrip-only concepts with no Waypoint equivalent), AR aging needs some record of outstanding, unpaid invoices to mean anything at all for a non-RoundTrip tenant — and RevenueEntry only tracks revenue already received, not open receivables. A genuine standalone path (per Principle 4 above) requires new domain modeling — likely a Receivable/manual-invoice concept with due dates and paid/unpaid state — not just an empty-state toggle. This needs its own design pass when picked up, not a quick bolt-on alongside WAY-027.

Milestone 6 complete when: Owner can track all revenue and expenses with a clear P&L view. — Effectively met for any tenant not relying on RoundTrip-sourced AR data; WAY-026 remains open, correctly sequenced behind M7 rather than treated as a milestone blocker.

Milestone 7 — Executive Dashboard ⏳ Not started​

Target: 1 week Goal: Dashboard with all widgets working, pulling from all data sources.

WAY-027 — Command Center API integration ⏳​

  • Confirmed: the Command Center API itself is live in production, but none of the specific Waypoint↔RoundTrip integration endpoints this ticket needs exist yet. This ticket explicitly depends on Command Center API Phase 3 (CC-008 to CC-013) landing in that repo first — worth confirming those are actually done before starting, not assuming.
  • This is also where WAY-026 (above) should be picked back up, alongside or immediately after.

WAY-028 — Dashboard assembly ⏳​

WAY-029 — Dashboard UI polish ⏳​

Milestone 7 complete when: Dashboard shows real data from all sources with RoundTrip integration working.

Milestone 8 — Billing & Subscription ⏳ Not started​

Target: 1 week Goal: Stripe integration, plan management, trial expiry working.

WAY-030 — Stripe setup ⏳​

Milestone 8 complete when: Customers can subscribe, upgrade, downgrade, and cancel.

Milestone 9 — Beta Preparation ⏳ Not started​

Target: 1 week Goal: Production-ready for first beta customers.

WAY-031 — Performance review feature ⏳​

WAY-032 — In-app notifications ⏳​

WAY-033 — Beta hardening ⏳​

  • Note: this ticket's testing scope (architecture tests, integration tests) has a standing, already-logged case for being pulled forward rather than left until M9 — several bugs this build (a stale DB default silently overriding domain logic, a missing Dapper type handler, a completely absent domain-event dispatch pipeline) were exactly the class of bug automated tests exist to catch structurally instead of by accident. Worth a deliberate decision on timing when M7/M8 wrap up, rather than defaulting to "M9 as originally planned."

WAY-034 — Suite navigation ⏳​

Milestone 9 complete when: Waypoint is ready for first private beta customers.

4. Timeline Summary​

MilestoneDescriptionOriginal EstimateStatus
M0Infrastructure & Scaffold1 week✅ Complete
M1Workspace & Onboarding1 week✅ Complete (1 tracked follow-up)
M2HR — Employee Records2 weeks✅ Complete
M3HR — Leave Management1 week✅ Complete
M4Team Management1 week✅ Complete
M5Document Management2 weeks✅ Complete (1 open gap)
M6Financial Overview2 weeks🚧 3 of 4 tickets complete; 4th blocked on M7
M7Executive Dashboard1 week⏳ Not started
M8Billing & Subscription1 week⏳ Not started
M9Beta Preparation1 week⏳ Not started

Original estimate: ~13 weeks from start to private beta, targeting November 2026. Actual pace through M0–M6 has run well ahead of this estimate — the milestone sequencing and scope boundaries have held up correctly in practice; only the calendar assumption was conservative. Worth revisiting the November target once M7's real external dependency (Command Center API Phase 3 completion) is confirmed, since that's the one item in the remaining plan not fully within direct control.

5. Dependencies​

DependencyBlocksNotes
Azure infrastructure (M0)EverythingMust be set up first
Entra app registrations (M0)Auth in all milestonesRequired before any auth-gated endpoint works
Employee records (M2)Leave (M3), Team (M4)Team is a projection of Employee
HR completion (M3)Team schedule (M4)Leave data drives team schedule
Domain event dispatch pipeline (built during M4/WAY-018)Every future domain eventDiscovered missing entirely during WAY-018; now a real, verified foundation — not present at scaffold time despite being assumed
Financial categories (built ahead of WAY-023/024)Revenue entries (WAY-023), Expenses (WAY-024)Neither aggregate should reference a placeholder category string
Financial entries (M6)Dashboard (M7)Dashboard revenue widget needs data
Command Center API endpoints (CC-008–CC-013, external repo)Dashboard RT widgets (M7), AR aging (WAY-026, M6)RT data not available until CC API Phase 3 ships — confirmed still pending as of this update
WAY-027 (Integrations table, ICommandCenterClient)WAY-026 (AR aging)Newly identified hard dependency — WAY-026 was originally listed under M6 but cannot be built before this M7 ticket exists

6. What's Not in This Plan​

ItemReason
Mobile appWaypoint is desktop-first — no native app
Org chartsDeferred to v2
Workflow automationDeferred to v2
QuickBooks integrationDeferred to v2
Project portfolio managementDeferred to v2
AI assistantDeferred to v3

7. Document History​

VersionDateAuthorChanges
1.0July 2026Pete CarrollInitial draft
1.1July 2026Pete CarrollUpdated M0–M6 completion status against actual build. Documented WAY-008 (workspace settings UI) and WAY-020 (DeleteFolder document check) as tracked open gaps. Documented WAY-018's unplanned domain-event dispatch pipeline work and resulting drift-detection system. Documented WAY-026's hard dependency on WAY-027 and its real non-RoundTrip scope gap. Added dependency table entries for the dispatch pipeline and the WAY-026/WAY-027 relationship. Revised timeline section from estimate-only to estimate-plus-actual-status.