Case study 04 · Founder product · In development

Canopy — a modular business operating system

One platform that replaces the website builder, CRM, booking system, email tool, and half a dozen other subscriptions a small business duct‑tapes together. Every tool — an "engine" — shares the same customer data. Canopy is my own product, presented here as an in‑development prototype, not a shipped one.

Role Founder — strategy, design, and build

Architecture 15 engines · multi-tenant · one data layer

Prototype scale 120+ screens · 130+ API endpoints

Status Working prototype — not yet launched

Summary

The problem: small businesses pay for eight or more tools that don't talk to each other — each with its own login, its own copy of the customer list, and its own bill. My contribution: everything — market research and positioning, product architecture, design system, and the working multi‑tenant build. What it demonstrates: taking an ambiguous, oversized product vision and reducing it to an architecture, a system, and a buildable MVP — then building it.

Fig. 01The brand on one sheet: forest green #2D6A4F at the core, growth-named tiers, and fifteen nature-coded engine accents inside one neutral system.

Fig. 02The social campaign in three beats: the promise, the enemy — eight struck-through subscriptions — and the invitation to build your canopy.

Canopy landing hero: 'One platform. Every tool your business needs.' with fifteen engine icons along the left edge — Fig. 03The product vision in one screen: every engine on the left rail, one promise in the middle.

Architecture as pitch

Fifteen tools that feel like one product

The central design problem was making fifteen tools feel like one product without collapsing into enterprise complexity. The answer is the engine model: every capability is a self‑contained module with its own identity that plugs into a shared shell — one sidebar, one command palette, one notification system, one customer record.

Canopy engines grid: Website & CMS, CRM, Scheduling, Commerce, Email, Analytics, Automation and more, each tagged with its tier — Fig. 04The information architecture is the pitch: fifteen engines, each named, tiered, and scoped — the complexity laid out in plain sight.

Canopy pricing: Seed $49, Grow $149, Forest $349 tier cards — Fig. 05Pricing as product architecture: tiers named for growth — Seed, Grow, Forest — so upgrading feels like progress, not a paywall.

Onboarding: a single calm 'Set up your business' card with industry chips — Fig. 06Fifteen engines, one quiet front door: onboarding asks three things — name, URL, industry — and gets out of the way.

The working prototype

Not a mockup — a running multi‑tenant system

The prototype runs against a real multi‑tenant database with row‑level isolation: 120+ screens and 130+ API endpoints across CRM, automation, email, CMS, booking, and permissions. Screens below show seeded demo data.

Roots CRM pipeline kanban with deal cards across five stages — Fig. 07The Roots CRM pipeline — deal cards moving through five stages against the live database.

Ecosystem automation workflows with run counts — Fig. 08Cross-engine automation is the payoff of shared data: cart recovery, lead follow-up, post-booking thank-yous, with per-workflow run counts.

Bloom email campaigns with open and click rates — Fig. 09Bloom, the email engine — campaigns with open and click performance in the same visual system as everything else.

Sprout CMS listing pages, blog posts, and navigation with publish states — Fig. 10Sprout, the CMS engine — one of four distinct product domains sharing one design system.

Flow booking engine: services with durations and prices — Fig. 11Flow, the booking engine — services feeding the same contacts the CRM and email engines use.

Team members and role-based permissions — Fig. 12Sanctum handles roles and permissions — the unglamorous engine that makes the rest safe to share with a team.

Design system

Calm, credible, and white‑labelable

The visual language is a muted forest green over true‑neutral grays — calm and credible rather than loud SaaS. Each engine carries its own earthy accent inside the shared system, so users always know where they are. Design tokens live in code as the single source of truth, and a brand provider lets each business white‑label its workspace.

Brand & go-to-market

Growth as the brand, not just the pitch

Canopy's marketing layer is live: a public site on Vercel with its own editorial voice — Playfair Display over DM Sans, distinct from the SF Pro product UI — and a social campaign to match. The social graphics aren't Figma exports; they're generated by an in‑product canvas tool that renders ten square posts and a vertical carousel from the same brand tokens the platform uses. One system, from design tokens to Instagram.

Start where you are. Grow into what’s next.
Canopy marketing site — growth plans

Canopy marketing site section: 'When one thing happens, everything else knows' with six cross-engine automation examples — Fig. 13The marketing site sells the architecture itself: “When one thing happens, everything else knows” — six cross-engine automations as the proof.

Status & next

Alpha → closed beta → general availability

Core engines — website/CMS, CRM, booking, commerce with Stripe checkout, email — run against the real database; several engines are earlier‑stage surfaces. The first target niche is wellness and beauty businesses, who need exactly the website + CRM + booking core and already spend heavily on fragmented software. Canopy has not launched publicly.

Reflection

Scope is a design material

Canopy's real lesson is scope discipline: an oversized vision became buildable only when the engine model turned 'everything' into slices that ship independently. The pricing tiers, the IA, and the architecture are the same decision expressed three ways. Next: put the wellness engine-set in front of real businesses in a closed beta before widening the aperture.

Competencies demonstrated

Strategy Market positioning · pricing architecture · MVP definition

Architecture 15-engine IA · multi-tenant model · roles

Design system Tokens in code · per-engine identity · white-label

Prototyping 120+ screens running against a real database