Making Customers Happy

We treat customer happiness as a leading indicator, not a vanity metric. Most of what we measure about a product flows from a single question: does someone keep using this product six months in, and would they recommend it to a peer who runs the same kind of company? That's our north star.

What "happy" means to us

It does not mean:

• NPS above some arbitrary threshold
• A polished status page and a Zendesk queue
• "Customer success" theater dressed up as account management

It does mean:

• The product solves a real, recurring problem in the customer's actual workflow
• Support comes from people who built the product, not from a separate offshored team
• We close the loop on feedback: either the requested feature ships, or we explain clearly why it won't
• Customers tell other operators about us without us asking

How we build products people want

We follow the same playbook on every product:

1. The first version comes from a real operator who hit the problem themselves. Popupsmart came from the agency. LiveChatAI came from running customer support at scale. enricher.io came from needing clean entity data for personalization. We don't build products on speculation.
2. Ship the MVP and find five paying, delighted customers. That's our product-market-fit bar. Not five logos. Five customers who actually love the product and would push back if we took it away.
3. Only then expand. New features come from real usage signals, not from sales-led wishlists.

This is deliberately slow at the beginning and fast afterward.

Engineers talk to customers

We don't separate "the people who build the product" from "the people who hear from customers." On our products:

• Engineers spend time in shared inboxes and community channels, directly, not via tickets
• Public roadmaps are visible before a product launches
• When a customer asks for something, the response either ships, gets a PR, or comes with a clear written explanation of why it won't

This compounds: customers who see their feedback shape the product become advocates. Advocates bring more aligned customers. Aligned customers give better feedback. The loop tightens.

Where dedicated support fits in

For our higher-volume products, a customer success function handles routine usage questions, onboarding, and account expansion. That work matters, but it sits on top of engineer-to-customer contact. It never replaces it.

For our newer products, the founder and the build team are the support team. That stays true until a product crosses a usage threshold that genuinely justifies dedicated CS.

Our promise

We will never:

• Lock you into multi-year contracts you can't get out of
• Charge you for usage you didn't actually use
• Pretend a feature exists when it doesn't
• Hide pricing or sales-only "talk to us" pages on core products

We will:

• Reply to substantive feedback, especially the negative kind
• Tell you publicly when we ship something, change something, or break something
• Be operator-led in how we run support, because we are operators ourselves