Skip to main content

🗺️ Roadmap

This document describes what gets built next, in what order, and when a phase is considered done.

Purpose: This is your execution contract — the operational sequencing that guides week-to-week work.

Audience: Builders, you week-to-week, anyone asking "what's next?"

Stability: Medium–Low (weeks) — Roadmap changes frequently as priorities shift.

Related: See Strategy for why decisions are made and what kinds of products Constellation enables.

Current State​

Constellation = Springular (same codebase, the boilerplate). CBT Buddy backend is a POC built on Constellation to validate AI capabilities. POC learnings will be ported back to Constellation according to this roadmap.

Infrastructure vs Feature Rule: If a capability exists only as infrastructure (e.g., chat responses in RAG), it belongs in Phase 1 or Deferred Plans. If it's exposed as a reusable, documented service, it belongs in Phase 2+.

Guiding Rules:

  • Every Constellation capability must enable a demoable product in ≤ 14 days, have Stripe checkout, and reuse ≥ 80% existing infrastructure.
  • Constellation grows by shipping narrow products, not by finishing platforms.
  • See Strategy for strategic rationale behind these rules.

TL;DR — If You Build Only One Thing Next​

Port First: Phase 1 Minimal AI Foundation (ChatModel infrastructure from POC)
Why: Stabilize proven POC capabilities before building new features
Time: 1-2 weeks (porting infrastructure, not inventing)

Then Build: Phase 2 Text Operations (rewriting, then generation)
Why: Enables 40-70% of TrustMRR products, lowest complexity, highest reuse value
Time: 2-3 weeks (via fork product)
Example product goal: AI text rewrite tool (see Text Operations Epic for capability definition)

Phase Overview​

PhaseFocusStatusDependencies
Phase 1Minimal AI Foundation⏳ PortingNone
Phase 2Text Operations⏳ PlannedPhase 1
Phase 3Execution Layer⏳ PlannedPhase 2

Status Legend:

  • ✅ Validated in POC = exists in CBT Buddy backend
  • ✅ Implemented in Boilerplate = exists in Springular/Constellation
  • ⏳ Porting = scheduled work
  • ⏳ Planned = planned for future phase
  • ⏳ Deferred = deferred until needed
  • ⏳ Optional = only if products need it

Phase Details​

✅ Phase 1: Minimal AI Foundation (Port from POC)​

Status: Validated in CBT Buddy POC, port minimal infrastructure needed for Phase 2

Purpose: Make AI technically possible and stable (infrastructure, not a feature)

What Phase 1 ports (minimal, just enough for Phase 2):

  • ChatModel bean + Ollama configuration
  • LangChain4j integration (basic wiring)
  • Constants class (AiConstants)
  • Application.yml AI configuration
  • Docker Compose (Ollama service)
  • Chat generation infrastructure (ChatModel wired, works internally)

What Phase 1 does NOT port:

  • ❌ RAG with document ingestion
  • ❌ Embeddings and pgvector
  • ❌ Document/Chunk entities
  • ❌ Vector similarity search

Stop Condition: Phase 1 is complete when ChatModel works, Ollama is configured, and text can be generated internally (infrastructure ready for Phase 2).

Note: This is infrastructure/plumbing, not a productized feature. Phase 2 will build the Text Operations Service on top of this foundation.

🎯 Phase 2: Text Operations (High Priority)​

Position: This is the first-class AI tier of Springular, built after Phase 1 foundation is ported. These features power the majority of real SaaS AI products.

Dependency: Requires Phase 1 (ChatModel infrastructure) to be ported first. Phase 2 builds on Phase 1 foundation to create a productized Text Operations Service.

Capabilities (in priority order):

  1. Text Rewriting (anchor primitive) — Transform existing text (humanize, tone adjustment, summarize)
  2. Text Generation (extension of rewriting) — Create new text from prompts
  3. Structured Data Extraction — Entity extraction, document parsing, form data extraction
  4. Moderation & Safety — Content moderation, toxicity detection

Why Phase 2 Matters:

  • ✅ Cheap to run (can use local Ollama)
  • ✅ Easy to reason about and test
  • ✅ Powers ~70% of TrustMRR AI products (validated with real MRR data)
  • ✅ Most Indie/YC products monetize here
  • ✅ Covers top 3 recurring features from TrustMRR analysis

Approach: Provide reference implementations, not dozens of endpoints. Focus on configuration and examples.

Scope Guard: ⚠️ Text Operations primitives must enable at least one shippable product (via fork) within 14 days of completion. This prevents infrastructure drift.

Stop Condition: Phase 2 is complete when rewriting + generation work AND at least one fork product validates them. No further capabilities until a fork product validates the need.

TrustMRR Validation: These primitives enable products making $40k–$250k MRR. See Strategy and Business Patterns for details.

Note: Products are built in forks, not in Constellation. Constellation provides the primitives; forks choose subsets and build products.

🔧 Phase 3: Execution Layer (Background Jobs & Automation)​

Status: High priority after Phase 2. Enables automation products.

Purpose: Provide background job infrastructure for scheduling and automation

What Phase 3 adds:

  • Background job system (Spring @Async, @Scheduled)
  • Task scheduling patterns
  • Retry logic and error handling
  • Event triggers (optional, lightweight)
  • Integration hooks for external job queues (if needed)

Stop Condition: Phase 3 is complete when background jobs work, scheduling patterns are documented, and at least one fork product uses them for automation.

Note: This enables marketing automation, social media schedulers, and other automation products. Combines with Phase 2 (Text Operations) for high-value products.

Rationale: Most successful YC startups doing automation have custom logic, not generic frameworks. Springular provides the infrastructure (jobs, events, hooks), products build their own intelligence on top.

Dependencies​

Phase 1 (Foundation)
  ↓
Phase 2 (Text Operations)
  ↓
Phase 3 (Execution Layer)

Success Metrics by Phase​

Phase 1 Success Criteria​

  • ✅ ChatModel bean configured and working
  • ✅ Ollama service running in Docker Compose
  • ✅ Text generation works internally (infrastructure ready)

Phase 2 Success Criteria​

  • ✅ Text rewriting (anchor primitive) implemented
  • ✅ Text generation (extension) implemented
  • ✅ Fork product validates capability (built and shipped)
  • ✅ Capability proven reusable (ready for more fork products)

Phase 3 Success Criteria​

  • ✅ Execution Layer primitives implemented
  • ✅ Fork products validate capability (automation products using jobs/scheduling)
  • ✅ Capability proven reusable (patterns documented)

Near-Term Focus​

Current Priority: Phase 1 → Phase 2 → Phase 3 (linear sequence)

Next Steps:

  1. Port Phase 1 infrastructure — ChatModel + Ollama config from POC (minimal foundation)
  2. Build Phase 2 Text Operations Service — Rewriting first (anchor), then Generation (extension)
  3. Validate via fork — Build product in fork to validate capability
  4. Build Phase 3 Execution Layer — Background jobs, scheduling patterns
  5. Add remaining primitives — Structured Extraction, Moderation (as needed)

Deferred Plans​

Deferred Plan 1: Full RAG/Embeddings Foundation — Deferred until products actually need RAG. Phase 2 does not require it.

  • pgvector setup & migrations (V4-V6)
  • Document + Chunk entities
  • Embedding service
  • Vector similarity search
  • RAG pipeline (ingest, retrieve, chat)
  • Document ingestion pipeline
  • Status: Validated in CBT Buddy POC, port when products require RAG capabilities
  • Note: This can be ported later when a product actually needs RAG. Phase 2 (Text Operations) does not require it.

Deferred Plan 2: Media Integration Hooks — Deferred until Phase 2 revenue exists. Only build if products need it.

  • Integration hooks for image generation APIs (OpenAI DALL·E, Stable Diffusion via Replicate)
  • Integration hooks for video generation APIs (Runway, Synthesia)
  • No core media generation — external APIs only
  • Documented integration patterns
  • Status: Truly optional. Most products don't need media generation.
  • Note: Only build if a fork product requires it.

Additional Text Operations Primitives: Summarization, translation, sentiment, classification — add as needed when fork products require them.

References​