The process behind the principles.

I ruled out the PDF first, for a reason that surprised me when I actually named it: it wasn't just low-friction UX-wise, it was structurally wrong for what I was building. Once it's a file, it can be forwarded to someone whose emotional state it wasn't built for — the profile-based personalization that makes the whole thing work collapses the moment it leaves the original context. SMS solved that, matched the progressive-reveal pacing I wanted, needed no new behaviour from the user, and let me build and test the exact mechanic I was most curious about — all without writing a line of app code. Reading the conditions here meant recognizing that the "leanest" option on paper (the PDF) was actually the wrong bet, because it failed on the dimension that mattered most.

I killed the new project despite the money already spent on it, because due diligence showed it was solving the wrong problem — adding a fourth app to a stack that was already incoherent, when the real issue was that one identical experience was being forced onto merchants with completely different end-user needs. I chose to consolidate around the original Ackroo app specifically because its simplicity was an asset, not a limitation: it was the only foundation stable and standardized enough to build on without inheriting the India outsourcing dependency or the shared app's structural failures. That let us cut the outsourced contract entirely, run the rebuild with one dedicated in-house mobile director, and layer in features merchants would actually pay for — punch cards, vendor-linked promoted ads, self-serve profiles, food-ordering integrations — funded by converting to a recurring monthly SaaS fee instead of a one-time charge. Some free-tier customers who wouldn't pay for the improvement churned out, and that was the right trade: new merchant sign-up landed close to 100%, and net dollar retention actually improved, because we'd finally priced the product to cover what it cost to run instead of eating that cost indefinitely. Reading the water here meant recognizing that the option with the most money and momentum behind it wasn't automatically the right one to finish.

The questions that don't appear in that table matter just as much — the flow only asks 2b (what are you celebrating) if someone actually chose "I'm celebrating something," and only asks which part of Hamilton if they chose to keep things close. Nobody answers a question that doesn't apply to them, which is a big part of why the flow doesn't need explaining as you move through it — it's already reacting to what you told it. Contact information — name, email, phone — comes dead last, after someone has already emotionally invested in the questions, rather than gating the experience behind a signup wall up front. And the logistics that do need to be stated plainly — the specific days and hours we run, the 48-hour lead time — are said once, exactly where they're needed, instead of living in a separate FAQ someone would have to go looking for.

The Location Mapping question wasn't part of the original flow — it came from watching real users hit friction after launch. Some were frustrated at being routed across town because they hate traffic; others were disappointed we hadn't sent them somewhere new. That split told me it wasn't really a logistics question, it was a personality signal, so I added it as an explicit choice instead of guessing. Users have also flagged a real limitation: intake happens at booking, but the actual experience can be three to four weeks later, so the emotional state someone reports isn't necessarily the one they'll be in on the day. That's a legitimate gap, and it's also a good example of holding scope — the fix (resending intake closer to the actual experience date) is a real idea for a future version, not this one, because the priority right now is getting a clean, solid read on how version one performs before adding more moving parts.

One more deliberate choice sits underneath all of this: the intake questions only appear after someone has paid, not before. I went back and forth on the logistics of that for a while, but landed on it for a specific reason — the questions themselves, combined with the profile-building logic on the back end, are close to the actual secret sauce of the product. Showing them to anyone browsing before they've bought in would let people reverse-engineer how the personalization works without ever paying for it. Asking for that information after commitment, not before, protects the mechanism the entire product depends on. If a question ever needed a tooltip to make sense, that was the signal to rewrite the question, not add the tooltip.

I kept the disclaimer short and repeated it everywhere it was actually relevant — pricing, post-intake, the footer — rather than writing it once and burying it on a policies page nobody reads. Linking it to a real crisis resource, not just a vague "seek help" line, was the non-negotiable part. Everything else about it — the phrasing, where it sits, how much visual weight it gets — got the same attention as any other line of copy on the site, because a disclaimer that reads like it was pasted in from a template undermines the exact trust the rest of the brand is built on.

The wipeout was slow, not sudden. Twilio changed its developer portal mid-build, and it started hanging and freezing on me — the logs wouldn't update in real time, so I'd send someone their next message and then have no way to know whether it had actually gone through. That's a bad feeling on its own; it's worse when the thing on the other end is a real person mid-experience, waiting on you. And the setup only worked for one person at a time — the front end wasn't built for concurrency, so running two experiences at once meant real risk of sending the wrong message to the wrong person. None of that was sustainable, and testing more than one person at a time — which I needed to do — made it actively worse.

I automated the SMS delivery ahead of schedule, earlier than I'd planned to take that on, because the manual version was costing me more than the build would. It took real time to get right. Once it was live, it did more than remove the babysitting: I built a proper dispatch site on top of it, so I can see every active experience at a glance, with stalled conversations flagged automatically instead of me guessing from a silent log. And because the same infrastructure was already in place, I shipped a second thing I hadn't originally planned for this stage — automated feedback collection and referral prompts once an experience wraps, so every completed experience now feeds the next one instead of just ending.

This wasn't a workaround I'm apologizing for — it was a deliberate bet. Waiting to fund an engineering team before testing whether an emotionally-guided itinerary could actually make someone feel different would have meant months of delay and real money spent before knowing if anyone wanted this at all. Working directly with Claude let me write, debug, and ship the actual mechanics of the product myself — the SMS flow, the profile-building logic behind intake, the dispatch automation — without a sprint cycle or a team to loop in first.

I'm honest with myself about the trade-off. I'm not a professional developer, so there's real technical debt sitting in that codebase, and I don't have a second set of eyes catching the blind spots an actual engineering team would catch. But the goal at this stage was never to build enterprise infrastructure — it was to find out, fast and cheaply, whether the core idea worked. Given the conditions I actually had, that was the right board to be on.