Uncle Tibo

The room, before the website

299 Kirkdale, Sydenham. One room doing two jobs: coffee house in the morning, wood-fired pizzeria in the evening. The same people, the same address, a different rhythm after five.

The first brief was small: make a single-page site that feels like the place. Warm, local and built around the people in the room. The ember red could nod to the oven. Red gingham could remain where it was, safely outside the project.

Then the useful problem appeared. Pizza service needed bookings, but a generic form would happily accept more people than the room could seat and leave staff reconstructing the night from an inbox. The flow had to understand the real service: Wednesday to Saturday, 5–10pm, thirty-minute slots, table capacity, customer confirmations and a staff view that made sense during service.

"Coffee, pizza, and the people you love."

Constraints

• Launch-day budget. Keep the running cost low and the booking platform small.
• One location, two services. Change register after five without making the place look like two unrelated businesses.
• Mostly phones. Build for the person checking tonight's pizza times while walking down Kirkdale.
• Local search from day one. Make the address, hours, coffee and pizza legible to people and machines.
• The room is the limit. Never offer a slot unless the eight-table layout can seat the party.

What I looked at before drawing boxes

The reports existed to stop taste pretending to be evidence:

• Brand extraction. Warm white, cream, ember red #C84B31 and charcoal; Playfair Display for headings, Inter for body. The owners' existing language supplied the tricolons, “big love” sign-offs and people-first tone.
• Competitor analysis. I benchmarked 10 London coffee-and-pizza sites, with Pizza Pilgrims and Yard Sale at the top. In my scoring, most SE26 independents landed below 4/10. That made the local gap visible without pretending the score was a law of nature.
• Niche and search report. Mapped Sydenham searches with local intent and relatively little competition.
• Build brief. Fixed the single-page order, calls to action and photography direction before development.
• Quality audit. Set the accessibility, performance and search baseline the finished build had to meet.

What I actually built

The public site is one long scroll: Hero → Tagline marquee → About → Coffee → Pizza → Hours & Location → Gallery → Community → Newsletter → Footer. Ten sections, but one read.

The booking system sits beside it:

• Customer flow. Choose a date, party size and sitting; leave details; get a confirmation screen and a manage/cancel link. The confirmation email still writes to a console rather than an inbox, which is why it is in §05 and not here.
• Availability API. Check the date and party size against the real table set before showing a slot.
• Staff dashboard. See the day, floor plan, bookings and table assignments; cancel or add a booking without returning to the public form.
• Operational rules. Expose sittings only from 5:00–9:30, Wednesday to Saturday, with a two-hour same-day cutoff.

Three decisions that mattered

• Vanilla frontend, small backend. The public site does not need a framework to display opening hours. Live availability and booking records do need a server, so that part gets Express and SQLite.
• Two typefaces. Playfair Display handles the editorial moments; Inter handles everything that needs to be read quickly. I stopped at two before I could develop a theory about a third.
• One accent. Ember red #C84B31 appears on calls to action, the marquee stroke and hover states. The colour can suggest the wood-fire without making every photograph prove there is an oven.

uncle-tibo@main:~$ tree --essentials
├── public/
│   ├── book.html       # customer booking flow
│   ├── dashboard.html  # staff day view
│   └── components/     # booking wizard + dashboard UI
├── server/
│   ├── index.js        # Express routes + service rules
│   ├── db.js           # SQLite schema + queries
│   └── email.js        # confirmation/cancellation emails
└── data/bookings.db    # created on first run

What shaped the build

• The order matters more than the copy. Place first, story next, coffee and pizza split by time of day, then hours and location once somebody wants to visit.
• Motion stays out of the way. The hero fades, sections reveal and the marquee moves. prefers-reduced-motion is respected throughout.
• FoodEstablishment schema sits in <head>. Address, hours and cuisine were machine-readable from launch rather than added later as penance.
• The booking rule is deliberately small. A smallest-fit table check prevents impossible bookings without forcing the cafe into restaurant software built for a chain.

Where it landed

The site shipped to uncletibo.com. A coming-soon page held the address before launch; the full site replaced it on opening day.

The booking system is the part that turned a good-looking page into a service tool. Customers can see what is available without messaging and waiting. Staff can see the night, assign tables and manage bookings without making the inbox the booking book.

I handed it over with WCAG AA colour contrast, keyboard-reachable controls and prefers-reduced-motion; semantic headings, alt text, schema, sitemap and Open Graph; lazy-loaded images, deferred scripts and no layout shift.

Still open

• Move confirmation email from the current console/test path to live Resend or Postmark delivery.
• Rotate the coffee and pizza copy with the seasonal menu without touching the page structure.
• Complete the Google Business Profile claim and Instagram cross-linking for the local search work.