← Index fig. 1

BTPHub

a marketplace connecting families with tutors and sitters across 80+ neighborhoods

Kind
Software
Tools
Vue.js, C#, ASP.NET, Azure SQL, REST APIs
BTPHub landing page with the headline 'Care from around the corner' over an aerial photo of a suburban neighborhood

Most babysitting apps are built for strangers. You search a city, scroll through people you’ll never run into, and hope the reviews are real. BTPHub goes the other way: you join your neighborhood, and the sitters and tutors you see live down the street.

TLDR: a two-sided marketplace (families on one side, sitters and tutors on the other) scoped to neighborhoods. Vue front end, ASP.NET API, Azure SQL, deployed through Azure Pipelines. It has location-based search, profiles, recurring availability, booking requests with accept/deny, and email notifications. It’s grown to 80+ neighborhoods, 2,000+ service connections and 700+ repeat users.

Design first

Before any code, I laid the app out in Figma: logo, a green palette, Outfit for headings and Inter for text, and the core components.

Figma board with the BTPHub logo, colour palette, type samples, buttons and a log-in card
The design system in Figma.

The logic took more thought. A booking touches two people with two calendars, and either of them can back out. I drew the whole babysitter flow as a chart before writing the API.

Flow chart of the babysitter booking logic with decision diamonds for availability, acceptance and cancellation
The babysitter booking flow, drawn before any of the API existed.

Neighborhoods

Sign-up asks one question first: are you looking for care, or looking for jobs? Then you find your neighborhood by name or ZIP. If it isn’t there, you can request it.

Neighborhood search during sign-up listing Georgia neighborhoods for ZIP 30022, with an option to add a missing one
Finding your neighborhood at sign-up. 'Neighborhood not listed? Let's fix that.'

Booking

Families filter sitters by date and time, open a profile, check the sitter’s schedule, and send a request. Sitters set recurring availability (“weekdays 3–6 pm”) plus one-off blocks, and accept or deny what comes in.

The original app: find a sitter, check their schedule, book.
Sitter profile modal with a monthly schedule calendar showing available slots
A sitter's schedule tab, from the customer's side.
Provider calendar with a modal for adding a new time block on 12/30/25
The provider side: open a day, add a time block.

The backend

The API is ASP.NET with Azure SQL behind it. By the end there were 27 entity classes and 85 routes across 17 controllers, a lot of them inherited from generic base controllers so that adding a new resource didn’t mean writing the same five endpoints again.

Plain-text listing of 27 entity classes with their properties and types
Every entity class and its fields, pulled straight from the C# source.
Plain-text listing of 85 REST routes grouped by controller
All 85 routes. The generic base controllers are why so many look alike.
C# source for the ServiceRequest controller handling booking requests
The service-request controller, which handles booking requests.

Notifications are their own project: templates filled in with the booking details and sent by email. Builds and deploys to the QA site run through Azure Pipelines.

Azure Pipelines YAML with build and deploy steps
The Azure Pipelines config.

The rewrite

In September 2026 I rebuilt the whole thing in Next.js. I started by recreating every page of the Vue app as a reference board, then rebuilt against those boards so nothing got lost. The flows are the same, and the code now lives in one app instead of three projects.

Same booking flow in the rewrite, end to end.
Customer dashboard in the Next.js rewrite with upcoming bookings, past bookings, a month calendar and pending requests
Customer home in the rewrite. Demo data.
Provider dashboard in the Next.js rewrite with upcoming jobs and requests awaiting response
Provider home in the rewrite.