Designing for composition, not completeness
Most platforms ship a feature checklist. We ship primitives that compose. Here's why that matters.
When we started Alphaspot, the temptation was to ship every feature a customer asked for. Pricing tables. Countdown timers. Quiz blocks. A/B test arms. Webhooks. Calendars. The list never ends.
The trap of completeness
Completeness optimizes for the first feature a customer wants. But customers don't have one feature request — they have a thousand, only a few of which they can articulate. Build for the first, you'll be drowning in the rest by year two.
"Software isn't a list of features. It's a set of primitives that compose into anything the team needs to build next."
What composition looks like
Our funnel builder doesn't know what a checkout is. It knows about steps, transitions, and conditions. A checkout is just a step. A thank-you page is just a step. An A/B test arm is just a transition with a roll function.
Once you have the primitives, the team can build what they need without us shipping a new product every quarter.
The trade-off
This approach is slower to demo. "Look, a pricing table!" sells better than "look, a step you can configure to display anything." We've made peace with that. Our customers find us not because we have the most logos on the marketing page, but because they want to ship something we haven't anticipated yet.