Download Barbershop & Salon Management System Source Code

It is Saturday afternoon, three customers walk in at once, one insists they booked by text but their name is nowhere in the book, and at closing the cash drawer does not match the records. This is common in barbershops and salons that still run on paper. This guide explains what a barbershop and salon management system should include, how its data flows, and what to check before adopting ready-made source code.

The Problems It Solves

Grooming businesses have a distinct shape: services are time-based, performed by a specific person, and customers return with the same preferences. Manual tracking tends to break in four places:

• Double bookings: two customers promised the same stylist at the same time.
• Incomplete transactions: add-ons such as a wash or treatment are not written down.
• Revenue blind spots: the owner only knows the monthly total after counting by hand.
• Lost customer history: the last cut or color formula lives in one employee's memory.

Core Modules and Data Flow

A solid system usually has six modules. Understanding how they connect helps you judge whether a codebase is designed properly.

1. Services and pricing: haircut, shave, coloring, treatments, each with a price and estimated duration.
2. Staff management: barbers or stylists assigned to bookings and transactions.
3. Customer management: name, contact, and service history.
4. Booking: links a customer, service, staff member, and time slot.
5. Transactions: records what was actually performed and paid.
6. Reports and dashboard: daily and monthly revenue from transaction data.

The flow: a customer books, the booking is confirmed on arrival, the service is performed, and the booking becomes a transaction. Reports should be calculated from transactions, not bookings, because bookings get cancelled.

Recommended Table Design

Use this as a minimum reference when reviewing source code or building your own. Note that the price is copied into each transaction line so historical reports do not change when you raise prices.

CREATE TABLE services (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  price DECIMAL(12,2) NOT NULL,
  duration_minutes SMALLINT UNSIGNED NOT NULL DEFAULT 30,
  is_active TINYINT(1) NOT NULL DEFAULT 1
);

CREATE TABLE bookings (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  customer_id BIGINT UNSIGNED NOT NULL,
  staff_id BIGINT UNSIGNED NOT NULL,
  starts_at DATETIME NOT NULL,
  ends_at DATETIME NOT NULL,
  status ENUM('pending','confirmed','done','cancelled') DEFAULT 'pending',
  INDEX idx_staff_time (staff_id, starts_at)
);

CREATE TABLE transaction_items (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  transaction_id BIGINT UNSIGNED NOT NULL,
  service_id BIGINT UNSIGNED NOT NULL,
  staff_id BIGINT UNSIGNED NOT NULL,
  price DECIMAL(12,2) NOT NULL
);

You would also have staff, customers, and transactions tables. The staff_id on each line item matters: in one visit, barber A may do the cut while stylist B does the coloring. It also makes per-staff performance reports straightforward.

Preventing double bookings

The most important rule in the booking module is rejecting overlapping slots for the same staff member. In Laravel:

$overlap = Booking::where('staff_id', $staffId)
    ->whereIn('status', ['pending', 'confirmed'])
    ->where('starts_at', '<', $endsAt)
    ->where('ends_at', '>', $startsAt)
    ->exists();

if ($overlap) {
    return back()->withErrors(['starts_at' => 'This stylist is already booked at that time.']);
}

Two time ranges overlap when each one starts before the other ends. When evaluating any codebase, try creating two bookings for the same stylist at the same time. If the system accepts both, add this validation.

Reports That Actually Get Used

Dashboards are often full of charts nobody reads. For a salon, three numbers drive most decisions: daily revenue, revenue per stylist, and the most requested services. All of them come straight from the line items table:

SELECT DATE(t.paid_at) AS day,
       s.name AS stylist,
       COUNT(ti.id) AS services,
       SUM(ti.price) AS revenue
FROM transaction_items ti
JOIN transactions t ON t.id = ti.transaction_id
JOIN staff s ON s.id = ti.staff_id
WHERE t.paid_at >= '2026-10-01' AND t.paid_at < '2026-11-01'
GROUP BY DATE(t.paid_at), s.name
ORDER BY day, revenue DESC;

For example, if the report shows Tuesdays are consistently quiet, you can schedule fewer staff or run a weekday offer. Without data, those calls are guesswork.

Running the Code Locally

Most Laravel-based projects follow the same general steps. Always read the project README first.

1. Install PHP, Composer, and MySQL or MariaDB.
2. Extract the project and run composer install.
3. Copy .env.example to .env and run php artisan key:generate.
4. Create an empty database and put its credentials in .env.
5. Import the bundled SQL file or run php artisan migrate --seed, as the project instructs.
6. Run php artisan serve and open the printed URL.

Typical Customizations

• Staff commission: add a commission percentage to staff and compute it from line items.
• Booking reminders: send a message the day before using the Laravel scheduler and an SMS or messaging provider such as Twilio.
• Service bundles: several services at a package price.
• Multiple locations: add branch_id to core tables. This is a large change, so plan it early.

Make each change on its own Git branch and test against a copy of the database. See customizing source code without breaking it for a safe workflow.

Evaluation Checklist

• A working demo exists and the flow from booking to report runs without errors.
• Double bookings for the same stylist and time are rejected.
• Old transaction prices stay the same after a service price is edited.
• Passwords are hashed, never stored as plain text.
• The folder structure follows Laravel conventions so another developer can pick it up.
• Installation docs list supported PHP versions.
• The license clearly says whether you can use it for clients or only your own business.

Limitations to Expect

Ready-made code is a foundation, not a finished product for every salon. Things you often need to add yourself: a customer-facing online booking page, card or wallet payment integration, and business rules such as membership discounts. You also own hosting, backups, and security updates. If nobody on your team writes code, budget for a freelancer to maintain it. The web application security best practices article is a useful baseline.

When It Is Worth Switching

A practical rule: if you have more than two staff members, take bookings from more than one channel, or struggle to reconcile daily cash, a system will pay off. A one-chair shop with regulars may still be fine with a notebook and a phone calendar. One implementation you can study is the barbershop and salon management system on GudangCode.