Skip to content

Deckly Internal DocsSystem map, implementation notes, and release history.

Use this as the fastest route into architecture, development, data rooms, roadmap, and recent changes.

Deckly logo

Read This First

If you are trying to change the app, use this order:

  1. Architecture for the system shape.
  2. Development for working conventions and file ownership.
  3. Data Rooms for the room-specific data model and flows.
  4. Roadmap for active work and sequencing.
  5. Changelog for recent changes and context.

Quick Code Anchors

These are the files to reach for first when the docs mention a behavior:

AreaPrimary files
Routing and shared linkssrc/utils/url.ts, src/pages/LegacyRedirect.tsx
Deck processingsrc/pages/ManageDeck.tsx, src/workflows/deckProcessing.ts, src/services/deckStorageService.ts
Analytics and signalssrc/services/analyticsService.ts, src/services/interestSignalService.ts
Session and authsrc/contexts/AuthContext.tsx, src/services/authSession.ts, src/services/userService.ts
Navigation and layoutsrc/components/layout/Sidebar.tsx, src/components/layout/BottomNav.tsx, src/components/layout/DashboardLayout.tsx

System Flow

mermaid
flowchart TD
    A[Docs Home] --> B[Architecture]
    A --> C[Development]
    A --> D[Data Rooms]
    A --> E[Roadmap]
    C --> F[Source files]
    B --> F
    D --> F
    E --> G[Changelog]

Reading Guide

Each page should answer a different question:

  • index.md: Where do I start?
  • ARCHITECTURE.md: How does the system work?
  • DEVELOPMENT.md: How do I safely change it?
  • DATA_ROOMS.md: How do room flows and data models fit together?
  • ROADMAP.md: What is next and what is blocked?
  • CHANGELOG.md: What changed recently?

Recent Focus

The docs are strongest when they stay tied to the codebase. When you update a behavior, pair the doc with the owning file path and the related flow so the next engineer can move from context to implementation without hunting.

Built with ❤️ for Founders