Inside the Build: How We Shipped Amigify from Idea to App Store

Most of our work is client projects: someone comes to us with a business and a problem, and we build the software that solves it. Amigify was different. It's ours, an in-house product, which meant we were the client too, and had to be honest with ourselves in a way that's easy to skip when the deadline and the budget are somebody else's.

The premise is simple to say and hard to build well: connect people with verified, trained companions for private conversations, by message, voice, or video, any hour. Not therapy, not a crisis line, just someone to talk to. Simple premise, but underneath it sits real-time messaging, identity verification, a payment system, content moderation, and two native apps that both had to feel trustworthy from the first screen.

Here's how we actually built it, using the same HOW WE WORK framework we use on every project.

01 Listen: Starting from "why would anyone want this"

Before any design work, we spent time on the uncomfortable question: why would someone pay to talk to a stranger instead of a friend? The answer that kept surfacing wasn't loneliness in the abstract, it was specific. People wanted to say something out loud, once, to someone with no history, no stake in the outcome, and no reason to bring it up again tomorrow. That's a different job than a chat app or a social network is built for.

That single insight shaped a lot of early decisions: nicknames instead of real names, no public profiles to perform for, and a companion who is explicitly a trained listener rather than a therapist, so nobody on either side is confused about what they're getting.

02 Plan: Designing for trust before designing for delight

With a companionship product, the interface isn't the hard part, the trust is. We mapped the entire conversation lifecycle before touching a single screen: how a message gets encrypted, what a companion can and can't see, what happens when a report gets filed, how a 24-hour reply window keeps things fair on both sides without ever gating the user who's actually writing.

We also planned the payment model early rather than bolting it on later. Amigify runs on a prepaid coin balance, charged per message and per started minute of a call, no subscriptions, nothing auto-renewing. Deciding that upfront meant the wallet, the pricing screens, and the backend ledger could all be designed together instead of stitched together after the fact.

03 Build: Two apps, one backend, and a lot of edge cases

Amigify shipped as native iOS and Android apps, built in parallel with a shared backend handling messaging, verification, moderation, and payouts. A few things that turned out to matter more than expected:

• Messages are encrypted with AES-256-GCM, and every message and image is screened automatically the moment it's sent, text by our own filtering, images by an AI moderation model, so content that breaks the guidelines gets blocked before it reaches anyone.
• Video is opt-in on both sides. A companion has to explicitly enable video calling before it's even possible, and the call still has to be answered. Nobody is ever obligated to turn a camera on.
• Every companion is identity-verified and age-verified before they can take a single conversation, and every report is reviewed by a person, not resolved automatically.

None of that is visible in a feature list or a screenshot. It's the kind of work that only shows up when something goes wrong and it doesn't, which is exactly the point.

04 Launch: Building the marketing site alongside the product

We didn't wait until the apps were finished to think about the website. The Amigify marketing site, waitlist infrastructure, pricing explainer, safety pages, and legal documents, was built in parallel, so by the time the apps were ready for early access, there was already a place for people to land, understand what the product actually is, and join the waitlist. Waitlist members are being invited in batches ahead of the public release.

What building our own product taught us

Being the client on this one meant we couldn't hide behind "the client wanted it that way." Every decision, from the 24-hour message window to the choice not to show public profiles, had to be defensible on its own, because we were the ones who'd have to stand behind it.

That's a discipline we now carry back into client work: not shipping a feature until we can explain why it exists, not just that it was requested.

---

Curious how we'd approach your product? Let's talk about what you're building, or see Amigify live to see where this one landed.