Powstania Warszawskiego 15
31-539 Kraków
Based on client expertise that identified user challenges in finding qualified local trainers and gaps in existing fitness platforms.
Clean, motivational interface with intuitive navigation and streamlined booking process to minimize friction between finding and scheduling with trainers.
Developed dual interfaces for users and trainers with integrated location services, verification systems, secure payments, and messaging capabilities.
Conducted comprehensive testing across devices, usability sessions with target users, and beta trials with trainers and clients to gather real-world feedback.
CASE STUDY · FITNESS & WELLNESS
A Flutter mobile app that puts personal trainers and their clients in the same tool, replacing spreadsheets, WhatsApp threads, and missed sessions with one shared booking, payments, and chat flow.
THE CHALLENGE
Personal trainers in Poland were running their entire business on tools built for something else. Availability lived in a paper planner or a shared spreadsheet, payments were tracked in a notes app, and client conversations were split across WhatsApp, Instagram DMs, and text messages. Every new client meant another manual thread to keep straight.
On the other side, people looking for a trainer had no real way to compare who was actually a fit. Directory style fitness apps show a list of names and a star rating, then hand the client off to a cold DM. There is no visibility into a trainer's actual schedule, no simple way to book a slot, and no shared record of what happened in past sessions.
The brief we received was not another generic booking widget. It was a working environment that a trainer would actually run their business inside, and that a client would actually enjoy using, built as one connected product rather than two separate apps bolted together.
KICKOFF & SCOPING
Instead of rushing a thin MVP to market, we spent the first four weeks in working sessions with the client. They came in with a clear vision of the product and a firm point of view on the fitness market, and our job in kickoff was to turn that into a scope a team could actually build: user roles, core flows, what ships in version one and what waits.
Three product decisions came out of those sessions and shaped everything after them. First, matching had to account for personality and specialty, not just location. A client is rarely looking for "a trainer nearby," they are looking for a boxing coach, a strength specialist, or someone whose style fits how they want to train. Second, rigid weekly schedules do not survive contact with a normal working life, so rescheduling and slot flexibility had to be a first class feature rather than an edge case handled through support. Third, the trainer side had to feel like the trainer's own business tool, not a lead marketplace sitting between them and their clients.
That last point is why the trainer side of Evesport is free to use, while the client side runs on Basic and Premium tiers. Trainers are the supply the whole marketplace depends on, so the business model had to make it easy for them to say yes. Settling that in kickoff, before a line of code, is what kept the paywall work later from turning into a rebuild.
THE PRODUCT
Evesport opens differently depending on who is signed in, but both experiences are built on the same core objects: slots, sessions, chat threads, and payments. A trainer sees their calendar, roster, and finances. A client sees a discovery feed of trainers filtered by city and specialty, along with their own upcoming sessions.
The client home screen was one of the most iterated surfaces in the app. Clients needed to scan a city's worth of trainers quickly, understand who was rated highly or featured, and get into a booking flow in a couple of taps rather than a multi screen funnel.
FEATURE WALKTHROUGH
A client opens a trainer's profile, sees the real week ahead, and books a slot directly. No slots that week is shown as its own state, with an option to get notified rather than a dead end. The system blocks double bookings automatically, so neither side has to police the calendar manually.
When a client can no longer make a booked session, the app does not just offer cancel and lose the slot. It lets them post the session for exchange, and anyone in the same trainer's group who wants that slot can request it. The trainer keeps a paying session, the original client is not out the cost, and a scheduling conflict becomes a small community transaction instead of a support headache.
Trainers open the app to a home screen built around their business, not a marketplace feed: active and pending clients, the next upcoming workout, completed versus cancelled session counts, and running earnings for the period. The weekly calendar underneath is where they open up new availability and see the week actually fill in.
Trainers manage active and pending clients as separate lists, assign someone to a class, or remove a client who is no longer training with them, all from one screen. It is the difference between remembering who is training with you and having it written down somewhere the app can act on.
Every trainer client relationship gets its own thread inside the app, including voice messages, so a new client's goals and a returning client's progress notes live in the same place as the booking itself. Nothing gets lost across Instagram DMs or a phone number exchanged once and forgotten.
Basic covers everything a client needs to train with one professional trainer. Premium unlocks access to up to five trainers across 3, 6, or 12 month terms, which fits people who train across disciplines, boxing one day and strength the next, without forcing them into a single trainer relationship.
Each client gets a personal QR code, shown at the start of a workout so the trainer can confirm attendance and award loyalty points. Points redeem for perks like a discount on a subscription, giving trainers a lightweight retention tool they never have to build or track themselves.
HOW WE BUILT IT
Working sessions with the client to lock scope and priorities, plus the technical architecture decisions the two sided model depends on: how slots, payments, and roles interact from day one, mapped by our Flutter development team.
Weekly stakeholder reviews kept the roadmap honest about what was actually working for trainers versus what looked good on a roadmap slide.
Real trainers from one of the top gyms in Warsaw ran their sessions through the app before public launch, together with their own clients. That is where the double booking edge cases and the case for session swapping actually surfaced.
The guiding principle through the build: a booking failure does not just cost a session, it breaks the trust a trainer spent months building with a client. Stability outranked feature count at every prioritization call.
RESULTS
Evesport is live today on the App Store and Google Play with a 4.9 average rating. Bookings grew 18% in a 60 day window after launch, driven by the combination of frictionless slot booking and the session swap feature keeping clients inside the app instead of cancelling out of it.
CLIENT REVIEW
“Our experience with Apps Value exceeded all expectations. Their team demonstrated exceptional proficiency in both technical execution and project management. What truly set them apart was their proactive approach.”
FAQ
We are not Evesport, we run a gym or studio. Does a two sided model like this apply to us?
Yes. The same pattern, one role that supplies availability and one role that books it, shows up anywhere a service is scheduled: coaching, tutoring, home services, equipment rental. If you already have a supply side that would use the app for free and a demand side worth charging, the architecture in this case study transfers directly. Our marketplace app development page covers how we scope that kind of build.
What made this harder than a standard booking app?
Two sided systems fail differently than single sided ones. A double booking or a payment mismatch does not just affect one user, it damages a relationship between two people who both trusted the app. That is why the beta phase ran with trainers from a leading Warsaw gym and their real clients rather than synthetic test accounts.
Why is the trainer side free while the client side is paid?
The trainers are the supply the entire marketplace depends on. Charging them would slow adoption on the side that is hardest to grow, so the business model monetizes the side with more willingness to pay: clients unlocking access to more trainers and priority booking.
How much would a project like this cost?
It depends on how many roles, payment flows, and real time features are in scope. Our mobile app development cost breakdown walks through the ranges by complexity tier.
What stack did you build this in?
Flutter, for a single codebase shipping natively to both the App Store and Google Play, plus a web admin panel for platform operations. It is the same stack our Flutter app developers in Poland use across the portfolio.
START A PROJECT
If your product connects a supply side to a demand side, the hard parts are the same: shared availability, two sets of permissions, and payments that have to be right the first time. That is the kind of system we build.
Or see Evesport live