Case Study
Scaling Stratly: Breaking the Linear Campaign Model
Product Designer - Stratly
Sept, 2025
Product & Problem
Stratly is an enterprise B2B fundraising and financial data platform serving enterprise nonprofits. The legacy architecture relied on a single, linear campaign wizard. This rigid, one-size-fits-all model forced large organizations to create completely separate, disconnected campaigns to handle standard donations, peer-to-peer fundraising, and live events. This created massive data silos, complicated financial reporting, and caused severe database logic conflicts as users attempted to hack the setup wizard by skipping irrelevant steps.
My Role & Contributions
I led the UX architecture and product design to tear down the linear campaign model. My objective was to redesign the core infrastructure into a decoupled, modular system that allowed enterprise clients to combine multiple fundraising tools into a single, centralized campaign without overwhelming the UI or breaking the backend logic.
Key Design Decisions
The Problem: One Path for Everyone
The old campaign wizard forced users to make a choice right away: "Are you running a Single campaign or a Group campaign?" Once they clicked a button, they were locked into that path. If a client started a donation page but later wanted to add an event ticket, they had to scrap everything and start over. The backend logic didn't support changing the campaign type mid-stream.
The Fix: Checkbox-Driven Dynamic Routing
Instead of forcing users into rigid templates, I introduced a modular selection architecture. At the initiation phase, users now select their required modules (Events, Peer-to-Peer, Donations) via checkboxes. The system then dynamically generates a custom setup flow based exclusively on those parameters. This completely eliminated irrelevant settings and skipped steps, dynamically scaling the UI to match the exact complexity of the user's requirements.
Decoupling Modules into Mini-Applications
To prevent deep nesting and logic conflicts, I rebuilt the fundamental architecture so that each module operates as an independent application within a parent campaign shell. For example,the Events module now contains its own localized dashboard, ticketing, and attendee lists. By decoupling the settings logic, I ensured that local module configurations do not overwrite global campaign rules.
Events: This module manages ticket inventory, tax receipting for attendees, and check-in lists.
Donations: This module handles recurring billing logic, fund routing, and dedication messages. It is fully customizable, allowing nonprofits to adapt the donation flow to each campaign's specific needs.
Handling Enterprise Complexity
Large organizations often have chapters or branches that need to run their own fundraisers under a main umbrella. I designed the "Group Form" to handle this. It allows a user to pull existing forms (like the "Ramadan 2025" form shown here) into a new container. This nesting logic means headquarters can set up the main rules, and local chapters can just "inherit" them without setting up a campaign from scratch.
Built to Grow
The best part of this architecture is that it keeps the "Add New" menu open for the future. If the product team decides to build an Auction tool or a Raffle system next year, they can build it as a standalone item and drop it into this list. They won't need to rewrite the campaign settings or the dashboard logic to make it fit.
Challenges & Trade-offs
The most complex challenge was backwards compatibility. We had thousands of active, legacy campaigns running on the old linear logic. We could not force an immediate migration without breaking live donation flows. I had to map a data translation strategy where legacy campaigns were automatically encased in the new parent shell but restricted to a single module. This preserved historical data integrity while ensuring all newly created campaigns utilized the flexible, multi-module architecture.