Last year I had to fly across the country with three cats. Airlines require a health certificate for each one, issued within 10 days of the flight. They also want proof of current rabies vaccination and for you to have it on hand... just in case. The experience sucked as much as you could imagine.

I spent two days before the flight digging through Gmail and calling my vet office for my records. It was exhausting. That's part of the origin story.

As any engineer does, I spent months reverse engineering this problem.

Why I built the upload flow first

Most app projects start with the home screen or the nav structure. I started with document upload and record extraction. My reasoning: if that part doesn't work well enough to be genuinely useful, there's no app. The rest is just scaffolding around a broken core.

The flow sends a PDF or photo to a backend, extracts the structured data, then shows it to the user to review before anything gets saved. That review step matters a lot. The last thing I want is an app that confidently saves the wrong vaccine date. So nothing goes into the vault without the owner confirming it first. You will see a lot about this human in the loop idea.

It took longer than I expected to get this right. Getting it mostly right was fast. Getting it to the point where I'd trust it for my own cats took another few weeks.

The stack

The app is React Native with Expo. I picked it because I wanted one codebase that could eventually ship on Android without a full rewrite. Hot reload during development is also genuinely fast once you get past the initial setup.

The backend is Node.js with Express and Postgres. Auth, database, and file storage all run through Supabase. I thought about rolling my own auth for about 20 minutes, then remembered the last time I did that and moved on. Supabase got me email/password login, password reset, email verification, and Google sign-in in an afternoon.

Document processing goes through a cloud vision API. It extracts structured data from vet PDFs and images well enough that I trust it for my own cats.

RevenueCat for subscriptions. It handles receipt validation, entitlement checks, and the webhook side in a way that lets me not think about it. Worth the cut.

The stuff that took way longer than the code

I thought building the app would be the hard part. It wasn't. The hard part was everything around it: App Store listing, screenshots, privacy policy, terms of service, the marketing site, support flows, getting anyone to know the thing exists.

Writing a privacy policy that actually describes what your app does with data is not fast. I read privacy policies for probably 15 other apps to understand how to write one that was accurate and not just meaningless boilerplate. Same with the terms. Same with the App Store description, where you have 4,000 characters to explain why someone should trust you with their pet's medical records.

If I did this again, I'd start the legal pages and marketing site at the same time as the app, not two weeks before launch.

Where I wasted time

I built a four-screen onboarding walkthrough. It explained features, showed UI previews, the whole thing. My first real test users skipped all of it. Every single screen. They just wanted to add a pet. I cut it to two screens and stopped caring about it.

I also built out edge case handling for about a dozen document formats before I had a single real user. I have still not seen most of those formats uploaded. That's weeks I could have spent on things people actually needed.

The one thing I'd actually do the same

I set a ship date and kept it. The app that went live was not the app I originally imagined. It was smaller, simpler, and missing things I thought were essential. But it was real, it worked, and people could use it.

I've watched other solo projects die in the polish phase. Not because they ran out of good ideas, but because the finish line kept moving and eventually the motivation runs out. A working v1 is better than a perfect v0 that never ships.

Where it actually stands

I had around 10 beta users before launch. Three days after going live on the App Store, I had dozens of real people using it. For a solo launch with no marketing budget, that felt like something.

Now I'm sitting with the classic problem: I built a thing, but who exactly are my users? People who download a pet records app probably care about their pets. But caring about your pets is not the same as being the kind of person who proactively calls the vet office and asks for a full records transfer. Most people aren't that person until something forces them to be. A move, a new vet, a flight with three cats.

That's the hard thing about this app. The value is directly proportional to how proactive the user is. You get a lot out of it if you actually go get your records. You get nothing if you download it and wait for value to appear. Nudging someone toward a behavior change (calling a vet, asking for paperwork) is a different problem than building good UI. I don't have a clean answer yet.

The next few posts here will be about what I try and whether any of it works. If you've hit a similar wall with an app that depends on user proactiveness, I'd like to hear how you approached it. support@mypetvault.org.