Building a Living Framework: Mermaid Tails Dog Retreat
A build in public example of designing an operating system from first principles.
Introduction
This page documents the development of a business operating system in practice — how a system is constructed from first principles, tested through real-world use, and refined over time.
Mermaid Tails Dog Retreat is an early-stage business. The operating system did not exist prior to this work.
Rather than optimizing an existing structure, the process involves building the system itself — translating a founder’s philosophy into decision logic, operational processes, and experience design.
This build reflects the Living Frameworks method applied to operational systems.
The approach applies same method used across Living Frameworks: structure is not imposed upfront, but developed through interaction, constraint, and feedback.
How to Read This Build
This work reflects an active system build.
Components are being designed, tested, and refined in parallel. Not all elements are complete, and some will change as the system is applied.
What matters is not any single component, but how the system evolves — how values, decisions, and operations become aligned over time.
System Context
Early-stage businesses often begin with strong founder intent but limited operational structure.
This creates a common failure mode:
decisions are made inconsistently
execution varies across contexts
customer experience becomes fragmented as the business grows
The challenge is not lack of effort, but lack of system structure.
What Is Being Built
This work focuses on building the operating system of the business.
This includes:
how decisions are made
how services are delivered
how customer expectations are set and met
how internal processes support consistent execution
The goal is not to define every action in advance, but to create a system that produces consistent outcomes while remaining adaptable as conditions change.
Core Build Layers
Translating Founder Intent into Structure
The system begins with founder philosophy — in this case, a model of care centered on calm, enrichment-focused experiences.
This intent cannot be executed directly.
It must be translated into:
decision criteria
service design
operational constraints
communication standards
This translation is the foundation of the system.
Designing the Experience Architecture
The customer experience is not incidental — it is designed.
This includes:
how services are structured
how environments are configured
how interactions are staged
Each element is aligned with the underlying philosophy, ensuring that experience is consistent rather than dependent on individual interpretation.
Building Operational Processes
Processes are developed to support the system:
intake and onboarding
scheduling and capacity management
service delivery workflows
client communication
These processes are not fixed.
They are tested, adjusted, and refined as the business operates.
Establishing System Constraints
Constraints are explicitly defined to maintain system integrity.
Examples include:
capacity limits
service boundaries
environment requirements
customer expectations
These constraints prevent the system from drifting away from its intended design.
Iterative Development
This system is being built in real time.
Components are introduced, tested, and refined through use.
As the business operates:
new constraints become visible
existing assumptions are tested
processes are adjusted to improve alignment
The system evolves as signals emerge.
Constraints and Tradeoffs
Not all decisions are additive.
Some require limiting options to preserve system coherence.
Examples include:
restricting capacity to maintain experience quality
narrowing initial service offerings to reduce operational complexity at launch
enforcing boundaries that may reduce short-term flexibility but improve long-term consistency
These tradeoffs are part of the system design.
Current State
This is a live system build.
Key components currently in development include:
operational handbook
management system selection and implementation
client data structuring and migration
business website and communication system
foundational business planning
The system is not complete.
It is becoming more structured, more aligned, and more responsive over time.
Why This Is Shared
This work is shared to make the process visible.
Operating systems are often only seen once they are established.
This page documents what it looks like to build one — where structure must be created, tested, and refined in real conditions.
If the system proves effective, it will be because it remains aligned with the conditions it is designed to operate within.