Blueprints
Turn repository work into a plan people can follow.
Blueprints is a local-first planning app for projects where repository work, releases, and release notes start drifting apart.
Most of that system is now built. Development is paused before release because the product expanded beyond its original focus and needs a clearer identity, audience, and core workflow.
Current state
Near the end of development, paused for a product rethink.
Most of the planned desktop system now works: project setup, release boards, reviewed repository imports, changelog export, signed sharing, trust checks, and recovery-aware project state. During development, however, Blueprints grew beyond its original release-planning focus and lost some of its product identity. Work is paused while its audience, central workflow, information architecture, and boundary between planning and release tooling are reconsidered.
- Plan-first release board
- Git and hosted-source import
- Signed sharing
- Safe project removal
- Changelog export
- Clarify the core user and job
- Reduce competing workflows
- Rework the information architecture
- Confirm the release scope
- Finish packaged distribution
Release flow
Discover, review, shape, then ship.
Blueprints reads existing project signals, keeps every import reviewable, maps work to detected releases, and generates notes from the signed plan rather than memory.
- 01Connect a repository or start manually
- 02Review discovered work and detected releases
- 03Shape progress on the planning board
- 04Review readiness, release, and export notes
System principles
- The plan stays central.
- Local-first by default.
- Nothing is imported without review.
- Each item belongs to one version.
- Item keys are generated automatically.
- Release is a signed action.
- Released versions are immutable in v1.0.
Architecture
- App holds the Avalonia shell.
- Core holds the planning models.
- Security handles signatures and trust.
- Storage handles canonical JSON and signed files.
- Collaboration holds the sync side.
Storage and trust
- Canonical JSON is used for signing.
- Each signed document writes a matching .sig file.
- Trust state is tracked per document.
- Shared changes are validated before they replace local signed state.
Local-first collaboration
Your plan stays local until you deliberately share it.
- 01Each user works from a local workspace.
- 02Changes are pulled, verified, and merged locally.
- 03Push writes signed changes to shared project state.
Who it is for
Release clarity without another hosted dashboard.
- Solo developers shipping versioned products
- Small teams that need release discipline without a hosted SaaS stack
- Projects that care about auditability, trust, and cleaner changelog structure