Scouted

The trigger was watching my son start talking to college coaches. I knew him well enough to know he would not keep track of any of it. The spreadsheet I built lasted a day before I realized this had to be an app: one home for every school, coach, conversation, and decision in his athletic recruiting, and a way for families to finally deprecate their spreadsheets.

Getting the data in is the whole problem

I expected the hard part to be the recruiting journal. It was not. The hard part is that the information lives in a teenager's email and text messages, and iOS gives an app no reasonable way to reach either. Everything else follows from working around that.

Four ways in ship today: type it manually, paste email content, take a screenshot of a text thread and let the app read it, or connect an Outlook account and search the mailbox directly. None of those is elegant. They are the cleanest hacks available inside the platform's constraints, and the number of them is a measure of how stubborn the problem is rather than how rich the feature set is.

Three more are built and have never been switched on: a forwarding email address, a browser extension for reading webmail, and a Mac importer that would pull iCloud and iMessage data in the background. The Mac importer is the one I would most like to finish, and it is also the one that requires a user to own a Mac, so it waits for a user base that justifies it. None of those are features until somebody can use them, so I am counting four rather than seven.

Cheapest model that gets it right

Reading a screenshot of a text conversation and turning it into structured records sounds fragile. Once the prompt was right it has been surprisingly reliable, and it keeps getting better without me doing anything, because the models keep improving.

Everything goes through OpenRouter rather than straight to one provider, and that was a deliberate early decision. New models appear most weeks. What I want is the cheapest one that produces correct results for a given job, and the freedom to move the moment something better or cheaper lands. Going through a gateway makes swapping a configuration change rather than a rewrite. The app is currently running on models that are not close to state of the art, because they are sufficient and they are inexpensive.

All of the AI work happens asynchronously, which was the intent from the beginning. Nothing about a language model belongs in the path of a screen the user is waiting on. Doing that on Supabase means accepting some polling, which took a little understanding to get right and has been fine since.

The suggestion that sold me

The smart suggestions are my favorite thing in the app, and one test case is why. An athlete had gone on an official visit. The suggestion that came back was to remind him to send the coach a thank-you note.

Nothing in the code knows what an official visit means socially. The model understood the context, and understood that a thank-you after a visit is the kind of small communication that matters disproportionately in recruiting. It was exactly right and I had not anticipated it.

The practical value is smaller and more useful than that moment suggests. Suggestions collapse a lot of the manual bookkeeping into a tap, and manual bookkeeping is precisely what a teenager will not do. Anything that turns a chore into a confirmation earns its place.

Conversation summaries were the first AI feature built and they remain core. A parent or an athlete needs a straight answer to where things actually stand with a given school, and a summary does that better than scrolling a thread. It also has a second effect I did not design: seeing a summary go stale is a reason to enter more recent information.

The NCAA publishes PDFs

Recruiting rules run on a calendar that says when coaches may contact, evaluate, and visit athletes, and the NCAA publishes that calendar as PDFs, per sport and per division, on an S3 bucket. The app needs that data.

It gets parsed once a year, by pointing an agent at the PDFs and having it pull the data out. Format changes between seasons used to be the thing that would break a scraper. Current models handle them without intervention, which quietly turned a maintenance problem into an annual chore I trigger by hand.

Being wrong about this matters more than most things in the app, because a family could plan around it. Everything is presented as informational, with a clear instruction to confirm against the NCAA or the university. I would rather be visibly cautious than quietly authoritative.

The minor panic

Somewhere in the build it landed properly that I was storing personal data about children. That caused a short panic and then a lot of deliberate design.

The app is 13 and over. It is explicitly not social: there is no mechanism for one user to find or contact another, because the entire category of risk that comes with that is not worth any feature it would buy. Deletion is transparent and immediate, because data this personal should be easy to take back.

Family sharing was the one place where sharing had to exist, and the shape of it is the part I am most confident about. A parent gets a read-only view of what the athlete sees, enforced with row-level security in the database and not only in the interface. The athlete can remove a shared user instantly, with one button. Sharing is capped at two people and only on a paid plan, which sounds like a monetization decision and is really a safety one: an adult has to be aware of a payment before anyone gets added, which makes casual or accidental sharing with the wrong person much harder.

The athlete is in control. Every decision above falls out of that one.

The problem I have not solved

The technology has not been the difficulty. Expo and Supabase have both been good choices and have not caused anything I could not work through.

The difficulty is the interface, and it is not my strength. The question underneath it is genuinely hard: how do you make a CRM that a teenager wants to use? Recruiting bookkeeping is exactly the kind of work a sixteen year old will not do unless the app makes it feel worth doing, and there is a narrow band between showing too little to be useful and showing so much that it is overwhelming.

I have rebuilt the interface many times. Most of those versions never went to production. I am still not certain the current one is right, and data entry remains the weak point. That is the honest status of the most finished thing I have built: the plumbing works, the AI earns its place, and the part a user actually touches is still the open question.