Product Strategy & Prototype · In development
A modular business operating system — fifteen business tools, one platform, taken from strategy through working prototype
Founder — strategy, design, and build
2026
In development · Working prototype
Canopy is 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.
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.
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.
The information architecture is the pitch: fifteen engines, each named, tiered, and scoped — the complexity laid out in plain sight. Pricing works as product architecture too, with tiers named for growth — Seed, Grow, Forest — so upgrading feels like progress, not a paywall.
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. The screens shown here use seeded demo data.
Cross-engine automation is the payoff of shared data: cart recovery, lead follow-up, and post-booking thank-yous run as workflows because every engine feeds the same customer record. Booking services feed the same contacts the CRM and email engines use, and role-based permissions make the whole thing safe to share with a team.
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.
The marketing layer carries its own editorial voice — Playfair Display over DM Sans, distinct from the SF Pro product UI — and the social graphics aren't Figma exports; they're generated by an in-product canvas tool that renders posts from the same brand tokens the platform uses. One system, from design tokens to Instagram.
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.
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.