DateBot

Most dating AI starts with "what should I say?"

DateBot starts by understanding the situation and deciding what to do. Wording comes last, and only when sending something is actually the right move.

That means the product can recommend action, restraint, waiting, or no action at all instead of always manufacturing a reply.

The AI layer is designed around distinct responsibilities rather than a single model call that produces the final answer end to end.

Reasoning and response generation are separated so I can improve decision quality without unintentionally changing tone, and improve conversational quality without silently changing the underlying advice.

Screenshot understanding is part of the same product path, which lets DateBot reason directly from real conversations rather than relying on a user to summarize them correctly.

DateBot maintains person-aware context across otherwise separate chats.

A user can discuss someone, start a new conversation days or weeks later, and continue without re-explaining the important history.

That required treating long-term context as a product-level system rather than simply attaching history to a chat thread. The design prioritizes correctness over aggressive matching because mixing context between two people would be worse than temporarily knowing less.

AI behavior is easy to change and surprisingly hard to improve reliably.

I built a dedicated evaluation system around DateBot so changes can be tested against reproducible situations before reaching users. It supports behavioral regression testing, replay of real product paths, controlled comparisons, and validation of changes across different model configurations.

That system became part of the development loop rather than something added after launch. A change that sounds better in a few manual tests does not ship unless the broader behavior still holds.

DateBot is built as a real asynchronous product rather than a synchronous demo.

AI work runs outside the request lifecycle, allowing the system to handle retries and longer-running generations without tying correctness to one open connection.

Results are delivered back to the app in real time, with push notifications when the user is no longer active. The client can recover state from the backend rather than treating one socket connection as the source of truth.

The production system also includes server-side subscription enforcement, persistent usage state, background processing, monitoring, and private operational tooling for inspecting AI behavior and production issues.

The app is built in Swift, SwiftUI and UIKit rather than as a web wrapper.

The product includes:

The backend handles AI workloads, context assembly, memory, subscriptions, job execution, and real-time delivery.

DateBot was an exercise in building an AI product where the hard part is not generating text.

The harder problems were deciding what the system should do, preserving context over time, measuring whether changes actually improved behavior, and making the whole thing reliable enough to ship as a real consumer product.