Daniel's got Ezra down with a cold, and after a trip to urgent care and a nebulizer treatment, he's back on a question he's circled before. He wants an Android app for logging the health parameters that actually matter to him — oxygen saturation, breaths per minute, that kind of thing — with photos and video when they're useful, and clean export ahead of a doctor's visit. And he's noticing something specific about the app landscape. The baby-tracking world has templates for everything. Diaper changes, breastfeeding sessions, sleep windows. But the moment you want to define your own variables, the category just... isn't there. His bigger argument is that this is true of personal tracking generally. One-size-fits-all apps fit nobody. What he actually wants is a general-purpose tracking framework. Define your own data structure, create workspaces for different purposes, record periodically, export. He points to Directus as the closest web analogue — a minimal scaffold over a backend and an API — but says the leap from that to a usable mobile interface is still enormous. His question is whether anything like this already exists, and if not, how to solve for it without building a custom app from scratch every single time.
The short answer is that the category exists, but the exact thing he wants — all four requirements in one app — doesn't. And that gap is interesting because it's not a technical gap. The pieces all exist separately.
What are the four requirements?
Fully user-defined schema, photo and video attachment, periodic capture with reminders, and clean export. There are apps that do three of the four. I couldn't find one that does all four on Android.
So what's the closest thing that actually shipped?
There's an Android app called Track and Graph. Free, open source, no ads, no accounts, data stays on the device. You define your own numerical values or simple occurrences, organize them into groups, and it builds line graphs and statistical reports. It even has a Lua scripting API for custom calculations. And people use it for exactly this kind of thing — one reviewer said it replaced about a dozen overly-specialized apps. Another uses it for health data including sleep, exercise, symptoms, medications.
Lua scripting. For a health log.
I know. It's a power tool wearing the clothes of a simple tracker. But here's the thing — it doesn't do photo or video. And the export is backup-oriented, not doctor-visit-oriented.
What about the other end of the problem? The export half?
That's where it gets lopsided. On iOS there's a whole mini-industry built around exporting health data into doctor-readable form. Apps like vitalina, Health Data to PDF, Health.md — a hundred plus health metrics, export in under two minutes, PDF or CSV or JSON. On Android that layer is much thinner. Which is probably why Daniel feels the gap more acutely than an iPhone user would.
So the export problem is solved on one platform and the custom-schema problem is solved on the other, and nobody has put them together.
Right. And there's a deeper reason for that, which I think is the most interesting part of this whole prompt. The closest conceptual match to what Daniel is describing was actually built. As a research project. In 2017.
Tell me.
It was called OmniTrack. An Android self-tracking system built by researchers at Seoul National University and Microsoft Research, among others. Their opening premise was almost word-for-word Daniel's thesis. They wrote that despite the vast number of available tools, it's still challenging for self-trackers to find apps that suit their unique tracking needs. And people are bounded by the tracking tools' initial design because it's difficult to modify or extend. So they built a system where you design your own data format. Number, text, time point, time range, choice, location, audio recording. The configuration interface was like a form builder — Google Forms or Survey Monkey. It had widgets, time-based triggers, data-driven triggers, automatic visualization based on the schema you defined. It could integrate with Fitbit and Google Fit and RescueTime.
That's the framework. That's the thing Daniel is asking for.
It is the thing. Published at UbiComp 2017, peer-reviewed, validated with users. And then the consumer version never shipped. The project site still says open beta coming soon. The open-sourced code is a research toolkit with about twenty-two stars on GitHub. It was designed, tested, and then effectively abandoned as a product.
So the answer to "does this exist" is yes, it existed, in a lab, and then the lab moved on.
And that's the pattern I keep seeing. The flexible tracker fails commercially. The rigid template app thrives. Diaper logging apps make money. OmniTrack gets twenty-two GitHub stars and a dead beta page.
Why do you think that is?
I think templates are cheap to add and they drive onboarding. You open a baby app and it says here are forty things you can track, tap the ones you want. You're productive in thirty seconds. A framework app says here is an empty schema, define your data types, and most people look at that and close it. The flexibility is the feature, but it's also the friction.
There's a second thing too. The template apps are selling reassurance. They're not really data tools. They're ritual tools. Logging a diaper change is not about the diaper. It's about feeling like you're doing the job of parenting. The data is almost beside the point.
That's a clinical observation, and I think it's right. The metrics Daniel wants to track are different. Oxygen saturation and respiratory rate are not rituals. They're diagnostic. He's not logging to feel like a good parent, he's logging because a doctor is going to ask him for numbers. So the template apps don't just fail to serve him, they're serving a different psychological function entirely.
Which explains why the category boundary is so sharp. Baby apps won't add SpO2 tracking because that's medical, not baby care. And medical apps assume a clinician is doing the logging, not a parent at two in the morning.
The two-in-the-morning part matters. Whatever Daniel ends up using, the capture surface has to be one-handed and nearly thoughtless. That's the real bottleneck. Not the schema, not the export. The moment of data entry.
Directus gives you the schema and the API instantly. It even has a native MCP server now, so Claude or Cursor can create collections and fields from a prompt.
That's the part that made me sit up when I read about it. Directus ships a native MCP server. You can literally describe your tracking schema to an AI and it creates the collections, the fields, the relationships, under the same role-based access control as a human user. That's Daniel's AI-assisted onboarding. It exists. It's just aimed at developers and operations teams, not parents.
And the interface you get is an admin grid. A very good admin grid. But it's not a mobile capture surface. You're not holding a baby in one arm and tapping oxygen saturation into an admin panel.
No, you're not. And that's the leap Daniel identified. Directus solves the data layer. It doesn't solve the two a.m. capture problem. And I don't think any no-code database tool does.
So what's the actual path for someone like Daniel? He's technical. He could build something. But he's also a parent with a sick kid, and the whole point is that he shouldn't have to.
There are a few real options. The first is just... use Track and Graph. Accept that photos and video live in the camera roll, and the export is a CSV you can format later. It gets him eighty percent of the way with zero build effort. The second is a self-hosted web app, something like HealthLog, which is a progressive web app that tracks weight, blood pressure, pulse, glucose, mood, medications, and oxygen saturation, with trend charts and a doctor-report PDF export. That's the export half done properly. But it's not user-defined schema in the full sense — it has a fixed set of health metrics.
And it's a web app, not native Android.
Right. A progressive web app can be installed to the home screen, but it's not the same as a native app for offline use and notifications. The third option is the one I think is actually most interesting given where AI is now.
Which is?
A thin native shell over a user-defined schema. Not a full app build. A single Android app that does one thing: you describe what you want to track, it generates a local SQLite schema, gives you a simple form for each metric, stores everything on-device, and exports to CSV or JSON. The schema generation could be a local LLM call or even a rule-based system. No cloud, no accounts, no backend.
That's a weekend project for someone with Daniel's skills. Maybe less with current tooling.
And here's the thing about the AI angle. There's a research paper from earlier this year called Text2Schema, and the authors built something called SchemaAgent. It's an LLM-based multi-agent framework that converts natural language requirements into relational database schemas. They explicitly note that schema design demands domain expertise, and research on directly generating schemas from text was basically unexplored. So the capability Daniel is imagining — describe what you want to track, get a sensible schema — is being formalized in the literature right now. It's just not in a consumer product yet.
So the pieces are: Track and Graph proves the custom-metric mobile app works. OmniTrack proved the full framework concept works. Directus proves the AI-assisted schema layer works. Text2Schema proves the natural-language-to-schema pipeline works. And nobody has assembled them.
That's the state of things. The category is populated with partial solutions. The full framework doesn't exist as a shipped Android app. And I want to be careful here, because Daniel's instinct was that there's a gap, and he's right about the specific gap, but the gap is not "no general-purpose trackers exist." It's that no single app combines all four requirements. And the reason is probably commercial, not technical.
The template paradox.
The template paradox. Templates are cheap to add and they market well. A flexible framework is hard to explain in a Play Store listing and hard to onboard users into. So the market produces a hundred diaper loggers and zero OmniTracks.
There's something else in Daniel's prompt that I want to pull on. He says one-size-fits-all apps are a bad fit for every use case. Not just baby tracking. Personal health, DIY projects, anything where you're logging metrics. And he's right, but I think the reason is deeper than he stated.
Go on.
He frames it as a software problem. I think it's actually a taxonomy problem. When you use a template app, you're not just accepting the app's data model. You're accepting the app's theory of what matters. The diaper app has a theory of baby care, and it's a theory built by a product team that needed to ship something. When your own theory diverges — when you think respiratory rate matters more than sleep windows — the app has no way to express that. So you end up fighting the taxonomy.
That's exactly what the ACM Interactions piece from a few years ago found. When self-tracking tools don't satisfy tracking needs, people resort to building their own custom trackers if they have technical skills, or they fall back to spreadsheets and paper notes, or they give up tracking entirely.
And Daniel is in that first group. He has the technical skills. The question is whether he should have to use them for something this basic.
Let me ask you the uncomfortable question. Is this worth building? Or is the spreadsheet the right answer?
For a single sick-kid episode, the spreadsheet is absolutely the right answer. A shared Google Sheet with columns for timestamp, oxygen saturation, breaths per minute, notes, and a photo link. Done in ten minutes. Exportable, shareable, works on any device.
But it's not a framework.
It's not a framework. And Daniel's point is that he doesn't want to build a new spreadsheet for every tracking task. He wants a reusable pattern. The sheet is a stopgap, not a solution.
So what's the reusable pattern that actually gets him there without a custom app build every time?
I keep coming back to the local-first idea. A single Android app, maybe built with something like Jetpack Compose, where the user defines a small schema — metric name, data type, unit, optional photo field. The app generates a local database, a simple form, and a CSV export. No backend, no sync, no accounts. The schema definition could even be a JSON file you write once and import. That way the app itself is dumb and reusable, and the schema is the thing you change.
That's OmniTrack minus the research overhead.
It's OmniTrack minus the integrations and the triggers and the auto-visualization. Just the core loop: define, record, export. And I think that core loop is missing from the Android ecosystem right now.
What about the AI-assisted onboarding? Daniel floated it as a maybe — he said bundling AI is probably not even necessary. Do you agree?
I think he's right that it's not necessary. For a schema with five fields, you don't need an LLM. You need a form with five rows. The AI becomes valuable when the schema gets complicated — relationships between entities, conditional fields, calculated values. For logging a sick kid's vitals, that's overkill.
But for the general framework, the AI onboarding is the thing that makes it accessible to non-technical users. That's the difference between a tool for Daniel and a tool for everyone.
And that's where Directus with the MCP server is interesting. You could imagine a version of this where the user describes their tracking need in plain language, the AI generates the schema, and then a mobile app renders a capture form from that schema. The pieces all exist. The integration doesn't.
So the honest answer to Daniel's question is: the closest shipped thing is Track and Graph, the closest conceptual thing is OmniTrack, the closest data-layer thing is Directus, and the thing he actually wants doesn't exist yet.
That's the answer. And the reason it doesn't exist is not that it's hard to build. It's that it's hard to sell.
Which is why it might be a perfect open-source project.
It might be. A general-purpose tracking framework for Android. Define your schema, record periodically, export cleanly. No accounts, no cloud, no templates. The templates are the user's own.
The thing that strikes me about this whole conversation is that the technical barrier is essentially gone. Ten years ago, building a custom tracking app meant real work. Now the schema generation is a solved problem, the local database is a solved problem, the export format is a solved problem. What's left is a design problem. How do you make the capture surface fluid enough that a parent at two a.m. with a sick kid actually uses it?
And that's the part nobody has cracked. Not Directus, not Track and Graph, not the research prototypes. The two a.m. test.
The two a.m. test.
You're holding a baby. You have one hand. The lights are dim. You're tired. You need to record three numbers and maybe a photo. The app has to be ready for that moment before you even open it. A capture surface that already knows what you're tracking and just needs the numbers.
Which argues for the schema being defined ahead of time, when you're calm and awake, and the capture being nearly instant.
Define when you're clear-headed. Record when you're not. That's the whole design.
And the template apps actually do this part well. They're optimized for the capture moment. They just don't let you define what you're capturing.
So the ideal app is a template app where the templates are user-defined. Which is... a framework. Which is what Daniel asked for.
We've gone in a circle.
We've gone in a circle because the answer is the same thing he proposed. The question is just whether anyone has built it.
And the answer is no, not fully.
Not fully.
Let me ask you something else. The photo and video requirement. How hard is that to bolt onto an existing solution?
Not hard technically. Any app with local storage can attach a photo to a record. The hard part is the export. If you're exporting to CSV for a doctor, photos don't fit in a CSV. You need a folder of images with a manifest, or a PDF with embedded images, or a ZIP. And that's where the export half gets complicated.
So the photo requirement actually drags the export requirement up in complexity.
It does. A pure numeric tracker can export to CSV trivially. Add photos and video, and suddenly you need a packaging format. Which is probably another reason the full combination doesn't exist. Each requirement individually is easy. Together they compound.
What would you actually tell Daniel to do today, with Ezra already sick and the doctor's visit presumably soon?
Today, use a shared spreadsheet. Or install Track and Graph and define the three metrics he cares about — oxygen saturation, breaths per minute, temperature maybe. Keep photos in the camera roll with a timestamp. Export the CSV when he needs it. That solves the immediate problem in under an hour.
And longer term?
Longer term, if he wants the framework, he's probably the person to build it. Or at least to spec it out and see if there's an existing project to contribute to. The gap is real. The pieces are all open source. The missing thing is integration and a decent capture UI.
And the AI-assisted onboarding is the cherry on top that makes it accessible to non-technical users.
Which is the difference between a tool for Daniel and a product for everyone else.
Hilbert: I've been running something like this for eleven years.
Running what?
Hilbert: A custom tracker. A notebook and a set of index cards. I worked a job in the mid-seventies where we had to log equipment temperatures every four hours, and I kept the habit. Every time I need to track something new, I make a new card. Columns across the top, dates down the side. Card goes in the kitchen drawer. When the doctor asks, I hand him the card.
That's... a paper spreadsheet.
Hilbert: It's a paper spreadsheet. Works without a charger. Works with one hand. Works at two in the morning. The photo is a Polaroid I staple to the back if it matters.
What do you track?
Hilbert: Blood pressure. Weight. How much rain the gutters catch. Whether the furnace kicks on. I had a card for the dog's seizures for a while. Vet liked it.
The vet liked the index cards.
Hilbert: Vet said it was better than the apps people bring in on their phones. Legible. No login screen.
The export format is the card itself.
Hilbert: The export format is the card. I've got a shoebox full of them. My whole medical history, furnace history, dog history. Alphabetized by topic. It's a mess, but it's my mess.
You know, there's something instructive in that. The index card is the ultimate user-defined schema. You draw the columns you need. No template. No account. No export step because the artifact is the record.
Hilbert: The artifact is the record. That's right. These app people build a database and then have to figure out how to get the data out of it. I just have the card.
And the AI-assisted onboarding is you standing in the kitchen deciding what columns to draw.
Hilbert: I don't need an AI to tell me what a fever log looks like. I've seen a fever.
The point stands, though. The index card solves the capture problem and the export problem simultaneously because there's no separation between the data and the artifact. The app world separated those two things and has been trying to rejoin them ever since.
Hilbert: Sounds like a lot of work to replace a card.
The card doesn't graph the data.
Hilbert: I can graph it on graph paper if I care. I usually don't care. The doctor cares about the numbers, not the line.
That's actually a fair point. For a doctor's visit, the raw numbers and the trend are both useful, but the raw numbers are the priority. A CSV export is just a digital index card.
And yet the app world has spent a decade building dashboards.
Hilbert: Dashboards are for people who like looking at dashboards. The doctor wants the numbers. The parent wants to go back to sleep.
The two a.m. test again.
Hilbert: I've done the two a.m. test. The card passes. The phone with the app that needs me to find the right screen and type in a value with the keyboard... that's a fail.
So the design problem is real, and the index card is the benchmark.
Hilbert: The index card is the benchmark. If your app isn't faster than a card, it's worse than a card. Most of them are worse than a card.
That's the line I'm going to remember from this episode.
It's a good line.
Hilbert: It's just true.
The export side, though. Daniel wants to hand something to a doctor. A card works for that. A CSV works for that. A PDF with embedded photos works for that. The app world has made export an afterthought when it should be the primary output.
Because the app world monetizes retention, not export. If the data leaves the app, the user might leave too.
Hilbert: I don't have that problem. The card leaves the drawer and comes back when the doctor's done with it.
The card has no churn problem.
The card has no business model at all.
Hilbert: The card doesn't need one. That's why it still works.
I think what I take from this is that the framework Daniel wants is not actually a technical challenge anymore. The schema generation is solved. The local storage is solved. The export formats are solved. The thing that remains is the design discipline to make the capture moment as fast as a card. And that's a very different skill than building a database.
It's the difference between a tool and a product. A tool does the job. A product gets used.
Hilbert: The card is a tool. The apps are products. That's why the apps have templates and accounts and dashboards and the card just has columns.
And yet the card can't sync to a phone or graph a year of data or remind you to log.
Hilbert: I've got a kitchen wall for reminders.
The kitchen wall is not a push notification.
Hilbert: It's better. It doesn't buzz.
There's a version of this that's a hybrid. A digital card. You define the columns once, the app gives you a dead-simple capture screen, and the export is a PDF that looks like the card. No dashboards, no accounts, no gamification. Just the artifact.
That's the thing I'd want to build if I were Daniel.
Hilbert: Then build it. It's a weekend. The card took me five minutes.
The card took you five minutes because you already knew what you wanted to track. The app has to help someone who doesn't.
Hilbert: That's the AI part. Fine. Tell the AI what's wrong and it draws the columns. Then the app just shows the columns.
So the AI is for the setup, and the setup is a one-time cost, and the capture is the card.
That's the shape of it. And it's the shape of OmniTrack, which had exactly this architecture in 2017. Schema definition up front, simple capture after. It just never shipped.
The research was right. The product was missing.
Hilbert: The product is a card. Always has been.
I keep thinking about why OmniTrack died. It wasn't that the idea was wrong. The paper was well-received. The user studies showed people liked defining their own trackers. But the team was academic, and the product never got the polish or the distribution. The template apps had marketing budgets and app store optimization. OmniTrack had a GitHub repo.
So the flexible tracker loses to the rigid template not because it's worse, but because it's harder to explain in a thirty-second app store listing.
"Track your baby's diapers" is a sentence. "Define your own data structures for arbitrary personal metrics" is a paragraph. And the app store rewards the sentence.
Which is why Daniel's instinct about AI is interesting for a different reason than he stated. The AI isn't just for schema design. It's for the app store listing. If the AI can take a user's plain-language description and generate the tracker, then the app's pitch becomes "describe what you want to track and we'll build it." That's a sentence.
That's a very good sentence, actually.
The AI collapses the explanation problem as well as the schema problem.
And that's the thing that wasn't available in 2017. OmniTrack had the form builder, but the user still had to know what a data type was. With an LLM, the user just says "I need to log my kid's oxygen saturation and breathing rate before a doctor's visit" and the system draws the columns. The onboarding friction disappears.
So the missing piece in 2017 was the natural-language interface, and that's exactly what's available now.
Which means the moment for this app is actually now, not then. The research was ahead of its time. The technology caught up.
The question is whether anyone will build it.
Or whether Daniel will.
He does have a sick kid and a GitHub account.
The two great motivators.
Alright, I want to land one thing for the cutting-room floor. The Directus security note from earlier this year. Security reports to Directus jumped sixfold in the first half of the year, but the number of valid reports sharply decreased. Which tells you the platform got popular enough to attract attention, and the attention was mostly noise. That's the sign of a project that's crossed into the mainstream.
And it's relevant because Directus is the thing Daniel pointed to as the closest web analogue. The fact that it's now big enough to attract spurious security reports means the data-layer problem is solved at scale. The gap is not the backend. It's the two a.m. Capture surface.
And the index card.
And the index card.
One forward-looking thought. The Text2Schema work from this year suggests the natural-language-to-database pipeline is maturing fast. The framework app might not need a company to build it. It might just need a motivated parent with a sick kid and a few hours.
That's a nice place to land. The tool that doesn't exist yet might be built by the person who needs it most.
Thanks to our producer Hilbert Flumingtop for keeping the show running, and for the index card system we're all going to be thinking about now.
This has been My Weird Prompts. Email us at show at my weird prompts dot com if you've built a general-purpose tracker or if you have strong feelings about index cards.
We'll be back soon.
