YurAI
Context
I hate having a billion apps for everything. One for notes, one for the calendar, one for whatever I signed up for last month, and every one of them wants an account, a place on a home screen and a decision about notifications that I will get wrong. The one thing I open a few hundred times a day without deciding to is Messages. So the assistant went in there rather than becoming the twelfth app, and everything else about the project follows from that.
The other half of it was that I did not want a meter running. The obvious build is an API key and a bill that grows every time you talk to it, which is a good way to start rationing your own questions. I already pay a flat fee for a Claude subscription, and that subscription lives in a terminal on the PC in my room. So the assistant is a service on that machine: a text arrives over Surge and a webhook, the service pushes it into the terminal, and whatever comes back gets sent to my phone as a reply. No bill per message, and a model already sitting in my own files instead of one that has to be handed everything.
What that made is something I could text from anywhere. It kept a SQLite knowledgebase on the same machine so a conversation on a Tuesday knew what Monday's had been about, and because my projects were on that machine it could answer questions about my own work and my schedule from the actual source rather than from what I had remembered to tell it. It drafted posts, went and researched things, and, when I asked it to, deployed subagents against a real codebase while I was out of the house. What it is turning into now is the same idea pointed at Korrit rather than at me: a text message front end onto the tools and the database the studio actually runs on.
Details
- Role
- Designer and Engineer
- Team
- Solo
- Timeline
- Aug — Dec 2025
- Built with
- TypeScript, Node, SQLite, the Claude CLI
- Deliverables
- SMS assistant, local knowledgebase, landing site
- Status
- Ran daily in 2025, now being rebuilt for Korrit
Tech stack
- Channel
- SMS·Surge·Webhooks
- Runtime
- TypeScript·Node·The Claude CLI
- Memory
- SQLite·Local knowledgebase
- Host
- A PC at home
- Front
- Landing site·Consent and opt-out
Key design moments
SMS is the worst interface I could have chosen, which is the point
Every assistant tool I had tried wanted me to come to it, and the honest outcome of that is that I stopped opening it after a fortnight. Text messages ask nothing. There is no app to install, nothing to sign into, no settings, and it works on a locked phone and on the cheapest handset anybody owns. What you give up is everything a chat interface does for you. No formatting, no attachments, nothing to show that it is thinking, and a long answer arrives as three messages in whatever order the network feels like delivering them. A model that replies in headings and bullet lists is unusable over a channel that has neither of those things. So the medium made it answer the way a person texting answers, short and without ceremony, which is what I wanted from it in the first place and would probably not have had the discipline to enforce myself.
It was pointed at my terminal because that is where the subscription was
Wiring it to the CLI instead of the API bought two things. The small one is money: texting it forty times on a Tuesday cost exactly what texting it once cost, because the subscription is flat and I was already paying for it. The larger one is that a terminal is not a blank model. It was already sitting among my repositories with my files and my tools around it, and an API key turns up with none of that and has to be handed the world one call at a time. What it cost is that I was not using an interface. I was driving a program built for a person at a keyboard, and there is no contract there, nothing to version against, and no error worth catching. When the session ended, or the CLI changed under me, or the machine at home went to sleep, nothing failed loudly. The texts just stopped coming back, and an assistant that has gone quiet looks identical to one that has nothing to say.
The security model was that nobody else had the number
A machine awake at home with my projects on it, taking instructions from whatever arrives at a phone number, is either the best thing I have built or an unusually relaxed way to lose a codebase. The check on all of it was that the sender had to be me. A phone number is not a secret and a text message is not signed, and there was no second factor because there was no account and no audit because there was one user who already knew what he had asked for. What actually kept it safe was that it was worth nothing to anybody and nobody was looking, which is a real answer and not a good one. The other half is that texting is fire and forget. You send eleven words, put the phone back in your pocket, and by the time you read the reply the work has already happened. The jobs I gave it most were the ones that end in a draft rather than in something sent, and that was a habit rather than anything I had built.
Impact
There are no numbers on this one and I am not going to make any up. Nothing was logged, nobody was counting, and the only user was me. What I can say is that it ran every day from August to December, and that the measure of it was which things I stopped opening. The notes app went first, then most of the tabs I kept alive so that something could tell me what I was supposed to be doing. Being able to ask about my own schedule and my own work from a text message, on a walk, without unlocking anything, is a smaller feeling than it sounds and it is the whole reason the thing survived past the first week. The limit is the same as the achievement. Everything good about it depends on there being exactly one person it has ever had to work for, and on that person owning the machine it runs on.
Reflections
The model was the least interesting part of this. Almost all of the work was access and plumbing: getting a message off a carrier and into a process, getting a process to keep what it learned, and getting a machine at home to still be there when I texted it from somewhere else. What I would tell myself is that the thin channel was a feature and I should have trusted it earlier. Nearly every time I wanted to add a screen or a dashboard to this, the honest reason was that I did not believe a text message was enough, and it was.
The part of this nobody warns you about is the paperwork. A number that can text a person has to be registered before a carrier will carry it, and the registration wants a public page saying what you send and how somebody stops receiving it, which is the reason there is a consent box on the site at all. I went with Surge rather than Twilio because getting a number and a webhook answering took an afternoon instead of a day, and Twilio is what I would move to if this ever carries more than one person's traffic. None of that is the part you look forward to and all of it is load bearing: without it there is no number, and without a number there is no product, only a program on a computer in my room. The code for that version is still on the machine it ran on and has never been pushed anywhere, which is the thing I would actually go back and change. Pointing the same idea at Korrit breaks the one-user assumption on purpose, because a studio's tools and a studio's database have more than one person asking them questions, and the answers have to be right for somebody who did not write the system.