sscoble/speckl
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions
speckl/docs/business-brief.md

9.9 KiB
Raw Blame History

Speckl — Business Brief & Strategy

Prepared by @cos for Scott Scoble Date: 2026-04-28

1. What Speckl Is (The Asset)

Speckl is a multi-agent software development system where the primary artifact is the specification ("Speck"), not code. It inverts the classic dev workflow:

Traditional: Requirements → Code → Tests → Ship → (provenance? who knows) Speckl: Speck (formal spec) → Prove (Z3/DST verification) → Generate (WASM artifacts) → Ship with full dark provenance

The core ideas:

  • Speck / SpeckDL — Domain-specific languages for defining system behavior and interfaces. Humans review these directly. Deterministic compilation to Z3 (SMT solver), DST (decision structures), and WASM.
  • Dark Provenance — Every behavior is traced back to its original source (academic paper, spec decision, regulatory requirement), forming an auditable graph. The "dark" = you don't have to think about it until you need it.
  • Tiered Agent Architecture — Orchestrator (client entry) → Team Leads (manage SMEs) → SMEs (hyper-specialized single-task agents). Self-replicating teams scale dynamically.
  • TillDone — Condition-based task tracking. Tasks don't tick boxes; they evaluate predicates. "Done" means a proven condition is met.
  • SA-11 Compliance — The Speck review boundary aims to meet stringent software assurance requirements (DO-178C, IEC 62304, etc.) by proving semantic preservation during compilation.

2. Positioning Options (Multiple Business Plans)

I see four distinct product/business models Speckl could become. Each targets a different market and revenue profile.

Plan A: Speckl as Developer Tool (SaaS/PLG)

Tagline: "Spec once. Prove everywhere. Ship with provenance."

What it is: A hosted platform where dev teams write Speck specifications, the system verifies them via Z3/DST, generates code/WASM, and maintains the full dark provenance graph. Think of it as a spec-first CI/CD pipeline.

Target Market:

  • Regulated industries: aerospace (DO-178C), medical devices (IEC 62304), automotive (ISO 26262), fintech (SOC 2)
  • Teams that want to be audit-ready even if not yet regulated
  • Enterprise dev teams tired of "code first, document never"

Revenue Model:

  • Freemium: 3 specs/month, public provenance graph
  • Team: $99/seat/mo, unlimited specs, private provenance
  • Enterprise: Custom (on-prem, air-gapped, SLA, compliance cert packs)
  • TAM estimate: ~$500M in regulated-dev-tooling alone

Go-To-Market:

  1. Open-source SpeckDL language → build community
  2. Target "I hate writing docs but need compliance" dev advocate accounts
  3. Partner with DO-178C consultancies and regulatory auditors
  4. White paper: "The Compliance-First Development Pipeline"

Pros: PLG scales, developer credibility, clear ROI (audit cost reduction) Cons: Long enterprise sales cycles, regulatory expertise needed, open-core risk

Plan B: Speckl as Compliance Infrastructure (API/Platform)

Tagline: "Don't document your code. Trace your intent."

What it is: Not a frontend tool — a provenance engine that plugs into existing CI/CD. You feed it specs, code, and decisions; it maintains the dark provenance graph and produces audit-ready reports, compliance evidence bundles, and traceability matrices.

Target Market:

  • Same regulated industries as Plan A, but sold to compliance/QA departments (not devs)
  • Large enterprises with existing toolchains that need a provenance layer
  • Government contractors

Revenue Model:

  • API usage: $0.01/provenance-edge-month (per connection in the graph)
  • Compliance report packs: $500/report
  • Enterprise license: $50k+/yr for unlimited provenance
  • TAM: ~$200M (smaller but higher-margin, sticky)

Go-To-Market:

  1. Build compliance export connectors (DO-178C, IEC 62304, SOC 2, FedRAMP)
  2. Sell to compliance officers, not devs — different pitch
  3. Publish "Dark Provenance: A Methodology" as a standards paper
  4. Target companies facing audits in the next 12 months

Pros: High margins, sticky (compliance data is a moat), not dev-fickleness-dependent Cons: Longer sales cycle than SaaS, need compliance expertise in house

Plan C: Speckl as Service (Consulting + Custom)

Tagline: "We'll build your audit-proof system. You own the provenance."

What it is: A services business where Scobleclaw (or a Speckl team) works with clients to spec out critical systems using SpeckDL, set up the agent harness, and train their teams on dark provenance workflows. Delivers working systems + full compliance traceability.

Target Market:

  • Mid-market companies needing a single regulated system (not a platform)
  • Startups in health-tech, aviation-tech, or fintech that need compliance from day 1
  • Companies that want to adopt the methodology but lack internal expertise

Revenue Model:

  • Engagement: $25k–$150k per system, depending on complexity
  • Retainer: $5k–$15k/mo for ongoing provenance maintenance
  • Training: $3k/team for Speckl methodology workshop

Pros: High per-customer revenue, builds case studies for Plan A/B, less R&D-heavy Cons: Not scalable (services business), requires talent, competitive with existing systems integrators

Plan D: Speckl as Open Standard + Foundation

Tagline: "The specification-first standard for auditable systems."

What it is: SpeckDL becomes an open standard. Dark Provenance becomes a known methodology. Speckl the company becomes the steward — like Rust Foundation or CNCF. Revenue comes from certifications, tooling, and enterprise support.

Target Market:

  • Broader: any team writing safety-critical or audit-sensitive software
  • Standards bodies (SAE, IEEE, FDA guidance working groups)
  • Open-source community

Revenue Model:

  • Speckl certification: $5k/team for "Speckl Certified" training
  • Speckl tooling: commercial IDE plugins, CI integrations
  • Speckl conferences / workshops
  • Grants from safety-critical software foundations

Go-To-Market:

  1. Open-source SpeckDL under Apache 2.0
  2. Publish the Dark Provenance methodology paper
  3. Build reference implementations
  4. Seek standards-body adoption

Pros: Maximum reach, community-driven, positions Scott as thought leader Cons: Hard to monetize directly, requires community management, slow growth

3. Recommended Strategy: Multi-Phase Rollout

I'd recommend a hybrid approach — not picking one plan, but sequencing them:

Phase 1 (Now → 3 months): Speckl as Open Standard + Consulting

  • Open-source SpeckDL to validate the concept and attract contributors
  • Run 1–2 paid consulting engagements with health-tech or fintech companies to prove the methodology in the real world
  • Build the case studies needed for Phase 2
  • Cost: Low (time + hosting)
  • Revenue: $25k–$150k per engagement

Phase 2 (3 → 9 months): Speckl as Developer Tool (SaaS)

  • Launch Speckl SaaS based on learnings from consulting
  • Target the most painful regulated-industry pain point (DO-178C documentation is notoriously expensive)
  • Free tier for open-source projects to build community
  • Cost: Moderate (SaaS infra, compliance certifications)
  • Revenue: $99/seat/mo target

Phase 3 (9 → 18 months): Speckl as Compliance Infrastructure

  • Once you have provenance graph data from real users, pivot the compliance export connectors into a standalone API product
  • Now you have both a frontend tool AND a backend compliance engine
  • Cost: Low (extension of existing infra)
  • Revenue: $50k+/yr enterprise licenses

4. Key Business Questions to Decide

To move forward, we need answers on:

  1. Ownership structure — Is Speckl a Scobleclaw property? A separate LLC? Your personal IP?
  2. Investment — Bootstrapped (your time) or do you want to raise? Speckl is fundable as a devtool/compliance play.
  3. Role — Are you the CEO/founder, or do you want to hand this off to someone else to run?
  4. IP status — What currently exists? Code, docs, designs? Is it in a repo?
  5. First customer — Do you already have a target? A regulated company you know?

5. Immediate Next Steps (If You Want to Proceed)

  1. Fork the speckl concept into its own repo under your Forgejo (sscoble/speckl)
  2. Open source SpeckDL — the DSL is the wedge
  3. Publish the Dark Provenance methodology as a whitepaper (positioning content)
  4. Identify first consulting target — a startup building a regulated system
  5. Decide ownership structure — I'd recommend a separate Forgejo org (scobleclaw/speckl) with you as owner

6. Risk Analysis

Risk Likelihood Mitigation
Market not ready for spec-first dev Medium Start with compliance pain (already exists)
SpeckDL too niche/weird to adopt Medium Open source + make it compile to widely-used formats
Regulatory expertise barrier High Partner with compliance consultancies
LLM agent harness unreliable Medium Use Speckl tiered architecture with human-in-the-loop
"Dark Provenance" sounds sinister Low Rebrand to "Provenance Graph" or "Intent Trace" in marketing
Competition from existing formal methods (TLA+, Alloy, etc.) Medium Speckl wraps these — doesn't compete — plus agent harness is the differentiator

7. Branding & Positioning Notes

Name: Speckl is strong — memorable, distinctive, implies "spec" + "tickle" (it makes you think about specs). Keep it.

Domain ideas: speckl.dev, speckl.ai, getspeckl.com

Logo concept: A small grain/speck that radiates a tracing network — representing the provenance graph growing from a single spec.

Positioning sentence: "Speckl is a spec-first development system that traces every line of behavior back to its origin — so you can prove your system does what you intended, and only what you intended."

End of brief. For any of these plans, I can dispatch @engineering for a repo setup, @market for competitive analysis, or @trust for compliance research. Just say the word.