Hey guys,

Remember yesterday when I proudly said “just getting something into production on day 0, even if it’s just a form that collects emails?”

Well…

My only and first feature in production failed. Let's hope my boss doesn’t read my newsletter.

I tested it locally. It worked of course. I shipped to prod. I did not test in prod. Because why would a waitlist form break between local and production?

It’s a waitlist form.

Thanks Peter. Bless you, and luckily he caught it during the first A/B test sample of only a couple hundred emails. I ran back from the grocery store and even nicked by hand drawing blood to fix it before I got fully embarrassed sending a dead link to everyone.

The fix took two minutes. An environment variable wasn't set for production in Vercel, so my Supabase calls were getting rejected. Worked on my machine. Did not work on the internet.

Lesson: trust but verify. Then verify again in prod. What works locally can fail in production for the dumbest reasons. From now on, nothing ships without me clicking through the live URL myself. Every time multiple times. Still got some signups so no damage besides my ego.

Anyway, let’s get to todays entry.

Since I was already in the waitlist code, I added a quick post-signup survey. Just three questions after someone joins. Took about 15 minutes.

Where are you based? If 40% of signups are outside the US, my SMS-first decision starts looking off.

How often do you go on dates? Frequency signals willingness to pay and helps me think about pricing tiers against “cost-per-date” unit economic for me. Someone who wants weekly date nights has a very different value threshold than someone doing monthly.

Would you pay more if your assistant monitored hard-to-book restaurants or places you specifically flagged, and alerts you when a spot opens? I got a LinkedIn DM from someone offering $100 for exactly this (more on that below). I want to validate whether that's one person's enthusiasm or an actual feature with legs. Early signal on a potential premium tier before I build a single thing.

I also added a clean share-to-LinkedIn prompt after joining. My early waitlist is coming almost entirely from here and I know you all have LinkedIn, so making it easy to spread there just makes sense. Go where the people already are.

If you want to see the flow, you can here: test the waitlist flow (and join it).
*I tested in 5 times.

Sadly not much building, much more connecting the nervous system. All the services that need to talk to each other before the agent can actually do its job. Today was a lot of signing up, copy and pasting credentials, and applying for things.

I did manage to get to some of the real stuff in local: signup, login, and onboarding.

I had this flow planned from day 0 and my primary PRD Claude and I worked on, so this step was just getting Cursor to execute.

The flow I have right now: landing page → verify via text → land on /onboarding → Answer a few questions in one dynamic chat flow to get the context the agent needs to plan for you. City, neighborhood, budget, date frequency, preferred days and times, interests, dietary restrictions, food dislikes, anything else the assistant should know.

The interesting part is what happens with all of that. It gets stored in the db of course, but it also gets structured into a system prompt that goes into the agents core persistent memory and context just for that couple.

Every time the agent responds, it rebuilds this context fresh, loads the couple profile from the database, loads the last N messages, combines them into the system prompt and message history, and sends that to Claude. The couple profile lives in the system prompt (which Claude treats as fixed, privileged context) while the actual conversation lives in the messages array. So the agent always knows who you are and what you like, no matter how many turns into the conversation you are.

This is the kind of architecture decision that matters a lot for agent products. The system prompt is your product's personality and memory. Getting this structure right early means the agent feels like it actually knows you instead of starting cold every time.

Where I'm at: The web flow works mostly. Data saves. Onboarding completes. But I haven't got the text flow working yet—I need to spend time debugging why the first message isn't coming through after onboarding from Twilio.

Tomorrow's problem/goal. I want this sending…

That's the moment the product comes alive. Not the Aha moment, but something showing it’s there.

Right now it's a form that saves data. Tomorrow it should talk back. Even if the first word is a mumbled "Dadda!” and it has no idea what I say back.

This was cool

This is the fun and important part about building in public.

Ian saw yesterday's post and said they'd pay me $100 a month if I solved an adjacent problem: an agent that watches your favorite hard-to-book restaurants for availability and alerts you when a spot opens. "Hey, Carbone in New York has a spot next Thursday — want me to book?"

I almost sent him a Stripe link right there.

Decided that was maybe too ambitious before the core product works. But it's on the roadmap (which is just in my head right now) as a premium feature and retention hook— passive restaurant monitoring that pings you when a reservation opens at your dream spot.

Out little $100 MRR target might be closer than I thought. And who knows, maybe not even for the reason I expected.

See you after some more progress.
— Jaryd