BarberFlow.
An idea put into practice.

An application connecting barbershop management with team schedules and client appointments.

FROM SIGN-IN TO DAILY OPERATIONS

Actual BarberFlow screen: sign-in using a phone number and verification code.

Mobile application · API · Database

THE CHALLENGE

Coordinate the business, the team and its clients.

An appointment depends on shared information: service, time, branch, barber and status. BarberFlow organizes that information into dedicated experiences for clients, barbers and owners.

My role: Design and development of the mobile application, backend, API and database.
Core technologies: Flutter · C# / .NET · SQL Server
Product status: Final stage of development

WHAT IT ENABLES

View bookings and track appointment statuses.
Organize barber schedules, working hours and time off.
Manage branches and barber assignments.

ONE APPOINTMENT, DIFFERENT PERSPECTIVES

A dedicated space for each role.

Clients check their bookings, barbers review their schedules and owners oversee the business’s appointments. Select a screenshot to enlarge it.

Client appointment history showing the service, date, barber and status. — **Client**
Checks bookings and appointment history.

Barber schedule with appointments grouped by date and status. — **Barber**
Reviews the schedule and appointment statuses.

Owner view showing appointment times, services, barbers and branches. — **Owner**
Reviews the business’s appointments and assigned barbers.

Owner service catalog with descriptions, prices, duration and availability controls. — **Business services**
The owner manages services, prices, duration and booking availability.

HOW IT IS BUILT

From screen to data.

The mobile application communicates with a .NET API backed by a SQL Server database.

Mobile applicationFlutterInterfaces for each role
Backend and APIC# / .NETBusiness rules
DatabaseSQL ServerData persistence

Structure and technical decisions

Mobile application structure

The Flutter application is organized into authentication, owner, client and barber modules. Each module separates presentation (screens), application (state and controllers) and data (models, repositories and API access).

Interfaces by role: each user has access to the actions they need, with shared components to maintain consistency.
Critical rules in the backend: business validation runs in the API. Endpoints are grouped under /auth, /owner, /client and /barber.
Bookings in UTC: a shared time reference for storing and handling dates and times.
State and navigation: Riverpod manages state and dependencies; GoRouter centralizes navigation.
Communication and sessions: Dio handles API requests, with interceptors for authentication, token refresh and logging. Secure Storage stores the tokens.

BarberFlow.
An idea put into practice.

Coordinate the business, the team and its clients.

A dedicated space for each role.

From screen to data.

Mobile application structure

What do you need to build?

Project screenshot

BarberFlow.An idea put into practice.

Coordinate the business, the team and its clients.

A dedicated space for each role.

From screen to data.

Mobile application structure

What do you need to build?

BarberFlow.
An idea put into practice.