A self-serve Community Hub builder that removed setup from engineering and put launch control in customer hands.
Designed and shipped a self-serve Community Hub builder, replacing a manual dev-dependent process
Role
Product Designer, end-to-end
Timeline
3 months
Team
Solo designer, PM, 3 engineers
Outcome
4 to 6 hours down to under 20 minutes
Context
Launching a Community Hub inside Breakthru CRM required developer intervention every single time. The setup worked, but it could not scale with customer growth.
Breakthru CRM served nonprofits and political organizations. Every new Community Hub required manual developer configuration, usually taking 4 to 6 hours per setup and repeating for each customer. That meant every launch depended on internal bandwidth instead of customer readiness.
This was not just a usability issue. It was an operational scalability problem. Each new hub competed with core product work for engineering time, and campaign initiatives were delayed by setup bottlenecks that should have been part of the product.
Problem
Customers could not create or edit hubs independently. Engineering and support absorbed the repetitive work, while organizations waited for setup steps that followed the same patterns again and again.
The opportunity was to turn a repeat service workflow into a self-serve product flow: something customers could launch themselves with enough guidance to feel confident, without handing them a blank system they did not know how to configure.
Manual configuration took 4 to 6 hours per hub.
Organizations couldn't create or edit hubs independently.
Campaign and community initiatives were slowed by setup dependency.
Research
I ran six customer interviews focused on customization needs, paired that with support and engineering sessions to map the repetitive setup tasks, and audited SaaS builder tools like Wix, Squarespace, and Webflow to understand where guided flexibility worked best.
The key pattern was clear: customers wanted branding control, but most actual setups reused the same few structural patterns. The builder did not need to start from infinite flexibility. It needed to make the common paths fast and safe.
About 80 percent of customers primarily wanted branding control, and most setups reused the same three configuration patterns.
Key Decisions
The PM initially pushed for maximum flexibility through a blank starting point. I argued for templates because most customers did not know where to begin and clustered into three common use cases: volunteer signup, event promotion, and fundraising.
Engineering proposed a save-and-preview model for speed. I pushed for immediate visual feedback because builder confidence depends on seeing changes reflected while configuring, not after committing them.
The builder exposed branding basics up front and hid advanced controls behind accordions. That kept the default flow approachable while preserving power for organizations with more specific setup needs.
Solution
The shipped builder flow moved from template entry into modular configuration across branding, features, and layout, then into preview and launch. It was designed around reusable components that matched the engineering architecture, which kept the product model aligned with implementation rather than becoming a purely visual layer.
Template-first onboarding gave customers a place to start, while the builder itself exposed the decisions they actually cared about most: name, color, logo, layout, and feature toggles. Advanced options remained accessible, but they no longer dominated the primary path.
Impact
Setup time dropped by roughly 95 percent, moving from 4 to 6 hours of developer-led work to under 20 minutes of self-serve setup. That removed 15 to 20 engineering hours of repetitive work every week and redirected that time back into core product development.
Support tickets related to hub setup dropped by 70 percent, and the builder became the standard launch path for all new customer hubs. The value of the feature was not just speed. It changed who owned the work.