Business goals, technical build plan, and RunOS platform roadmap. Progress syncs to Firestore and shows on the home dashboard.
Practice vision
Limicelia is an organizational accompaniment practice — not a consultancy. We come in, learn what's actually present with the people doing the work, and stay through the change. The business goal is to grow a sustainable two-practitioner boutique while building RunOS as a second revenue line that encodes our consulting IP into reusable infrastructure.
2026 Business Goals
Revenue
$120–160K gross
4–6 active engagements at any time. Mix of Discovery ($6–12K), Transformation ($18–40K), and Long Arc ($3.5–6K/mo). Target: 2 Long Arc + 2 Transformation running simultaneously by Q3.
Break-even (BK + Carol): ~$95K/yr
Client Acquisition
12 paid engagements
8 new + 4 repeat/extension. Conversion target: 1 in 4 discovery conversations → proposal. 1 in 3 proposals → active. Bay Area + DC as primary markets.
Pipeline target: 20+ active contacts
Case Studies
3 documented case studies
PSFG and CFL are the two we have. Need one more from 2026 work. Each case study enables a new category of outreach. Target: one per service domain (Conflict, Leadership, Org Design).
Using lineage page + AI synthesis
Service Positioning
3 settled service domains
Conflict Navigation (settled), Org Conditions & Governance (settled), and one of: Relational Vitality or Systems Convening. Decision depends on discovery data from Q1–Q2 conversations.
Website update trigger: 20+ conversations
RunOS
1 white-label pilot
One non-Limicelia org running on a branded instance of the portal. Implementation fee: $3–8K. Goal is validation of the product concept, not revenue. Target: a peer firm or field-building org we already have a relationship with.
Unblocked by: Phase 1 Identity Layer
Practice Infrastructure
Portal as operational backbone
Every client engagement flows through the portal: pipeline tracked, proposal drafted, SOW generated, sessions debriefed, outcomes documented. Goal: zero client activity outside the portal by Q2.
Current: ~60% of activity tracked
Business Milestones
Q2 2026
Proposal + discovery rhythm established
Consistent cadence of 2–3 discovery conversations per week. Post-interview process running within 30 min. First proposals sent via portal proposal builder. Rate card finalized.
Now
Q3 2026
2 Long Arc clients + 1 Transformation active
Enough recurring revenue to sustain both BK and Carol at full capacity. Colmenar partnership scoped for Conflict Navigation engagements. First repeat client (PSFG or CFL) in a new arc.
Target
Q3 2026
PSFG + CFL case studies documented + shareable
Both case studies written, reviewed, approved for use in proposals. Format decided: 1-page PDF + portal lineage entry with testimonial. One new 2026 case study in progress.
Target
Q4 2026
First RunOS white-label pilot live
One peer org running on a branded portal instance. Logo, color, terminology configured. Feedback loop established. Informed Phase 2 wizard scope.
RunOS
Q1 2027
Service domain decision made
Based on discovery data: 3 settled service domains named, website updated, outreach templates tuned to sector. Wenger-Trayner attribution resolved for Systems Convening.
Target
2027
RunOS: 3 paying orgs + first SaaS revenue
Multi-tenant infrastructure live. 3 orgs on recurring subscriptions ($300–800/mo each). First template published. RunOS revenue covers portal infrastructure costs.
RunOS
Framework Evaluation — Recommendations
Current state
Recommendation
Service architecture
5 service domains, Settled/Forming/Tending status. Contested: too many vs. sharper positioning.
→ Narrow to 3 for outreach, keep 5 internally
Lead with 3 domains in all external materials. Use discovery data to decide which 3 by Q3. Keep all 5 internally for matching + tracking — the portal supports this already.
Client development arc
Discovery → Proposal → Active → Won. Proposal goes out 24hr after strong fit determination.
→ Add pre-proposal step for complex orgs
For multi-stakeholder orgs: insert a "Shared framing call" between discovery and proposal. Reduces proposal rewrites. Already in the onboarding process doc — make it a pipeline stage.
Lineage + knowledge capture
41 clients in lineage page. Most undocumented. PSFG + CFL are the only case studies.
→ Close the loop from pipeline → lineage
When a pipeline engagement moves to "Won/Closed," auto-suggest creating a lineage entry. Add lineageId field to pipeline docs. This creates the link from active work → institutional memory automatically.
Advisor Circle use
Advisor portal exists with asks/responses. Jutta + Richard are named advisors. Usage pattern unclear.
→ Structured quarterly review ritual
Use the Advisor portal for a structured quarterly: post 3 open questions, share lineage patterns synthesis output, request one introduction. Turns the portal from a passive tool into an active relationship.
RunOS vs Limicelia blending
RunOS roadmap lives inside the Limicelia portal. Product identity and consulting identity are blended.
→ Separate repo when Phase 2 starts
Keep Limicelia-specific features in limi-hq. At Phase 2 (Config Wizard), fork RunOS into its own repo (runosportal.com). Limicelia's portal becomes one deployment of RunOS. See repo bootstrap below.
LC practice roadmap
This tab tracks Limicelia-specific work — service architecture, positioning, and portal features for the LC instance. Separate from the RunOS product roadmap. Check items off as they ship. All open items are available for any agent to pick up (see CLAUDE.md for setup).
Practice + portal build — check items off as they ship
Custom roadmap items
Technical philosophy
No bundler. No framework. Vanilla JS ES modules + Firebase + Cloudflare Workers. Every dependency is a CDN URL, not a local install. The constraint is deliberate: the product must be deployable from a single HTML file. This is what makes it fast to build, fast to deploy, and easy to hand to another org.
Portal build phases — check items off as they ship
Revenue model by phase
Phase
Interface
Type
Range
Phase 1–1.5
Portal
Implementation fee
$3–8K per org
Phase 2
Portal
Implementation fee (self-serve)
$1–3K per org
Phase 3
Portal
SaaS subscription
$300–800/mo per org
Phase 4
Portal
Template licensing
$500–2K per template
Future
Intelligence Layer
Consulting + platform
TBD — high
Interface 2 — Future
The Intelligence Layer: org world model, ambient session capture, DRI-aware AI, relational graph. Built from consulting work already being done inside these transitions.
Directional signal
Block's public account of replacing hierarchical coordination with an AI-maintained world model names what is happening to organizational structure across sectors. Three roles replace the traditional pyramid: individual contributors, DRIs, and player-coaches. The information-routing function of middle management is being retired — not by policy, but by the emergence of systems that can hold and route organizational knowledge without human relay.
This is not a distant future. Haier eliminated 12,000 middle managers in 2005. Block is attempting it in 2026 with AI infrastructure. The question is not whether this transition is coming — it is whether organizations navigate it consciously or reactively. That is Limicelia's terrain. And it is RunOS's next interface.
Intelligence Layer
Future Interface — Directional, Not Scheduled
"From Hierarchy to Intelligence" — Dorsey & Botha, March 2026
▶
Org world model — Firestore as structured substrate of org knowledge: decisions, commitments, relationships, context.
DRI-aware AI — AI chat and task assignment that understands who is responsible for what, surfaces conflicts, flags when responsibility is unclear
Ambient session capture — meeting notes, decisions, next steps captured without deliberate entry; surfaced back into the world model automatically
Relational graph — who has worked with whom, on what, with what outcome; relationship history as organizational infrastructure
Succession and knowledge transfer layer — when someone leaves, the world model holds what they knew; the org doesn't start over
Player-coach interface — role-type-aware view for people building and developing others simultaneously, without traditional management structure
RunOS as a product
RunOS is the operating system for professional services organizations navigating structural change. It has two interfaces — the Portal (building now) and the Intelligence Layer (future). As a product it needs its own repo, deployment pipeline, and brand identity separate from Limicelia. Limicelia's instance becomes one deployment of RunOS. The consulting practice is both the first customer and the proof of concept.
Layer 2 — Language skin (Phase 1.5): Vocabulary map — every label, stage name, service domain, nav item, and AI response uses the org's terminology. Stored in /settings/vocabulary, injected into every AI prompt automatically.
Layer 3 — Behavioral skin (Phase 2): AI persona per org — system prompt shaped to their sector, values, and language. This layer encodes Limicelia's consulting IP into the product and is the hardest to replicate.
New repo bootstrap — when to fork + how
When: At the start of Phase 2 (Config Wizard). At that point limi-hq becomes one deployment of RunOS. The fork creates the product repo while keeping the Limicelia instance working.
# 1. Create RunOS repo on GitHub (via gh CLI or GitHub UI)gh repo create meldfunction/runosportal --private --description "RunOS — operational OS for professional services orgs"# 2. Copy current portal as the RunOS basecp -r /Users/bk/Documents/GitHub/limi-hq /Users/bk/Documents/GitHub/runosportalcd /Users/bk/Documents/GitHub/runosportalgit init && git remote add origin git@github.com:meldfunction/runosportal.git# 3. Strip Limicelia-specific content, add org config system# - Replace hardcoded "Limicelia" strings with org config lookups# - Move CLIENTS array out of lineage page → /settings/clients in Firestore# - Move service domains → /settings/domains# - Add /settings/org, /settings/vocabulary, /settings/modules# 4. New Firestore project for RunOS (separate from data-load-195219)firebase projects:create runosportal --display-name "RunOS Portal"firebase use runosportalfirebase deploy --only firestore:rules# 5. New Cloudflare Workercd /Users/bk/Documents/GitHub/runosportal# Edit wrangler.jsonc: name = "runosportal", routes = runosportal.com/*wrangler deploy# 6. Limicelia instance: limi-hq stays as-is, points to data-load-195219# Both repos share the same codebase but different firebase-config.js
Key principle: firebase-config.js is the only file that differs between deployments. Org-specific content (name, logo, vocabulary, modules) lives in Firestore, not in the code. This is what makes white-labeling zero-code.
Future integrations
Stripe
Phase 3
Subscription billing per org. Module access gated by plan tier. Invoice generation. Connects to Finance view for AR tracking.
Resend
Phase 2
Weekly digest email per org. Transactional emails (invite, proposal sent, debrief reminder). CF Worker cron triggers. Org's own sender domain.
Surface upcoming client sessions on dashboard. Auto-create session log entries from calendar events. Meeting prep brief generated before each call.
Zapier / Make
Phase 4
Automation hooks for any event in RunOS (new pipeline entry, proposal sent, session logged). Lets orgs connect to their existing toolstack without custom code.
DocuSign / HelloSign
Phase 3
SOW e-signature flow from within the portal. Contract status updates back to pipeline. Signed PDF stored in Drive and linked to engagement.
Loom / Fireflies
Phase 4
Meeting recording transcripts → session debrief auto-population. Ambient session capture. The beginning of the Intelligence Layer ingestion pipeline.
Notion / Coda
Phase 4
Import existing org knowledge bases as context for AI. Deliverable output can be written directly to Notion pages. Transition path for orgs migrating from Notion workflows.
Linear / GitHub
Phase 4
For orgs that build software: kanban board syncs with Linear/GitHub issues. Delivery pods map to engineering teams. For Limicelia: RunOS development itself.
OpenAI / Anthropic
Now
Already routed through doc-processor Worker. Future: org brings their own API key. Model selection per org. Fine-tuned models for sector-specific AI personas.
Calendly / Cal.com
Phase 3
Discovery call scheduling linked to CRM contacts. New booking → auto-creates pipeline entry + pre-call brief. Reduces manual entry after every discovery conversation.
QuickBooks / FreshBooks
Phase 4
Invoice sync from RunOS Finance view. P&L data pulled for BizModel view. For orgs replacing separate accounting tools with RunOS Finance as primary.
Positioning vs alternatives
Tool
What it does
RunOS difference
HubSpot / Salesforce
CRM + pipeline for sales orgs
Built for relationship-driven work, not transactional sales. No velocity metrics. AI understands accompaniment, not conversion.
Notion / Coda
Flexible workspace + docs
RunOS is opinionated. It has a model of how practice-based orgs work. Notion has no model — it's infrastructure for any model.
Monday / Asana
Task and project management
RunOS integrates pipeline, sessions, proposals, and board in one model. No context-switching between "client work" and "internal work".
Copper / Pipedrive
CRM for service businesses
Designed for B2B sales. RunOS is designed for accompaniment: long arcs, relational complexity, multi-stakeholder engagements.
Practice Better / Jane
Practice management (health)
Sector-specific. RunOS is sector-configurable via Language + Behavioral skin. Not locked to one practice type.
What the demo environment is
A private, seeded RunOS instance with fake org data — showing all modules working, skinned as a different organization. No real client info. Used for prospect walkthroughs, setup guide testing, and onboarding new white-label clients. Hosted separately from limi-hq. Backed by its own Firestore project and Cloudflare Worker.
Live demo environment
RunOS — Clearwater Consulting (demo org)
A fully seeded portal skinned as a fictional management consulting firm. Pipeline, sessions, proposals, AI chat — all populated with demo data. Walk a prospect through it in 10 minutes.
Demo — Coming Soon
What the demo covers
Layer 1 — Visual skin
Branded as Clearwater
Custom logo, brand color (#2B5F8E — navy), org name in topbar and page titles. Demonstrates Phase 1 white-labeling in 30 seconds.
Layer 2 — Language skin
Clearwater vocabulary
Pipeline → Engagements. Sessions → Client Meetings. Contacts → Clients. Nav labels and stage names all use Clearwater's terminology.
Layer 3 — Behavioral skin
AI speaks their language
AI chat is primed with Clearwater's sector context (management consulting), voice, and common presenting problems. Responds in their register.
Populated data
Realistic, not empty
5 fake engagements in various stages. 8 contacts. 3 session logs. 2 proposals (draft + sent). 1 signed SOW. Kanban with active sprint items.
Setup guide
How to deploy your own
Step-by-step: fork the repo, connect Firebase, connect Cloudflare, run setup wizard. Estimated time: 45 minutes for a technical user.
Private repo
meldfunction/runosportal-demo
Seeded data scripts, setup guide, wrangler config template, firebase rules. Starting point for each new white-label deployment.
Deploying a new RunOS instance — setup guide
01
Fork the repo
~5 min · Requires GitHub access
# Fork runosportal-demo on GitHub, then clone locallygh repo fork meldfunction/runosportal-demo --clone --remotecd runosportal-demo# Rename for the new orggh repo rename acme-portal
02
Create Firebase project
~10 min · Requires GCP account
Create a new Firebase project at console.firebase.google.com. Enable Firestore (us-east1), enable Authentication, add Google Sign-In provider. Add the new org's Google accounts as authorized users.
# Get your project ID from Firebase console, then:firebase use --add# Select your new projectfirebase deploy --only firestore:rules# Edit firebase-config.js — replace all values with new project's config# (Get config from Firebase console → Project Settings → Your apps → Web)
03
Set superadmin claims
~5 min · Requires service account key
Download a service account key from Firebase console → Project Settings → Service accounts. Place as scripts/service-account.json (gitignored). Run the claims script to make the org admin a superadmin.
cd scripts && npm install# Edit set-claims.js — replace BK/Carol emails with new org admin emailsnode set-claims.js# Admin must sign out and back in for claims to take effect
04
Deploy to Cloudflare
~10 min · Requires Cloudflare account
Log in to Cloudflare. Edit wrangler.jsonc: update the worker name and route to the org's domain. Then deploy.
Sign in as superadmin. Go to Settings → Org to set org name, upload logo, set brand color. Go to Settings → Vocabulary to configure terminology. The portal reflects changes immediately — no redeploy needed.
06
Invite team members
~2 min per person · In the portal UI
Go to Users → Invite. Enter team member email. They'll receive an invite link, sign in with Google, and land in the onboarding wizard. Role assignment is done from the Users view.
What goes in meldfunction/runosportal-demo
File / folder
Purpose
README.md
Setup guide (mirrors steps above). Target audience: technical person standing up a new deployment.
firebase-config.js
Template with placeholder values. Only file that changes per deployment.
wrangler.jsonc
Template with placeholder worker name and route. Edit for each deployment.
scripts/seed-demo.js
Seeds Firestore with Clearwater demo data: 5 pipeline entries, 8 contacts, 3 sessions, 2 proposals, org settings. Run once after Firebase setup.
scripts/set-claims.js
Sets superadmin custom claims. Edit email addresses before running.
scripts/seed-clearwater.json
Demo org settings: Clearwater name, navy color, vocabulary map, pipeline stages, AI persona prompt. Import to Firestore /settings.
Current status: Repo scaffold in progress. The demo page (runosportal-demo.html) in this portal is the visual walkthrough — it doesn't require auth and shows RunOS skinned as Clearwater Consulting. The live demo environment (separate Firebase project + Cloudflare Worker) is the next infrastructure task after the repo is set up.
Portal simplicity stories
18 epics, ~100 stories organized by tier. Each story is independently completable by any agent. Tier 1 (Foundation) must ship first — other tiers depend on it. Progress syncs to Firestore alongside the other roadmap tabs.