🎯 Context Separation Guide: Internal vs Customer¶

Executive Summary¶

This guide provides a clear framework for maintaining the critical distinction between:

Our internal reality as a 3-person startup (simple processes)
Our customers' reality as companies with boards (governance needs)

Key Principle: We are a small team building sophisticated features for larger organizations.

The Core Distinction¶

Who We Are vs Who We Build For¶

Aspect	Internal (Us)	Customer (Them)
Organization Size	3 people	10-100+ people
Decision Making	Direct, founder-led	Board oversight, management execution
Approval Layers	Single approval	Multi-stakeholder visibility
Compliance Needs	Basic startup compliance	Regulatory & governance compliance
Stakeholders	Founders only	Directors, executives, staff
Reporting	Simple metrics	Board-ready reports

The Mental Model¶

We (3-person startup) → Build → Features for companies with boards
     ↓                            ↓
Simple processes            Sophisticated capabilities

Common Confusion Patterns¶

1. Scaling Down Features¶

❌ WRONG Thinking: "We're a small startup, so let's build simple features"

✅ RIGHT Thinking: "We're a small startup building enterprise-grade governance features"

2. Over-Complicating Internal Processes¶

❌ WRONG Thinking: "Since we build for boards, we need board-like processes"

✅ RIGHT Thinking: "We keep our processes simple to efficiently build for boards"

Feature Design Examples¶

Audit Logging¶

❌ Under-Scaled (Startup Thinking)

- Basic activity log
- Shows who did what
- Simple timestamp
- Admin view only

✅ Properly Scaled (Board-Ready)

- Comprehensive audit trail
- Role-based access to logs
- Compliance-ready formatting
- Export for board packages
- Retention policies
- Change justification tracking

User Management¶

❌ Under-Scaled (Startup Thinking)

- Admin/User roles
- Simple invite system
- Basic permissions
- Single organization

✅ Properly Scaled (Board-Ready)

- Director/Executive/Manager/Staff roles
- Invitation with approval workflows
- Granular permissions by compliance area
- Multi-tenant architecture
- Delegation capabilities
- Temporary access provisions

Compliance Dashboard¶

❌ Under-Scaled (Startup Thinking)

- Single dashboard for all
- Basic task list
- Simple progress bar
- Manual updates only

✅ Properly Scaled (Board-Ready)

- Role-specific dashboards
- Board overview vs operational detail
- Risk heat maps
- Automated evidence collection
- Trend analysis
- Exception reporting

The Scale Test Questions¶

Before designing any feature, ask:

Stakeholder Test: Can this handle 5-15 board directors plus management team?
Governance Test: Does this provide appropriate oversight without micromanagement?
Compliance Test: Would this satisfy a regulator or auditor?
Liability Test: Does this help directors meet their legal obligations?
Delegation Test: Can work be assigned and escalated appropriately?

If any answer is "No" → Scale up the feature design!

Quick Reference Matrix¶

Feature Area	Startup Version (Don't Build)	Board-Ready Version (Do Build)
Permissions	On/Off access	Role-based with granular controls
Workflows	Linear checklist	Delegation with escalation paths
Reporting	Basic status	Board packages with trends
Audit Trails	Simple log	Compliance-grade with retention
Notifications	Email everyone	Role-based with urgency levels
Data Access	All or nothing	Need-to-know with justification

Implementation Guidelines¶

When Building Features¶

Start with the board perspective: What do directors need to see?
Add management layer: What do executives need to manage?
Include operational level: What do implementers need to do?
Never remove layers: Even in MVP, keep the structure

When Designing Workflows¶

Assume multiple stakeholders: Never design for single-user
Include delegation: Someone's always on vacation
Add escalation paths: Things go wrong, plan for it
Maintain audit trails: Directors have liability

When Writing Documentation¶

Describe who uses it: "Directors can..." not just "Users can..."
Explain governance value: Why boards need this feature
Include scale examples: Show 20-person org using it
Avoid startup examples: Don't show 3-person scenarios

Red Flags to Watch For¶

In Feature Design¶

"This is probably overkill for most users"
"Let's keep it simple for now"
"Do small companies really need this?"
"Seems too enterprise-y"

In Documentation¶

Using our team as the example
Describing single-user workflows
Omitting role descriptions
Simplifying compliance requirements

In Architecture¶

Single-tenant thinking
Flat permission models
No delegation capabilities
Missing audit requirements

The Golden Rule¶

When in doubt, ask: "Would this feature help a board director sleep better at night knowing their governance obligations are met?"

If yes → You're on the right track If no → Scale it up

Conclusion¶

Remember: We're not building GetCimple for companies like us. We're building it for companies that need governance tools. Our superpower is being small enough to move fast while building features large enough to matter.

Our Mantra: Small team, big features, real governance value.