Yapper

Friends and family in the trades had mentioned the same problem over the years: when they are on a job, they cannot always answer the phone. A missed call can become a missed job, and many small businesses cannot justify a full-time office employee.

I had built iOS apps and a Shopify app, and I wanted to learn what it took to run a web SaaS. Yapper gave me a real operating problem to work through: telephony, voice AI, onboarding, billing, notifications, consent, and customer acquisition all had to work together.

Yapper is aimed first at trades and trades-adjacent businesses, though the workflow fits any small business that loses calls while the owner is busy. It answers the business line, collects the caller's details and reason for calling, and sends the owner a summary by text and email.

The default job is deliberately narrow. Yapper captures, classifies, and summarizes the call. Pro customers can turn on calendar scheduling and emergency transfer, but scheduling is optional because a bad availability rule can create an overbooking problem that is worse than a missed call.

The original seven-day trial required a credit card. When signups did not become trials, I reviewed every point where a customer might hesitate. Requiring a card can create fear of an immediate charge or a difficult cancellation, so I removed it. Billing is now added only if the customer decides to continue. I do not have enough trial volume to say whether the change improves conversion.

I tested cold email, follow-ups, and QR-code postcards. Origami ranked more than 1,000 leads by criteria such as business size, location, and review data, and the highest-scored prospects received the postcards. People created accounts, but no one began a trial.

That result made me question the channel as much as the product. Tradespeople are usually working rather than watching an inbox. I did not move to cold SMS because of consent and compliance risk, and I hesitated to cold call people whose phones are also their customer lines. Yapper remains live while I put my limited build time into other products and reassess the next validation test.

Twilio approval delayed the launch by almost two months. SMS was part of the core value, so I could not run a real launch without it. The site and product were ready while I waited, but the vendor dependency stopped the full workflow.

I also validated the category more than my offer. Larger companies already sell AI receptionist products, which proves that businesses buy the category. It did not prove that a small operator would buy my version, at my price, from me. If I started again, I would get four or five prospective owners to commit to paying and use their common requirements to define the first release.

The current default greeting does not proactively disclose that the caller is speaking with AI or that a call may be recorded and transcribed. Owners can edit the greeting, and the agent identifies itself as virtual if asked, but the safer product decision is to include disclosure and consent in the default flow while preserving owner controls. Durable consent records for caller texts also remain unfinished.

The next serious test would be one focused month of daily, channel-specific marketing built around direct conversations with business owners. Three or four customers who stay beyond the first month would be enough evidence to continue investing. Zero customers after that test would be a reason to stop or rethink the offer.

Before that test, I would make disclosure and consent part of the default greeting, add durable consent records for caller texts, and keep the settings editable for businesses with different needs. I would still wait for customer evidence before adding CRM integrations, overage pricing, or a broader feature set.