Stylez by Saceria
A Dallas braider for kids and adults moves booking onto her own website — real availability, her own policies, and a dashboard where she edits the site and runs her calendar.
- My role
- Sole designer and developer — brand application, the public site, the booking engine, the owner dashboard and website editor, email, and the launch onto the client's own domain.
- Built for
- Barbershops & salons
- Project type
- Braiding studio website & booking system
- Built with
- Vite · React · TypeScript · Vercel Functions · Neon Postgres · Vercel Blob · Resend
The story
What problem existed, and what we built.
The problem
Saceria's menu, photos and bookings all lived on a third-party booking platform. The platform owned the client relationship and the look of her business, and her policies — deposits, lateness, cancellations, what to bring — were buried in one long profile description.
What I built
A website she owns with booking built in. Clients pick a style and options, see the times she can actually take, and reserve one. She collects the deposit and confirms from her dashboard, where she can also change prices, photos, hours and every line of text on the site.
What it had to achieve
- Give the business a home that looks like her brand, not a booking platform's
- Never double-book — the calendar has to be trustworthy
- Put policies where clients actually read them: before they book
- Let the owner change anything on the site from her phone
The customer's experience
A parent or client picks a style, chooses length and size, and sees only the times that fit the full appointment. They read the policies that apply, book, and get an email right away. The studio is a home, so the address is shared personally once the deposit is received, never on the website.
What customers can do
- Browse styles for kids and adults with prices, times and hair requirements
- Book a style with its options and see real open times, in Central Time
- Request-only styles send a request instead of booking
- Read preparation, policies and FAQs before booking
- A private link to view, reschedule or cancel an appointment, with the policy terms shown first
The owner & staff experience
A new booking lands on her calendar with the client's phone and email. After she collects the deposit she marks it confirmed, and the client gets their confirmation with a link to manage it. When she wants to change a price, a photo or a sentence on the homepage, she edits it in place and presses Publish.
What the business can do
- Edit every page right on the site — tap text to change it, then publish
- Calendar with manual appointments, blocked time and deposit confirmation
- Answer booking requests with a reply that is emailed to the client
- Services, prices, options and photos, with hidden services kept for later
- Working hours, latest start time, notice and buffer settings
- Portfolio controls that keep children's photos private until guardian permission is recorded
How it works
Architecture & integrations.
How the application, data, access controls, and connected services work together.
A calendar that cannot double-book
Every hold, booking and blocked hour is a claim on the calendar, and the database itself refuses two claims that overlap, including the cleanup buffer. Two people tapping the same time at the same moment cannot both get it.
The server decides the price and the time
Prices, appointment length and open times are calculated on the server from the current menu and her hours, in Central Time with daylight-saving handled. What the client sees is what gets booked.
The website is editable content
Page text, lists and site photos are one document she edits on the live page. Every publish is checked, so a bad save cannot blank a page for visitors.
Messages that can't be lost
Confirmations, reminders and request replies are recorded before they are sent, and anything that fails to send is retried by a daily job.
Design decisions
The choices that shaped it — and why.
No address anywhere online
The studio is the owner's home. The system never stores or shows it; she sends it herself to confirmed clients.
Deposits handled by the owner, for now
Online deposits are built but switched off until she picks a provider. Launching with owner-collected deposits meant the business did not have to wait on a payment decision.
Brand first, from her approved logo
The site uses her approved butterfly mark and lettering, her plum-and-champagne palette, and her own professional photography rather than stock imagery.
How it was built
Development process
- 1Built the public site and a four-step booking flow against a documented data contract
- 2Imported her menu, photos and policies, then removed anything she didn't want shown
- 3Added owner sign-in, an in-place website editor and site photo controls
- 4Built the booking backend: availability, holds, requests, manage links and email
- 5Ran an end-to-end QA pass and fixed every finding before launch
- 6Launched on stylezbysaceria.com with booking live
Technical overview
Technology & implementation
Technology stack
- Vite
- React
- TypeScript
- Vercel Functions
- Neon Postgres
- Vercel Blob
- Resend
Implementation scope
Sole designer and developer — brand application, the public site, the booking engine, the owner dashboard and website editor, email, and the launch onto the client's own domain.
Related projects
You might also want to see
Joe's Barber Cide
Barbershop operating system · Client project
joesbarbercide.comA two-chair barbershop runs its whole day on its own website — booking, walk-ins, barber portals, pay statements and 1099 prep — instead of renting a booking platform.
Read the case study
LaTarsha Towers
Personal brand website & content dashboard · Client project
latarshatowers.comOne home for an entrepreneur's brands, speaking, events and community work — with a dashboard to keep the story current.
Read the case studyWant something like this for your business?
Tell me how your days go and what you'd like to stop doing by hand. I'll tell you honestly what would help.