From Idea to App Store

Managing a horse involves an enormous amount of information

Feed plans change. Farrier and veterinary appointments need to be tracked. Health records and documents need to be accessible. Supplies run low. Expenses accumulate. Vaccinations expire. Yet much of that information still lives across:

I experienced this fragmentation firsthand while managing horses at my own ranch. What started as an observation became a product question:

That question became HorseKeeper.

The idea didn't begin with an app. It began in the barn.

Important information was scattered across physical and digital places: feeding instructions on whiteboards, veterinary information in paperwork, appointments on calendars, and reminders dependent on memory. The original research explored existing barn workflows through conversations with horse owners, observation of barn-management practices, my own experience managing horses, and analysis of existing equine-management products. A consistent pattern emerged:

The problem wasn't simply record keeping. It was being able to find and act on the right information when it mattered.

Focusing a broad vision on one clear user

The initial vision was broad. Horse care involves owners, barn managers, veterinarians, farriers, trainers and other service providers, and my early exploration looked at how a centralized platform might connect this larger ecosystem. But building a useful product required prioritization. Instead of trying to solve every problem in the equine ecosystem at once, I focused the first product around a much clearer user: the everyday horse owner. The goal became:

Mobile-first, because horse care doesn't happen at a desk

HorseKeeper needed to work differently from a traditional desktop application. Horse owners aren't sitting at desks when they need this information. They're standing in stalls, holding lead ropes, talking to veterinarians, buying feed, scheduling farriers, or checking something from the pasture. That made HorseKeeper mobile-first from the beginning. My early design principles included:

• Fast access to frequently used information
• Minimal navigation
• Large, accessible touch targets
• Quick data entry
• Clear visual hierarchy
• Interfaces usable in real-world barn environments

The original concept specifically considered one-handed use and visibility outdoors, because the product needed to work where horse care actually happens.

Start with the horse

One of the biggest design challenges wasn't an individual feature. It was information architecture. A single horse can have identification information, feed plans, veterinary records, farrier visits, documents, service providers, expenses, supplies, appointments and reminders. Multiply that across several horses and the complexity grows quickly. I designed the experience around a simple mental model:

Each horse becomes the anchor connecting the information associated with its care. From there, HorseKeeper organizes information into focused areas that make it easy to move between the horse and the jobs owners need to accomplish. This allowed a complicated care ecosystem to feel much more manageable on a small screen.

I didn't stop at prototypes. I built it.

This is where HorseKeeper became very different from a traditional portfolio project. Using React Native, Expo and Supabase, I took HorseKeeper from product strategy and UX design through front-end development, data architecture, testing and production release. AI-assisted development became part of my workflow, helping me move between product thinking, design and implementation while still making the product decisions myself.

That experience changed the way I think about design. I wasn't handing a specification to engineering. I had to experience the consequences of my own decisions:

• If a workflow was unnecessarily complicated, I had to build that complexity.
• If the data model didn't support the experience, I had to rethink it.
• If something broke, I had to fix it.

That created a much tighter relationship between design intent and technical feasibility.

A working iOS product for the everyday management of horses

The product allows owners to manage:

• Horse profiles centralize information about each horse.
• Feed plans organize feed, supplements and care instructions by horse.
• Health & records hold vaccinations, deworming, health information and important documents such as Coggins records.
• Services cover veterinarians, farriers, dentists, trainers and other providers, with the ability to contact them directly.
• Expenses track horse-related costs by horse, category and date.
• Supplies track hay, grain, bedding and other inventory owners keep on hand.
• Reminders & scheduling surface upcoming care, expirations, birthdays and recurring responsibilities.

HorseKeeper isn't simply a place to store information.

Owners can call or text service providers, share information, print schedules, receive reminders and access important records when they need them.

Launching the product changed the design process

Instead of asking only “Does this make sense in a prototype?” I could start asking “What are people actually doing?” I integrated analytics, monitored product stability, listened to user feedback and watched where people progressed or dropped off. Those signals influenced subsequent releases. Some ideas were expanded. Others were simplified. And some, including concepts from the original case study such as dedicated training logs, were intentionally left out of the current product and remain potential future opportunities. That distinction became an important part of product ownership:

The App Store wasn't the finish line. It became another feedback loop.

I continued improving the product through multiple production releases, adding and refining capabilities based on real-world use. Enhancements included improved navigation, supply management, recurring services and expenses, document sharing, expiration reminders, notification preferences, birthday reminders, printing schedules, upload feedback, friendlier error handling, automatic age calculations, and dashboard improvements.

Instead of treating launch as the outcome, I treated HorseKeeper as a living product.

From an observation in my own barn to a released iOS app

Since launch, the product has attracted real horse owners, generated ongoing usage, converted users to paid subscriptions and remained highly stable through continued releases.

For me, that is the most important outcome of the project. HorseKeeper gave me the opportunity to own the complete product lifecycle rather than one portion of it.

Building HorseKeeper changed the way I approach product design

Prioritization matters more than feature count

My original vision included owners, barns, trainers, veterinarians and a much broader set of capabilities. Building the actual product forced me to distinguish between what could be built and what should be built now.

Technical feasibility belongs in the design conversation

Building my own designs made engineering constraints tangible rather than theoretical.

Real behavior is more valuable than assumptions

Once people began using HorseKeeper, analytics and feedback became another form of research.

Shipping changes your perspective

A polished prototype can demonstrate an idea. A production product has to survive real users, real data, edge cases, errors, releases and continuous change.

See it in more detail

• The live product & work (gethorsekeeper.com) ↗
• Interactive prototype (Figma) ↗
• Design system & color tokens →