{
  "path": "/posts/2026/personal-software/index",
  "site": "at://did:plc:mracrip6qu3vw46nbewg44sm/site.standard.publication/self",
  "$type": "site.standard.document",
  "title": "Personal Software",
  "updatedAt": "2026-02-21T00:27:02.906Z",
  "publishedAt": "2026-02-18T21:22:12.070Z",
  "textContent": "Since agents became good enough to write low-stakes software without you needing to validate the code they write yourself, I've been experimenting with several different ways to build tools for myself on demand.\nIf I'm working on a PC, the overhead required to scaffold a CLI, webapp, or even native app is pretty low.\nI start an agent, prompt it to create a project, then use it as I need it.\nThese projects include everything from single-use tools to personal, bespoke software like the writing app Tarn that I am using to write this post.\n\nMy process up until this point has almost always relied upon having access to a PC, to install dependencies, deploy infrastructure, or do builds.\nAnd this was awesome.\nI built tools for writing and tracking notes this way.\n\nA webapp might look something like this.\n\nAnd a CLI like this.\n\nThe at-my-PC limitation wasn't too much of a problem until I built and began interacting with a stateful agent more regularly on Slack.\nWith straightforward access to an agent with a VM on my phone, writing software away from the keyboard became possible.\nHowever, getting the software into a usable state all from a phone was still a challenge.\nI was juggling tools and management consoles and it felt like a struggle.\nNot something I could do trivially.\n\nThe landscape for products for this type of software-building-agent is vast, but everything I've read about or tried missed one thing or another.\n\nWhat I wanted\n\nAgent-driven development\n\nI write a description of the solution (mostly from my phone), the agent writes, commits, and deploys the software.\n\nData privacy\n\nCloud software uses cloud datastores.\nCloud datastores require authentication. If the webapp runs on the public internet, the data store is also exposed to public internet traffic.\nI didn't have the desire to roll my own authentication and/or run in a VPC.\nI tried with basic auth, but still didn't like having personal data protected by just a thin security layer on the public internet, and with agent-coded software, who knows what corners I was cutting.\n\nA native interface (or close)\n\nWhen I've built apps with basic auth, I mostly solved this preference by building PWAs.\nI could save these to my homescreen on my phone and I can search for and launch them as apps rather than another browser tab.\nWith basic auth, I would stay logged in and that worked reasonably well. However, with each new app, I had to save a new app to my home screen.\nFor disposable apps, I have to clean those up.\nIt was more maintenance than I wanted.\n\nIt's the data\n\nMost of the software I write isn't sensitive - just the data stored alongside it.\nWith my prior approaches, the webapps and their data were served from a similar place.\nThis was a benefit because I could access the data across all my devices but a drawback due to the suboptimal authentication approach and data security posture.\n\nHaving my data available cross-platform is really nice though.\nIt sort of makes or breaks the experience, which was why moving away from the basic auth approach was so difficult.\nI could have just used localStorage but then my data would be stuck in a single browser on a single device.\n\nWith localStorage, each device has its own isolated data\n\nWith a cloud datastore, both devices share the same data but need authentication so that data isn't accessible to the public internet.\n\nEnter CloudKit\n\nIf you use Apple products, you're familiar with the data syncing across devices that usually just works.\nIf you use the Notes app, your notes sync to all your devices.\nIt's difficult to beat, and it's private.\nThe data is not available to the public internet - it's behind iCloud login.\nIf you build on top of Apple's CloudKit framework, you can use CloudKit and this private data syncing capability with iCloud for your own apps.\n\nThis is all fine and good, but it's not easy for an agent to scaffold and build a Swift app, and even if it could, it can't automatically build and install it to my device when I am on my phone away from my PC.\n\n\"Framing\" my apps\n\nCloudKit was actually what I was looking for from a data perspective.\nI can access my data from my devices via private APIs.\nThe Swift CloudKit APIs allow you to read and write from this personal data namespace.\nNow I just needed to connect the webapps my agent builds and deploys with this personal data layer.\n\nThe solution was a single Swift app pointed at a public manifest file.\nThe manifest file defines the list of \"apps\" available in the Swift wrapper app, which I call frame.\nThis manifest is a simple JSON file that describes where the app lives and how to render it in the frame app list.\n\nHere is an example manifest.json\n\nThat \"Buy List\" app is a regular webapp - a single file with HTML, CSS, and JS, plus fuse.js via CDN for search.\nThe interesting part is how it handles data storage.\n\nThe Swift app injects a JavaScript bridge (window.Frame) into each web view at document start.\nThe bridge exposes an async key-value storage API (save, load, list, delete) that routes through WKScriptMessageHandler to CloudKit on the native side.\nWebapps get private, cross-device data sync via iCloud without knowing anything about CloudKit via the frame app.\n\nThis approach works because the webapp checks whether window.Frame is available and uses it if so, otherwise it falls back to localStorage.\nThis means I can develop and test the app in a regular browser, and it just works inside the frame Swift app with CloudKit syncing.\n\nThe workflow now\n\nWith the frame app and an agent running, the whole process collapses to a few minutes from my phone.\n\nI describe what I want in Slack. \"Add a buy list app to Frame that tracks items I purchase with fuzzy search.\" The agent scaffolds the webapp, wires up the window.Frame storage abstraction with localStorage fallback, commits, and pushes.\nGitHub Actions deploys the site to Cloudflare Workers.\nThe agent updates the manifest as well (a separate repo) and GitHub Actions deploys that as well.\nFinally, the frame app displays the newly deployed app in the list.\n\n!Frame App\n\nI open the frame app on my phone, the new web app is in the list, and the data syncs to my Mac.\nI never touched a PC.\n\n<div style=\"display: flex; gap: 1rem; justify-content: center;\">\n<div style=\"flex: 1; max-width: 375px;\">\n\n!Frame iOS\n\n</div>\n<div style=\"flex: 1; max-width: 375px;\">\n\n!Frame Buy List\n\n</div>\n</div>\n\nMy new status quo\n\nThis approach is now my preferred way to build personal software for simple data management and tracking of things.\nI send my agent a message from my phone and it builds me a personal webapp with private, cross-platform data persistence using my iCloud account.\nWhen I am done with an app, I have the agent clean up the manifest and delete the code.\n\nTo reiterate, this is a hyper-personalized process I've landed after some iteration, using my preferred stack on Cloudflare, a personal, stateful agent (that I will probably write about soon) and purpose-built agent skills I assembled so that when I ask my agent for a \"frame app\", it knows about and performs all of the steps above.",
  "canonicalUrl": "https://www.danielcorin.com/posts/2026/personal-software/index"
}