HorseGirl

Your horse is a 600 kg athlete that needs care like a newborn. Horsegirl tracks every ride, runs feeding, meds and barn tasks, and calls for help if you fall. Even with no signal.

Comment

Inspiration

For almost a year, my girlfriend had been asking me to build this app.

She always felt that there was no single app that truly understood everything a horse girl needs. There are apps for recording rides, managing stable tasks, tracking health, or planning training, but each one focuses on a single part of the experience. Nothing connects the rider, the horse, and their shared history in one thoughtfully designed place.

I originally wanted to participate in Shipaton last year, but the app I was building was far too large and poorly scoped. It was also my first mobile app, so every part took much longer than I expected. I kept building, but I never reached the point where I felt ready to submit it.

This year, I wanted to approach things differently. Instead of waiting until every part of the vision was complete, I decided to start with a strong foundation, ship it, and improve it alongside real riders. Shipaton gave me the push to finally build the app my girlfriend had been describing for so long.

We started with the experience that mattered most to her: recording rides and connecting them to the actual horse. From there, Horsegirl grew into a place where riding, training, health, feeding, equipment, weather, and everyday care could support each other instead of living in separate apps, notebooks, screenshots, calendars, and group chats.

We did not want to build another database that happened to contain information about horses. We wanted to create a connected companion that remembers what happened, makes today's responsibilities clear, supports better decisions, and helps horse and rider improve together.

Most importantly, we wanted to create the app she had always wished existed. Shipaton was the moment we finally decided to make it real.

What it does

Horse care rarely happens in one place. Rides live in a tracking app, training plans in saved posts and screenshots, health notes in a notebook, and daily care in calendars and group chats. HorseGirl brings that fragmented routine together around the one thing every decision affects: the horse.

Each horse gets a living profile that connects their care, health, feeding, equipment, training, and riding history. Riders can plan recurring stable tasks, manage medication and feeding schedules, keep care records, coordinate with the people who help look after their horses, and get weather-aware guidance for the day ahead. HorseGirl turns those plans into a clear daily routine, so the rider can see what needs attention without rebuilding the same context in several different apps.

When it is time to ride, HorseGirl becomes a full ride tracker. It records the route, distance, duration, pace, elevation, speed, and time spent in walk, trot, canter, and gallop. Riders can replay a ride, review trends and personal bests for each horse, export the route, and use fall and prolonged-standstill detection for extra reassurance when riding alone.

HorseGirl also turns training ideas into sessions riders can understand, perform, and improve. Our expanding library of 1,400 structured exercises will cover different goals, disciplines, and difficulty levels. Instead of relying on a paragraph or a static arena sketch, every exercise has a visual preview that animates the intended path, direction, timing, arena letters, and obstacles. The rider chooses a horse, studies the pattern at their preferred speed, and records the session directly in the app.

After training, HorseGirl compares the recorded path with the intended pattern, shows both paths together, scores the session, tracks personal bests, and provides focused coaching feedback. If indoor-arena GPS becomes too weak for an honest path comparison, the app switches to an explicitly labeled estimate based on movement, turns, rhythm, and smoothness rather than pretending the location data is accurate.

Everything is designed for real stable conditions. Core records and actions remain available when reception is poor; changes appear immediately and sync in the background when a connection returns. The result is not just a ride tracker or a horse-care checklist, but one calm, visual place to answer three questions: What does my horse need today? What should we work on next? Are we improving together?

How we built it

We built Horsegirl as a Flutter app for iOS and Android, with Riverpod managing application state and a custom component system defining the visual language. We used Flutter not just to share code, but to keep interactions, animation, typography, and layout consistent across the entire product. Many of the most important experiences, including ride playback, gait charts, training paths, arena previews, image editing, and sync feedback, are drawn and animated specifically for Horsegirl rather than assembled from generic screens.

Local first from the beginning

Stables frequently have weak or unreliable reception, so the mobile app reads its core data from a local SQLite database instead of waiting for the network. When a rider completes a task, updates a horse, changes a feeding plan, or saves a ride, the change appears locally first. Horsegirl then writes a durable operation to an outbox and synchronizes it with the server in the background.

Each operation receives an idempotency key so retrying it cannot create a duplicate. Multiple pending edits to the same record are reconciled, deletes remain recoverable until the server confirms them, and failed operations stay queued for a later attempt. A connectivity coordinator automatically retries pending work when the device comes online. The interface also exposes pending and failed states so riders can tell whether an update has reached the cloud. This same architecture lets one account stay consistent across multiple devices without making a stable-side action feel dependent on network speed.

Backend and connected services

The backend is built with Next.js and TypeScript. Prisma manages a PostgreSQL data model for horses, workspaces, tasks, rides, care records, equipment, feeding plans, and training sessions. Clerk handles authentication and shared workspace identity. Photos and other files are uploaded through signed URLs to private, encrypted, versioned Amazon S3 storage rather than passing large files through the API server.

OneSignal delivers task, team, and weather notifications. PostHog gives us product analytics and feature flags, which lets us release larger features to controlled groups and measure how people actually use them. We use OpenAI for specific personalized explanations and coaching, but never make it a hard dependency. Important features have deterministic fallbacks when an AI request fails.

Ride tracking and safety

Ride recording combines continuous GPS with device motion data. From those signals, Horsegirl calculates the route, distance, speed, elevation, pace, and time spent in walk, trot, canter, and gallop. Recording continues outside the main screen through platform-specific background behavior. Riders can also connect rider heart-rate data through HealthKit or Health Connect and pair a compatible Bluetooth monitor for the horse as a separate signal.

Fall and prolonged-standstill detection combine motion and location rather than treating every pause as an emergency. Completed rides are transformed into replayable maps, charts, personal records, and editable sharing visuals. The share editor was built as a real composition tool so riders can choose the route presentation, crop imagery, adjust visual elements, and create something they genuinely want to post.

A visual training system that can scale

For training, we created a server-owned course format that describes an ideal path inside a normalized 20 by 40 meter arena, including direction, arena letters, timing, and obstacles. A custom browser-based editor lets us draw and refine exercises, while Flutter painters turn the same structured data into animated previews inside the app. Because courses live in the backend catalog, we can improve an exercise or add another one without waiting for a new App Store release. This is the foundation of our pipeline toward 1,400 visual training exercises.

During a session, Horsegirl records GPS and motion data. When GPS is reliable, we resample the recorded and ideal paths and use a best-fit geometric comparison to account for position, rotation, scale, direction, and the starting point of closed patterns. The result screen can then overlay what the rider actually did on the intended path.

Indoor arenas often have poor GPS, so we built a second scoring mode instead of forcing unreliable coordinates into the same calculation. It estimates turns, rhythm, and smoothness from device motion and labels the result clearly as an estimate. Coaching feedback receives only the derived scoring values, not the rider's raw location history. If AI feedback is unavailable, a rules-based coach still provides useful guidance from the same measurements.

RevenueCat and the paid experience

RevenueCat manages Horsegirl's subscriptions, paywall, purchases, and Pro entitlement state. We align the RevenueCat customer identity with the rider's Clerk account so access follows them across devices. The app uses RevenueCat's cached customer information for a responsive account experience, while an explicit refresh can reconcile a purchase or entitlement change without incorrectly replacing a known Pro state during a temporary network failure.

We designed the paid experience around continuing value rather than arbitrary limits. The goal is to keep essential horse organization and ride recording useful for every rider, while Pro supports the deeper safety, training, personalization, and horse-specific insight that Horsegirl can provide because all of those parts exist in one connected system.

Challenges we ran into

Protecting our launch with no time left

We started building Horsegirl on August 5, after Shipaton had already begun. That left us with less than two months to turn an idea into a product riders could trust, publish it, and find the first people willing to use it. We were not only racing a deadline; we were building an app that stores information about real horses, care routines, medication, training, and rider safety. We did not want the deadline to become an excuse for releasing something we would not feel comfortable using ourselves.

That meant submitting to Apple later than we originally hoped: September 17 at 3:56 a.m. local time. A previous app had taught me, through a long and difficult review process, how many small omissions can hold up a release. I went back through those old review conversations and used them as a checklist for Horsegirl: permissions, account behavior, privacy information, reviewer access, purchase flows, and the details needed to understand the app. Even so, the first review was not approved until around September 26. With our public launch promised for September 30, the remaining margin had almost disappeared.

Then we found the kind of issue every developer fears just before launch. In production, a rider could complete onboarding, enter their horse and stable details, and create an account, but the most important information they had just provided was not saved. The same flow had worked in staging. Releasing it would have meant welcoming riders with a long, personal onboarding process and then losing the reason they had completed it.

At the same time, our launch videos were gaining momentum. People repeatedly asked where they could download the app and when it would finally arrive. We had publicly committed to September 30, and my girlfriend was the face of the project. I was not only afraid of missing the date; I was afraid that she would receive the disappointment and criticism for a technical failure that was mine to solve.

I stopped the feature work already prepared for the next update and focused on the onboarding failure. Once it was fixed, another risk remained: would Apple review the new build before launch? On Tuesday, September 29, I submitted the fix together with the changes already prepared, briefly made the previously approved build available so its replacement could enter review, and requested an expedited review for the critical onboarding issue. Apple approved it in under two hours. The corrected version was ready for our announced launch, and not one user experienced the broken onboarding.

That week reinforced an uncomfortable but important lesson: shipping is not the moment a build compiles or even the moment Apple approves it. Shipping means protecting the first experience people trusted us enough to wait for, and being willing to abandon planned feature work when that experience is at risk.

Making offline-first behavior genuinely reliable

“Works offline” sounds like a feature. In practice, it became one of the largest engineering challenges of the entire project.

Stable connectivity is unreliable, so Horsegirl could not simply wait for a server before showing that a task was completed or a horse record was updated. Every change had to appear instantly on the device, remain safe if the app was closed, and synchronize later without losing data or creating duplicates. It also had to behave correctly when the same account was active on more than one device.

Almost every week exposed a new edge case. Some records failed to reach another device. Local and server schemas drifted apart. Superseded operations remained in the sync queue forever. A failed write could block newer work behind it, and two quick edits to the same record could arrive in the wrong state. Deletes were especially difficult because removing something locally before the server confirmed it could make recovery impossible.

We rebuilt this into a shared local-first system: changes are written to a local database immediately, durable operations are queued with stable idempotency keys, repeated edits are reconciled safely, failures remain retryable, and pending work is pushed again when connectivity returns. The UI also exposes pending or failed synchronization instead of pretending every change has already reached the cloud. Getting those details right took most of the Shipaton period, but it changed Horsegirl from an app that merely cached data into one designed for the conditions in which riders actually use it.

Finding the language in which we sounded like ourselves

Building an audience in the same short window was a different kind of challenge. We initially created our videos in English because it offered the largest potential audience. In practice, that theoretical reach did not help if the content felt rehearsed. My girlfriend and co-creator did not feel fully comfortable speaking English on camera, and remembering scripts while trying to sound natural made publishing slow and the videos less personal. Growth stayed mostly flat.

After two or three weeks, we switched to our native German. The potential audience became smaller, but the connection became much stronger. She could speak naturally, show more personality, and respond to riders without translating herself first. Growth began to pick up, and people explicitly told us that she felt more authentic and relatable in German.

That decision changed how we think about distribution. The biggest audience is not automatically the right first audience. For an app built around trust, care, and a very personal sport, authenticity was more valuable than maximum theoretical reach. [Add before-and-after figures for views, followers, engagement, waitlist sign-ups, or installs so the pivot is demonstrated rather than only asserted.]

Accomplishments that we're proud of

We built the audience while we built the app

One of our proudest accomplishments is that HorseGirl did not launch into silence. While I was building the product, my girlfriend was building a community around it.

We started the HorseGirl Instagram account on August 2 with no existing audience. By September 30, it had gained 2,183 net followers. In those first 60 days, our content received 37,301 views from 9,978 viewers and generated 2,415 interactions. Almost half of the views came from people who did not already follow us, which showed that the idea was reaching beyond our initial circle.

TikTok became our main discovery and acquisition channel. From August 1 to September 29, our videos generated 146,400 views, 9,700 likes, 622 comments, 651 shares, and 2,500 profile visits. The account reached 3,096 followers, with approximately 1,900 net followers added during that period. More importantly, 92.5% of the traffic came from the For You feed. People were discovering HorseGirl because the problem and the product resonated with them, not only because they already knew us.

The growth also accelerated as launch approached. The final 30 days produced 113,200 TikTok views, about 77% of the entire 60-day total, as well as 8,700 likes, 581 comments, and 596 shares. Our comment sections repeatedly filled with riders asking where they could download HorseGirl and when it would be released. TikTok did not just give us awareness. It gave us our first customers and turned the launch into something people were actively waiting for.

We converted anticipation into a real launch

On September 30, HorseGirl's first public day in the App Store, Apple recorded 52 first-time downloads and 3 redownloads. The product page received 61 views, and Apple reported a 61.6% conversion rate. We also recorded our first 2 in-app purchases that day (even though we currently provide all features completely openly so that our users can give us feedback on everything and we grow our audience quickly).

Those are early numbers, but they matter deeply to us. We started building the app on August 5 and had less than two months to design it, engineer it, pass App Review, create an audience, and earn enough trust that people would install it on launch day. Every one of those downloads represented someone who had followed the story, waited for the release, and decided to give the product a place in the care of their horse.

We created more than a follower count

We are proud of the numbers, but the community behind them matters more. People did not only watch polished promotional videos. They asked questions, suggested features, challenged our assumptions, and shared what was missing from the tools they already used. Their responses influenced what we prioritized and gave us confidence that HorseGirl was solving a problem beyond our own experience.

In less than two months, we went from an idea my girlfriend had been describing for almost a year to a live product with an engaged community and paying customers. We are proud that we built both at the same time, without waiting for either the app or our public story to feel perfect before sharing it.

What we learned

Building for someone you love changes the standard

There is a difference between communicating well with users and watching someone you deeply care about put their name and face behind your product. My girlfriend co-created HorseGirl and became the person presenting it to the community. Every rough edge felt more consequential because I was not only asking riders to trust my work. I was asking her to stand behind it publicly.

That made me much more invested in every part of the experience. I spent several days on something as familiar as sharing a ride, refining the animations, simplifying the flow, adjusting the visuals, and adding image editing until it felt effortless. There were moments when I knew we had only 20 days left and I had already spent seven hours on a detail that most people would never consciously notice. But those details accumulate. People may not identify every transition, delay, or interaction, but they can feel when a product has been treated with care.

Horsegirl changed my definition of premium. A product does not feel premium because it has attractive screenshots. It feels premium when every action is clear, smooth, and dependable, including the moments when something goes wrong.

That standard extends beneath the interface. HorseGirl stores information people rely on to care for real animals, so a completed task, medication schedule, or horse profile cannot quietly disappear. We learned to prepare for failures before users encounter them instead of reacting afterward. Important actions are saved locally first, failed synchronization work remains retryable, and the interface shows when a change is still waiting to reach the server. If GPS is too weak to compare a training path honestly, we label the result as an estimate instead of presenting uncertain data with false confidence.

The most important lesson I will carry into every product I build is that user experience is not the final layer added after the functionality works. It is the functionality, the appearance, the stability, the recovery plan, and the respect shown for the person trusting the product, all working together.

Shipping includes everything around the code

Before this project, it was easy to think of shipping as finishing the app and sending a build to Apple. HorseGirl taught us that production configuration, account creation, permissions, privacy information, reviewer instructions, release timing, and the first-run experience are all part of the product.

The onboarding failure made that lesson impossible to ignore. A flow that worked in staging still failed at the point where it mattered most. We now treat critical production paths as their own release checklist, especially account creation, onboarding persistence, purchases, and synchronization. We also learned to budget for review time and recovery time instead of treating approval as an instant final step.

The largest audience is not always the right first audience

We began making English content because it gave us the greatest theoretical reach. It also made our videos harder to produce and made my girlfriend, the person presenting HorseGirl, feel less natural on camera. When we switched to German, our potential audience became smaller, but our actual connection with people became stronger.

That taught us that early distribution is built on trust and recognition, not only reach. Riders responded to someone who spoke like herself and understood their world. The community did not need us to sound international. It needed us to sound real. We will continue building from that strong German-speaking community, then expand to other markets without losing the voice that made people care in the first place.

Building for someone you love changes the standard

There is a difference between communicating well with users and watching someone you deeply care about put their name and face behind your product. My girlfriend co-created Horsegirl and became the person presenting it to the community. Every rough edge felt more consequential because I was not only asking riders to trust my work. I was asking her to stand behind it publicly.

That made me much more invested in every part of the experience. I spent several days on something as familiar as sharing a ride, refining the animations, simplifying the flow, adjusting the visuals, and adding image editing until it felt effortless. There were moments when I knew we had only 20 days left and I had already spent seven hours on a detail that most people would never consciously notice. But those details accumulate. People may not identify every transition, delay, or interaction, but they can feel when a product has been treated with care.

Horsegirl changed my definition of premium. A product does not feel premium because it has attractive screenshots. It feels premium when every action is clear, smooth, and dependable, including the moments when something goes wrong.

That standard extends beneath the interface. Horsegirl stores information people rely on to care for real animals, so a completed task, medication schedule, or horse profile cannot quietly disappear. We learned to prepare for failures before users encounter them instead of reacting afterward. Important actions are saved locally first, failed synchronization work remains retryable, and the interface shows when a change is still waiting to reach the server. If GPS is too weak to compare a training path honestly, we label the result as an estimate instead of presenting uncertain data with false confidence.

The most important lesson I will carry into every product I build is that user experience is not the final layer added after the functionality works. It is the functionality, the appearance, the stability, the recovery plan, and the respect shown for the person trusting the product, all working together.

Shipping includes everything around the code

Before this project, it was easy to think of shipping as finishing the app and sending a build to Apple. Horsegirl taught us that production configuration, account creation, permissions, privacy information, reviewer instructions, release timing, and the first-run experience are all part of the product.

The onboarding failure made that lesson impossible to ignore. A flow that worked in staging still failed at the point where it mattered most. We now treat critical production paths as their own release checklist, especially account creation, onboarding persistence, purchases, and synchronization. We also learned to budget for review time and recovery time instead of treating approval as an instant final step.

The largest audience is not always the right first audience

We began making English content because it gave us the greatest theoretical reach. It also made our videos harder to produce and made my girlfriend, the person presenting Horsegirl, feel less natural on camera. When we switched to German, our potential audience became smaller, but our actual connection with people became stronger.

That taught us that early distribution is built on trust and recognition, not only reach. Riders responded to someone who spoke like herself and understood their world. The community did not need us to sound international. It needed us to sound real. We will continue building from that strong German-speaking community, then expand to other markets without losing the voice that made people care in the first place.

What's next for HorseGirl

Launching HorseGirl was not the completion of the idea. It gave us the foundation, the community, and the feedback needed to decide what should come next.

Our immediate priority is to keep improving the experience riders already use. Since launch, people have shared feature requests, frustrations with their current tools, and ideas for how HorseGirl could fit more naturally into their day. We want that feedback to become a visible loop: listen, choose the most valuable problem, ship an improvement, and return to the community with what changed. The roadmap should be shaped by real rider behavior, not only by the number of ideas we can add to it.

Turning training into a complete progression system

We are expanding HorseGirl's training system into a library of approximately 1,400 visual exercises across disciplines, goals, and difficulty levels. Riders will be able to understand a pattern through an animated arena preview, record themselves performing it, compare their route with the intended path, receive focused feedback, and follow their progress with each horse over time.

The longer-term goal is to move from isolated sessions to personalized training. HorseGirl should help riders choose what to work on next based on their horse, previous sessions, goals, and the areas where they are improving or struggling.

Connecting riders around real activities

Horse riding is deeply social, but coordinating it is still surprisingly fragmented. Riders organize hacks, lessons, arena time, and transport through private messages and group chats. We plan to add social features that make those real-world activities easier without turning HorseGirl into another feed that competes for attention.

Riders will be able to connect with people they know, plan rides together, invite others to join, share routes and ride recaps, and coordinate around their horses and stables. Trainers and trusted collaborators could also review sessions or leave feedback in the context where it is useful. Privacy and location safety will be part of the design from the beginning, especially when sharing routes, stable information, or future plans.

Building a brand beyond the app

We also want HorseGirl to become more than a piece of software. During Shipaton, we built a relationship with a horse-supplement manufacturer that believed in the project and sponsored a large giveaway for our community. That relationship showed us that HorseGirl can connect riders not only with tools and information, but also with carefully selected products and partners.

We are exploring how that could become a curated shop inside HorseGirl. The goal is not to fill the app with advertising or allow sponsorship to determine care advice. Any commercial integration should be relevant, transparent, and clearly separated from independent recommendations. We want riders to understand why a product is shown, who it comes from, and whether the placement is sponsored.

Beyond commerce, we see HorseGirl growing into a recognizable equestrian brand through education, community events, partnerships, and content created with the riders who helped shape the app.

Growing without losing what made it work

Our German-speaking community gave HorseGirl its first momentum. We want to deepen that relationship while gradually bringing the product and its content to more countries and languages. Growth should not come at the cost of the authentic voice, careful design, or reliability that made people trust us.

Whatever we build next, the standard remains the same: it should strengthen the connection between rider and horse, solve a real stable-side problem, and feel as thoughtful as the rest of the experience.

Built With

Share this project:

Updates

Submission history