Working launch
The mobile service reached an initial live release and continued into maintenance.
Sports & Recreation · Coaching marketplace
A sports-coaching concept became a working mobile service by resolving lesson booking, cancellation, and payment rules through weekly iterations and close review with the founder.
The business context
The founder saw coaches and learners arranging lessons through offline conversations. Finding a suitable coach and place to play was only part of the task; managing learners, lesson times, payments, and invoices also took attention.
An initial demo illustrated the idea but did not provide a complete service. The project needed to turn those interactions into a usable product for both sides of the booking, with a business model based on participation in lesson transactions.
Fictional booking view with a sample coach and lesson. It illustrates the decision context without assigning a real refund entitlement, deadline, or fee. View full-size interface (new tab)
The operating challenge
As the founder tried the application and spoke with coaches, new requirements emerged. Some of the most consequential changes concerned booking, cancellation, and refunds, including revisions shortly before launch.
These were connected decisions. A change to a lesson affected the learner's expectations, the coach's schedule, and the associated payment work. The team needed to review the flow from each role's perspective rather than implement each new screen independently.
The delivery decisions
The developers planned the backend, database, hosting, and expected operating approach with the customer. Flutter supported the mobile experience, with a .NET backend and a shared data foundation.
A test environment supported regular delivery and feedback. Feature work and defect correction progressed together, allowing the founder to evaluate real interactions as the service took shape.
The team discussed the reasonableness of the workflow from the coach and learner perspectives. Booking, cancellation, and refund changes were treated as part of the overall lesson service as the requirements evolved.
The working detail
In a two-sided lesson service, the same action has different consequences for the people involved. The project's repeated review of booking and refund behavior helped connect those consequences before the application reached its first users.
The value of the collaboration was not a fixed policy supplied by the development team. It was a process for helping the founder turn evolving ideas into agreed behavior, while continuing to build, test, and prepare the service for launch.
The delivered result
The mobile service reached an initial live release and continued into maintenance.
At the initial post-launch check described by the project team, five coaches and three learners were using the product.
The same report recorded a single-session booking and a recurring-course booking.
These figures describe an early snapshot roughly two weeks after launch. They establish initial use, not a current user count or a sustained growth result.
Case taxonomy
Discuss your project
Tell us how your business works and where your software needs to change.
Get in touch
Tell us what you need to build, modernize, automate, or augment with AI. We can start with a focused discussion or a no-risk 1-week trial.
“A fantastic company to work with.” After the initial rapid development project, American Shipping Co. kept two Shinetech developers embedded for nearly four years, supporting internal and external tools and new AI initiatives.
CEO, American Shipping Co. - 5-star Google Review