What’s up everyone.

Ok, I’ve been doing work on the Dateful project for 3 days now.

Let’s level set quick before I explain the sour pickle I’m in.

This thing exists to solve one problem: take care of date night planning for me.

For this to be interesting it needs to actually take care of all of it. The magic moment has to be non negotiable, and that’s a text to the user with the following punch line: “Here’s your plan. I’ve booked the table for you guys at 7pm. Let me know how it was. Have fun!”

To do this, Dateful must be an agent that knows the couple and handles everything—finds the spot, suggests the plan, gets it approved or makes some edits, then books the reservation. We just show up.

Not just a recommendation engine. Not just a list of restaurants. An agent that can reason and execute the entire date night from plan to booking.

That's the value prop. That's what I would pay for and what people have told me they’d pay for. And the goal of this mini challenge project is validating I can solve this and get $100 worth of recurring payments within 30 days.

Cool.

Now, here's where we are on Day 3…

So far, I’ve got it so you can login, answer some structured and open questions in a chat-style onboarding UI that informs the agent, and I’ve now got 6 unique date cards being generated with nice-looking and relevant date ideas.

Dates actually are personalized to you, and the agent uses the Google Places API and the web to make them timely and accurate itineraries.

These cards come through embedded within chat (I’m betting on a fully chat UI), and you can like or dislike the date cards. Your preferences feed back to the model, and saved dates show up on a new Dates page with pins for Saved Dates, Planned Dates, and Past Dates.

Why 6 cards specifically? Enough variety to feel like a real experience and see what the app does for you—you're browsing, not just saying yes or no to one thing. And not too many that it runs up my costs in model and API calls while users are still on trial. And enough to actually learn something about you, as each card carries metadata about why the agent suggested it. So when you like some and skip others, the model builds a real taste profile.

Not just "they like Italian" but "intimate spots with outdoor seating at a $$ price point on Fridays."

The UI is chat-first. Everything—subscription upsells (when they come), booking, interactions—all lives in chat. This is a bet. I think people are comfy with chat UIs now and know how to use them.

This was my goal for day 3 so I guess well done? Except, day 3 also ran my little speedboat into a sandbank…

And I’m wondering…how am I going to get myself to pay for it?

Before you build (or keep building) a product that has AI, ask yourself:

Can the user get this same result with reasonable effort by prompting ChatGPT or Claude directly?

The line here is moving fast. Models can do more execution now than six months ago— browsing, tool use, agentic workflows. So the question isn't "can a model do this?", as the answer is often yes if you know what you’re doing. It's "can a model do this with reasonable effort for a normal person?". Can a couple paste preferences into Claude and get date suggestions? Yes. Will they set up persistent memory, connect search APIs, monitor availability, and trigger proactive plans every week? No. That's where product value lives.

The differentiation isn't what the model knows. It's the system you build around it. In my case, persistent context, real integrations, proactive actions, and an experience that works without thinking about prompts.

Build the system, not the wrapper.

But, everything Dateful does today, you could do with reasonable effort by pasting your preferences into your favorite chat for date ideas. You'd get 80% of the same output.

Personalized itineraries are nice. But they're not a paid product. They're a wrapper.

And I'm not building this thing to learn how to make a wrapper. Punch the monkey can make a wrapper.

My goal is to use a model as the base layer and build something with a unique value prop on top of it. Something the model alone can't do for you.

For Dateful, that something is easy execution that just works. The hard and frequent problem here for date nights is restaurant booking. The actual reservation at the actual restaurant.

That's the gap between "here are some ideas" and "here's your Friday night, confirmed."

That’s the gap between $0 and say $10-$15 a month. Or for some people, the $100/m they said they’d pay.

I know people care about this and so do I. This is the benefit of being a selfish builder making what you want for yourself, you get to be your most discerning user.

And I know this isn’t a product I can charge for or would pay for, which brings me to my goal…how do I get to my $100 a month in 30 days?

The demand is there. The willingness to pay is there. The capability is not.

And it’s not not there because it’s just 3 day of the build.

To play the blame game and point fingers 👉 OpenTable rejected my API application. No detailed reason. Just a no.

Without booking access— OpenTable, Resy, whoever— Dateful can generate a beautiful itinerary and then hand you a deep link to go book it yourself. Which is fine. Somewhat cool. But it's not the product. It's a recommendation with extra steps.

This is the ugly issue with building on top of platforms you don't control. I need OpenTable or Resy to let me in for the core value prop to work. That's not a technical problem. It's a business development problem. And it's one I can't solve with more code no matter how much I tell Claude “You are an expert staff engineer!!”.

Am I building myself into a grave? Maybe. Being reliant on a third party's API approval to get beyond wrapper territory is exactly where you don't want to be as a solo builder.

And they say for every finger pointed, there are 3 pointing back at you. Well, this is the exact type of thing I should have researched before—not just assuming OpenTable would give me access. I made this mistake because every other API I needed access to I got easily without grief.

A risky assumption.

And hopefully digging out of the grave, not deeper.

My next step is two-pronged.

That spike is priority one before I vibe enough line of code, because the answer shapes the entire value prop. If I can't execute bookings, I might need to pivot what this product actually is.

I’m going to leave my Cursor and GitHub project alone in this next phase, and use Claude Code to make something dead simple (no auth or anything) that verifies if this approach allows me to book something.

This isn't a disaster. I'm not deep in a pit discovering this late and as you know I’m not precious on this idea—the last few days have basically been one big spike anyway.

Three days in and under $100 and I know exactly where the risk is. That's the point of building fast and furiously and writing about it. No harm no foul.

But note to self for the next challenge/build: before starting, use something like Claude Code to spin up a "does this work" prototype for the riskiest assumption. Don't build the auth, the onboarding, the UI, the date cards, the chat experience — and then find out you can't do the one thing that makes it a product worth paying for.

Test the hard part first. Test the hard part first. Test the hard part first.

Prove the risky thing before you build the pretty thing. Especially now with AI coding where with a few sentences and screenshots, suddenly you have a UI coming to life and it’s super exciting.

Things can easily run ahead of you before a technical assumption has been vetted.

I didn't do that this time. Lesson logged.

No API? Fine. Let's get weird.

The next post will be on this and I hope for all our sakes it’s an interesting one. But in short, instead of asking OpenTable or Resy for permission to use their API, and instead of trying to reverse engineering their API (which is apparently as simple as looking in dev tools at the network tap for API calls?), what if I can get an AI agent just to use their websites?

I know I can do that for myself as a single user, but can I productize browser automation for many people?