DEV Community: Brandon Lozano

Debugging & Refactoring Spaghetti Code - The A.I Special 🤖

Brandon Lozano — Tue, 03 Mar 2026 21:33:43 +0000

Given the fact that people have varying and mostly static opinions on Artificial Intelligence, I feel like I must start by stating my own. The following is merely opinion based on my experience and overall understanding of the world and technology.

Short & Sweet - My Opinion on A.I

I think every engineer should utilize A.I to some extent: writing docs, debugging, comparing technologies, and writing code are all good use cases. However, it is not, nor will it be, the end all and be all for great software. We do not have the compute nor the data for A.I to reach Artificial General Intelligence (AGI) - where A.I becomes human-like. The people who are selling the dream of A.I doing everything while we hang back like the people in WALL-E are directly benefiting from the stock surges caused by this speculation.

Problem Statement

Once upon a time, not too long ago I was handed over a project for Data APIs that were responsible for collecting and organizing all sales data for the company. The APIs had a ~80% success rate, not great for sales data that would mold and shift marketing and sales tactics.

On top of the bug infestation, the application was hosted in PipeDream which basically provides an env for your code to run, and handles things like gateways. Awesome for viability testing, but not great for real world applications. There was essentially no version control, config access, or proper way to manage dependencies.

Why All Of The Issues?

All of the architecture, code, and schema was built while heavily relying on A.I, and when I say heavily rely I mean, A.I drove - the old employee hit yes.

Overall there were around 50 data points that needed to be tracked, to get them there were countless if else statements, nested for loops, and API calls for each individual order instead of batch calls.

The project was the utter representation of spaghetti code - but I honestly learned more about APIs, debugging, databases, and clean code during this project than any other single project.

To Gain An Understanding

Plainly looking at the code and digesting the limited documentation did not provide enough context to give me any true indication as to what data points were required and where they came from.

I at least had a general understanding that sales data originated in Shopify, we were utilizing HubSpot to associate sales to team members, PostgreSQL was our combined source of truth, and the whole thing relied on PipeDream APIs. I started from the DB viewpoint to understand how data should be represented (if the pipeline ran successfully).

Below is the example schema for the deals table, this is the main entry point for tracking all sales

CREATE TABLE IF NOT EXISTS DEALS (
  deal_number INT,
  price INT,
  disc_price INT,
  shipped BOOLEAN,
  ...
);

Once I thoroughly understood data requirements, I began to use pen and paper to map out data points, their origin source, and data type that was preferred. This allowed me to make very rough sketches of the data pipeline. To start, the entire system was of a very ambiguous state - no beginning and no end.

Console Line Debugging

A real advantage here was that Pipedream saved each event with its full request payload for 30 days, meaning I could replay the exact same request through the broken pipeline repeatedly while making fixes. This made isolating failures significantly faster than traditional debugging — rather than waiting for real events to reproduce a bug, I could trigger it on demand.

Below is an example of what the code base looked like.

// Rough Example of what we were dealing with
const { Client } = require('pg');
export default function EventHandler() {
  const fetchShopifyOrders = async () => {
    const response = await fetch(process.env.SHOPIFY_URL, {
      headers: {
        API_KEY: process.env.SHOPIFY_API_KEY,
      }
    });
    return response;
  }

  const fetchHubspotData = async (orderId) => {
    const response = await fetch(process.env.HUBSPOT_URL, {
      headers: {
        API_KEY: process.env.HUBSPOT_API_KEY,
      },
      body: {
        orderNumber: orderId
      }
    });
    return response;
  }

  const client = new Client({
    user: 'your_user',
    host: 'localhost',
    database: 'your_db',
    password: 'your_password',
    port: 5432,
  });

  const orders = await fetchShopifyOrders();

  for (const order of orders) {
    const orderNumber = order.details.orderNumber;
    let currency = '';
    let price = 0;
    let delivered;
    let hubspotId;
    let hubspotOwner;
    // image 30 more variable likes this 

    if (order.details.country === 'us') {
      currency = 'USD';
    } else if (order.details.country === 'ca') {
      currency = 'CAD';
    } else if (order.details.country === 'au') {
      currency = 'AUD';
    }

    if (order.details.discountPrice) {
      price = order.details.discountPrice;
    } else {
      price = order.details.price;
    }

    if (order.details.deliveredStatus === 'delivered') {
      delivered = true;
    } else {
      delivered = false;
    }

    // and 30 more if else statements to assign variable values

    const hubspotData = await fetchHubspotData(orderNumber);

    if (hubspotData.dealOwner !== '') {
      hubspotOwner = hubspotData.dealOwner;
    }

    if (hubspotData.id) {
      hubspotId = hubspotData.id
    }

    await client.connect();

    const query = `INSERT INTO DEALS (orderNumber, currency, price, delivered, hubspotId, hubspotOwner) VALUES (${orderNumber}, ${currency}, ${price}, ${delivered}, ${hubspotId}, ${hubspotOwner}) RETURNING *`
    await client.query(query);
  }
}

Issues with the above

aysnc typo would crash immediately at runtime
fetchShopifyOrders called without await — iterating a Promise
client.connect() called on every loop iteration, never released
Raw template literal SQL query is a textbook SQL injection vulnerability
Hardcoded DB credentials in the source code
No error handling anywhere — a single failure crashes the entire batch
Dozens of verbose if/else chains that could each be a single expression
Variables declared and mutated individually per order with no shared shape or structure

To The Refactor

After quite a bit of work and understanding, I was able to get to a place like this:

Batch cleaned all order data first with a single map before any async work
Bulk fetched all HubSpot data in parallel with Promise.all instead of sequential awaits in a loop
Replaced verbose if/else chains with a CURRENCY_MAP lookup and ternary operators
Moved DB credentials to environment variables
Introduced a single pool connection reused across all inserts, released in a finally block
Parameterized SQL queries eliminating injection risk
RETURNING id gives back insert IDs for debugging and reduces load for returning all data - which is not necessary
Wrapped everything in try/catch for graceful error handling

import { Pool } from 'pg';

const pool = new Pool({
  user: process.env.DB_USER,
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  password: process.env.DB_PASSWORD,
  port: process.env.DB_PORT,
});

const CURRENCY_MAP = {
  us: 'USD',
  ca: 'CAD',
  au: 'AUD',
};

export default async function EventHandler() {
  try {
    const orders = await fetchShopifyOrders();

    const cleanedOrders = orders.map((order) => ({
      orderNumber: order.details.orderNumber,
      currency: CURRENCY_MAP[order.details.country] ?? 'USD',
      price: order.details.discountPrice ?? order.details.price,
      delivered: order.details.deliveredStatus === 'delivered',
      hubspotId: null,
      hubspotOwner: null,
    }));

    const hubspotResults = await Promise.all(
      cleanedOrders.map((order) => fetchHubspotData(order.orderNumber))
    );

    const enrichedOrders = cleanedOrders.map((order, i) => ({
      ...order,
      hubspotId: hubspotResults[i].id ?? null,
      hubspotOwner: hubspotResults[i].dealOwner || null,
    }));

    const client = await pool.connect();

    try {
      const results = await Promise.all(
        enrichedOrders.map((order) =>
          client.query(
            `INSERT INTO DEALS (orderNumber, currency, price, delivered, hubspotId, hubspotOwner)
             VALUES ($1, $2, $3, $4, $5, $6)
             RETURNING id`,
            [order.orderNumber, order.currency, order.price, order.delivered, order.hubspotId, order.hubspotOwner]
          )
        )
      );

      return results.map((r) => r.rows[0].id);
    } finally {
      client.release();
    }
  } catch (error) {
    console.error('EventHandler failed:', error);
    throw error;
  }
}

const fetchShopifyOrders = async () => {
  const response = await fetch(process.env.SHOPIFY_URL, {
    headers: { API_KEY: process.env.SHOPIFY_API_KEY },
  });
  return response;
};

const fetchHubspotData = async (orderId) => {
  const response = await fetch(process.env.HUBSPOT_URL, {
    headers: { API_KEY: process.env.HUBSPOT_API_KEY },
    body: { orderNumber: orderId },
  });
  return response;
};

The above code examples are brief indications of what the code-base looked like, in reality there were five other scripts and 5 other DB tables that were being populated. Each of these scripts contained at least 400 lines of spaghetti code. All code followed the same patterns above and each had to be rebuilt from the same foundation up.

The irony wasn't lost on me that I used AI tools during the refactor — for documentation, sanity checking logic, and comparing approaches. The difference was that I was driving. Understanding the problem space deeply enough to catch what the AI got wrong, knowing when to trust it and when to question it, is the skill. The code doesn't lie, and an 80% success rate on sales data will always find its way back to you.

Building an AI DJ: What I Got Wrong About Music Embeddings 🎶🕺

Brandon Lozano — Fri, 20 Feb 2026 00:50:23 +0000

It All Begins With a Vibe Gripe

We have all been there, at weddings, maybe even our own. The DJ decides to whip out Cupid Shuffle, Cha-Cha slide, and Cotten-eyed Joe (no offense if you genuinely enjoy these tracks). The intent is to drive engagement, but one thing we have found socially is that obligatory engagement isn't engagement. The purpose of a wedding reception is to get people dancing and to provide them with a great time.

Base Premise of the Application

I had a hunch that using meta-data, embeddings, personal data, location, and weather I could build an algorithm that outperformed 95% of wedding DJs. I am not bullish that computers will at all replace true art -- Tiesto, Steve Aoki, and Diplo are definitely safe IMO. The goal here is to build something that is budget friendly for couples who don't have an endless budget and want their guests to have a good time.

At the end of the day, engagement and music itself can be represented with tags and math.

Initial thoughts

I initially leveraged Spotify due to the countless public playlists — the like count is a decent proxy for crowd-tested quality. A few examples are SONGS TO DANCE TO AT 3:33 AM, sad songs to cry out to, and of course wedding reception BANGERS.

Originally my thought was to get the top 3 most liked playlists for wedding ceremonies, cocktail hours, dinners, and receptions using Spotify's API. Initially I assumed that BPM, Camelot Key, Popularity, Genre, and Artist would be sufficient to begin creating a vibe curve.

Importing Music

After copying 12 of the most popular playlist I setup a basic API to seed my PostgreSQL database. Quickly I found out that Spotify's /audio-features endpoint (which includes BPM, key, energy, etc.) was blocked for our app credentials. Rather than fight with API permissions, I built a manual entry script manually entering BPM and Camelot key for each track.

# Manual import script
def import_playlist_manual(playlist_id, stage):
    """Import playlist with manual BPM/Key entry from songbpm.com"""

    # Fetch all tracks from Spotify
    results = sp.playlist_tracks(playlist_id)
    # ... handle pagination ...

    for track in tracks:
        # Destructure track object from Spotify

        # Display track info
        print(f"🎵 {track_name}")
        print(f"🎤 {artist_name}")

        # Manual entry
        bpm_input = input("Enter BPM (or 's' to skip): ").strip()
        bpm = int(bpm_input)

        key_input = input("Enter Key (e.g. 10A, 2B) or press Enter: ").strip()

        # Estimate energy from BPM
        energy = 0.8 if bpm >= 130 else 0.6 if bpm >= 110 else 0.4

        # Save to database
        cursor.execute("""
            INSERT INTO curated_tracks 
            (spotify_id, name, artist, album, bpm, key, energy, stages, 
             popularity, duration_ms, genres, release_year, explicit)
            VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)
        """, (track_id, track_name, artist_name, album_name, bpm, key, 
              energy, [stage], popularity, duration_ms, genres, 
              release_year, explicit))

# Function call with manual stage denotation, based on playlist
import_playlist_manual(40baa6dacb5a4ad2, 'reception')

After building out the initial playlist generation services, I started to notice that recommendations were entirely off. I was adhering to the vibe curve for stages but the genre and semantic meaning of the music was way off. The vibe curve was one of the initial ideas, energy created from the music should have a curve based on the stage in the event to maximize engagement and minimize burnout.

CEREMONY = {
    'duration': 30,  # minutes
    'energy_range': (0.2, 0.4),
    'curve': 'flat_low',
    'description': 'Intimate and elegant throughout'
}

COCKTAIL = {
    'duration': 60,
    'energy_range': (0.4, 0.6),
    'curve': 'gentle_rise',
    'description': 'Conversational background, slight build'
}

DINNER = {
    'duration': 90,
    'energy_range': (0.3, 0.5),
    'curve': 'flat_medium',
    'description': 'Steady background, family-friendly'
}

RECEPTION = {
    'duration': 180,
    'energy_range': (0.5, 0.95),
    'curve': 'two_peak',
    'description': 'Gradual build → peak → sustain → final peak'
}

# Visual Representation
Energy
1.0 |                            ┌────────┐
    |                        ┌───┘        └─
0.8 |                 ┌──────┘
    |            ┌────┘
0.6 |      ┌─────┘
    | ─────┘
0.4 |
    └─────────────────────────────────────> Time
    0%   15%   40%  55%      85%       100%
    warm  peak1 dip  peak2    sendoff

Music Catalog Enhancements

From architecting RAGs and my overall experience with AI, I was aware of embeddings and wondered if that was something I could utilize to build a list of most similar songs to build the queues. Utilizing iTunes music preview API to download 30 second previews and LAION CLAP I was able to generate audio embeddings and Sentence Transformers to create embeddings based on meta-data per song. The approach: Generate 512-dimensional vectors that capture both sonic texture (tempo, timbre, instrumentation) and textual metadata (genres, artist, stage tags). By combining these with a 60/40 audio-to-metadata weighting, we could find songs that both sound similar and fit similar contexts.

# Initialize models
clap_model = CLAP_Module(enable_fusion=False)
clap_model.load_ckpt()  # LAION CLAP (HTSAT) for audio
text_model = SentenceTransformer('distiluse-base-multilingual-cased')

def generate_embeddings(track):
    # 1. Audio embedding from 30-second iTunes preview
    audio, sr = librosa.load(f"previews/{track.spotify_id}.m4a")
    audio_embedding = clap_model.get_audio_embedding_from_data(
        x=audio, 
        use_tensor=False
    )  # Returns 512-dim vector

    # 2. Metadata text embedding
    metadata_text = f"{track.genres}, {track.stages}, {track.artist}"
    metadata_embedding = text_model.encode(metadata_text)  # 512-dim

    # 3. Weighted combination (audio = 60%, metadata = 40%)
    combined = (audio_embedding * 0.6) + (metadata_embedding * 0.4)
    combined = combined / np.linalg.norm(combined)  # Normalize

    # Store in PostgreSQL with pgvector
    cursor.execute("""
        UPDATE curated_tracks 
        SET audio_embedding = %s,
            metadata_embedding = %s,
            combined_embedding = %s
        WHERE spotify_id = %s
    """, (audio_embedding.tolist(), metadata_embedding.tolist(),
          combined.tolist(), track.spotify_id))

PostgreSQL vector similarity search

Using pgvector extension (which adds vector similarity search to PostgreSQL), we can query for similar songs using cosine distance:

-- Find 10 most similar songs by audio + metadata
SELECT name, artist, bpm, energy,
       combined_embedding <=> %s::vector AS similarity
FROM curated_tracks
WHERE combined_embedding IS NOT NULL
ORDER BY combined_embedding <=> %s::vector  -- Cosine distance
LIMIT 10;

This did improve relevancy with suggested songs, but I could tell that something was missing. The problem: audio similarity captures sonic texture but not semantic intent. It was obvious that the essence, apart from lyrics of suggested songs was similar but the queue would add songs about war, club music, and romantic melodies all to the ceremony (if you are thinking of this split for your wedding please reconsider). A song about heartbreak can sound identical to a love song—same tempo, same instrumentation, completely different meaning. Embeddings alone couldn't distinguish between "Fortunate Son" (war protest) and "Signed, Sealed, Delivered" (celebration) if they had similar acoustic profiles.

Enter Claude: Semantic Tagging for Intent

I decided to use Claude's API to tag music to represent the semantic meaning apart from audio qualities, but more so to capture the intent of each song. The cost was negligible - costing around $15 for 2.5k songs.

def tag_song_with_claude(track):
    """Extract semantic meaning beyond audio qualities"""

    prompt = f"""Analyze this wedding song:

    Title: {track.name}
    Artist: {track.artist}
    BPM: {track.bpm}
    Energy: {track.energy}

    Provide wedding-specific tags in JSON:
    {{
      "vibe_tags": ["romantic", "celebratory", "energetic", etc.],
      "occasion_tags": ["first-dance", "processional", "general-dance", etc.],
      "mood_tags": ["joyful", "tender", "euphoric", etc.],
      "lyric_themes": ["love", "commitment", "celebration", etc.],
      "content_flags": ["war-themes", "breakup", "explicit", "club-music"],
      "wedding_appropriate": true/false,
      "wedding_notes": "Brief explanation"
    }}"""

    message = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )

    tags = json.loads(message.content[0].text)

    # Save semantic tags to database
    cursor.execute("""
        UPDATE curated_tracks 
        SET vibe_tags = %s,
            occasion_tags = %s,
            mood_tags = %s,
            lyric_themes = %s,
            content_flags = %s,
            wedding_appropriate = %s,
            wedding_notes = %s
        WHERE spotify_id = %s
    """, (tags['vibe_tags'], tags['occasion_tags'], tags['mood_tags'],
          tags['lyric_themes'], tags['content_flags'], 
          tags['wedding_appropriate'], tags['wedding_notes'],
          track.spotify_id))

The impact was immediate:

# Before Claude tagging - embeddings alone:
ceremony_queue = [
    "Canon in D",           # ✅ Perfect
    "The Sound of Silence", # ❌ Too melancholic
    "Fortunate Son",        # ❌ War protest song
    "Call Me Maybe"         # ❌ Club pop
]

# After Claude tagging - filtered by semantic meaning:
ceremony_queue = [
    "Canon in D",           # ✅ occasion_tags: ["processional"]
    "A Thousand Years",     # ✅ vibe_tags: ["romantic", "intimate"]
    "At Last",              # ✅ mood_tags: ["tender", "joyful"]
    "Marry You"             # ✅ lyric_themes: ["commitment", "love"]
]

The Hybrid Approach

The final song selection algorithm uses a weighted scoring system:

Embedding similarity (60%) - Heaviest weight because sonic continuity matters most for dance floor flow
BPM/energy matching (25%) - Adheres to the vibe curve progression
Semantic tags (15%) - Acts as a filter rather than primary driver; prevents obvious mismatches

These weights came from iterative testing - we found that prioritizing sonic flow over semantic perfection kept energy up while still avoiding thematic disasters.

This hybrid approach prevents the "sounds right but feels wrong" problem—songs flow naturally while staying thematically appropriate for each wedding moment.

In Conclusion

Vibe Curator is still in active development -- I am making some queue generation, conversation service, and UI enhancements before launching to my network for testing. Afterwards I plan to integrate real-time crowd engagement analysis to dynamically adjust the queue based on how people are actually responding on the dance floor.

The biggest takeaway from this whole process isn't specific to music though: embeddings are powerful, but they capture how something sounds or reads, not what it means. Pairing vector similarity with semantic intent is becoming a pattern I reach for anytime embeddings alone feel shallow.

If you've tackled a similar hybrid approach, or have thoughts on the scoring weights, I'd love to hear how you approached it in the comments.

Building a High-Performance Booking Platform: Reducing API Calls by 66% 🚀

Brandon Lozano — Wed, 08 Oct 2025 21:44:20 +0000

It's my money and I need it now! - JG Wentworth Commercial

The actors in this nostalgic commercial (90's baby) are demanding their money and want it instantly, as a kid the only solution I could think of was to have a JG Wentworth representative in every large city with boat load of cash - getting anything out of thin air instantly seemed unfathomable.

The commercial was ahead of its time, today we expect everything instantly - Netflix Shows, Amazon Products, Social Media Posts, and in the case of GOLFTEC users want to improve their golf game and want to get started now.

We had a problem though, our marketing website and booking platform were built on a home-brewed PHP CMS which was starting to show its age. The booking platform took 15 seconds to load appointments, forced users to re-enter information on every visit due to no session memory, fetched our APIs on every reload or page visit, and provided no visibility into abandoned carts.

I had six months to rebuild it, to make it work and to make it fast.

The Challenge

Huge annual sale is coming, we are down to the wire

The Legacy System

Performance baseline: 20+ seconds of waiting on API responses per booking flow
API overhead: 15+ calls per booking flow
Concurrent users: Hundreds during peak hours (golf tournaments and sale periods)
User experience issues:
1. Slow Loading
2. Confusing Flow
3. Nearby locations unclear
4. No data on booking funnel
5. Dated UX

Business Constraints

Timeline: 6 months from kickoff to launch
Availability requirement: 99.9% uptime (revenue-critical application)
Feature parity: Maintain 100% of existing functionality
Stakeholders: Marketing needed new features and metrics

Technical Constraints

Backend:
1. Limited bandwidth for backend services
2. Not much flexibility with core service
Team size: 2 engineers for backend support, me, myself, and I to build frontend

Solution Architecture

Support several apps - prioritize simplicity, less dependencies is more

Core Architectural Decisions

The platform was rebuilt with three key architectural principles:

Minimize network requests: Intelligent caching and request batching
Optimize perceived performance: UI Skeleton Feedback, Pre-fetching, and split modules where possible
Maintain simplicity: Avoid over-engineering; choose boring tech where possible

Tech Stack Selection

Frontend:

React + TypeScript: I wanted tried, true, and well documented. The idea was that any engineer with even some JS/TS could hop in and make changes. I had also previously worked in a large project previously that was vanilla JS, opting for TS and having access to interfaces and type safety was a no-brainer.
Context API for shared state: There are more than one ways to skin a cat and the same is true for sharing state. I would have only chosen Redux for resume-building, not because the project needed it - Context API provided all of the functionality I needed and did not bloat my dependency tree.
Material UI: The Figma designs for the booking platform were not anything too specialized and naturally closely followed Material UI's structure. I also wanted to leave margin for custom logic and functionality, CSS overrides were also a small price to pay for a beautiful UI.
Local Storage: The booking platform had previously fetched APIs every reload for data that was mostly static (GT Center data, user data, etc). To make the platform faster I knew I wanted to persist this data between reloads.
Webpack: The application(s) needed to be bundled and I wanted to use something that easily introduced code splitting and chunk caching.

Backend:

PHP Middleware to Java Backend: This was mostly already set in stone, but served useful since we had a couple of dedicated PHP engineers to create these new APIs bespoke to our use case. It also helped that we could reuse infrastructure from old PHP CMS, load balancers and all.
REST APIs: Because we were able to tailor our APIs, GraphQL was not needed. Anything that was not useful was cut from requests and responses.

Infrastructure:

AWS S3: Once compiled, that application files were static and needed to be easily fetched from the client, with our organization already utilizing AWS, S3 was an easy choice for hosting the application file.
CDN Strategy: The booking platform needed to support users across the globe (Dubai, South Africa, Japan, China, Canada, etc). The only difference between these applications were formatting items like currency, API endpoints, and language which the client could figure out at runtime. However, we needed to deliver the application quickly to all users so I setup a CloudFront instance, by default caching was enabled for 24 hours.

Deep Dive: Performance Optimization

1. Caching Strategy

The Issue

The legacy system made redundant API calls:

Locate user on page load
Relocate user on every additional page load
Fetch center data every time user is located
Require user to re-enter information on every reload
Fetch pricing data on every load
Require user to re-enter information when changing location

The Solution

Client-side caching with smart validations

class Storage {
  static EXPIRATION = 14 * 24 * 60 * 60 * 1000; // 14 days

  static getData(key: string){
    const item = localStorage.getItem(key);
    if (!item) return null;

    const { data, timestamp } = JSON.parse(item);

    if (Date.now() - timestamp > this.EXPIRATION) {
      this.deleteData(key);
      return null;
    }

    return data;
  }

  static setData(key: string, data: any){
    localStorage.setItem(key, JSON.stringify({
      data,
      timestamp: Date.now()
    }));
  }
}

// example usage
const centerData = Storage.getData('center_details');
if (!centerData) {
  const data = await fetchCenterDetails(centerId);
  Storage.setData('center_details', data);
}

Key Decisions

Data availability: We noticed that users would typically not book on their first visit (page or session) and also saw that users would typically come to the website from our Google maps listings (they have already vetted their most nearby location). All of this data Center Details, User Details, UTM parameters, etc would mostly be static so we decided on 14 days of localStorage or until a user booked.

Pre Fetching: In the previous tool, we would wait for interaction before starting off the process for fetching center data. In the new environment I looked for specialized tags within the DOM that would set the appropriate center and fetch data via API, the default though was using device GPS which would be requested on every page load, and the fallback was automatic GeoIP where we would not need user opt-in.

Results: Cutting out a lot of these redundant calls we saw that on average we went from 15 to 5 (66% reduction) and any number over the average was out of necessity - to change selected location or user details.

2. State Management Architecture

Why not Redux?

Redux is great and can be very useful, but just as ore is not useful on an airplane, Redux would not have been useful in the build of this application.

State Requirements

Booking flow state (4 steps, 6 user fields)
User session data (userID, handedness, etc)
UI state

Why Context API Won:

Simplicity: Redux required ramp up time for myself as well as adding to our dependency list, something I was very intentional about keeping short.
Performance: Component tree depth was 5 levels, re-render optimizations with useMemo(() => {}, []); was more that sufficient.
Bundle size: Redux + middleware would have added additional bloat and modules to our bundle, again something I was very intentional about keeping small.

// CONTEXT EXAMPLES
/*
  - I had 4 main contexts Appointments, Booking, Center, and Service
  - These would keep track of things like activeStep, selectedService, responseStatusCode, etc.
  - I could be very intentional about the structure of my app and components and where I wanted this data shared
*/

interface BookingContextProps {
  ...
}

const BookingContext = createContext<BookingContextProps | undefined>(undefined);

interface ServiceContextProps {
  ...
}

const ServiceContext = createContext<ServiceContextProps | undefined>(undefined);
...

3. Concurrent Bookings

Race Condition Problem

I think we lucked out a bit here, we had very few instances of truly concurrent bookings especially since we were booking for 250+ locations, but did add some safeguards to ensure there were no false-positives.

We freshly fetched appointments every time the appointment page was reloaded, having stale data here was not an option. To ensure there was no room for the edge case of double bookings, we added a queue that would be invoked by location ID, not allowing other bookings at that center until the previous job completed. In the front end we made allowances with Alerts and created statusCodes specifically in the event that a user tried to book a slot that was just taken.

4. Progressive Loading & Perceived Performance

Code-Splitting: In the main App.tsx file I added a lazy import for all modules that were not required for first paint, this did have some blow back for increased API latency but was solved with more intentional deeply nested lazy(() => import('<module>')); statements.

// App.tsx
import React, { lazy, Suspense } from 'react';
import { BrowserRouter, Routes, Route } from 'react-router-dom';
import LoadingSkeleton from './components/LoadingSkeleton';

// Eagerly loaded (needed for first paint)
import Header from './components/Header';
import LocationSelector from './components/LocationSelector';

// Lazy loaded (defer until needed)
const BookingFlow = lazy(() => import('./modules/BookingFlow'));
const AppointmentScheduler = lazy(() => import('./modules/AppointmentScheduler'));
const CheckoutPage = lazy(() => import('./modules/CheckoutPage'));

function App() {
  return (
    <BrowserRouter>
      <Header />
      <LocationSelector />
      <Suspense fallback={<LoadingSkeleton />}>
        <Routes>
          <Route path="/book" element={<BookingFlow />} />
          <Route path="/schedule" element={<AppointmentScheduler />} />
          <Route path="/checkout" element={<CheckoutPage />} />
        </Routes>
      </Suspense>
    </BrowserRouter>
  );
}

Bundle Optimization: In the webpack config file I segregated three different types of files - bookingCore; contained utils, types, apis, etc.. vendors; contained node modules, commons; was inclusive of all components. Initial first paint bundle size went from 570kb to 100kb dramatically improving load times.

// webpack.config.js
module.exports = {
  optimization: {
    splitChunks: {
      cacheGroups: {
        // Third-party vendor code (React, MUI, etc.)
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          priority: 10,
          chunks: 'all',
        },
        // Shared application code
        commons: {
          name: 'commons',
          minChunks: 2,
          priority: 5,
          chunks: 'all',
          reuseExistingChunk: true,
        },
        // Booking-specific utilities
        bookingCore: {
          test: /[\\/]src[\\/](utils|types|apis)[\\/]/,
          name: 'bookingCore',
          priority: 8,
          chunks: 'all',
        },
      },
    },
  },
};

UI Updates: Thankfully, MUI made this extremely simple with some out of the box and easily configurable skeletons. Any component that contained data from our APIs was shown immediately with a 1:1 Skeleton component, we only had one spinner in the entire application - this made everything feel lightning fast.

Backend Enhancements: We were able to also find some issues with how we were fetching and booking appointments with redundant and overly verbose DB calls, fixing these helped dramatically.

5. Monitoring & Observability

Metrics Tracked:

Page load time
Time to interactive
API error rates
Booking completion rate
Booking Funnel

Tools used:

Datadog (Real User Monitoring RUM, Application Performance Monitoring APM, Session Replay)

Session Replay was particularly valuable—we could watch actual user sessions where bookings failed and identify UX issues that metrics alone didn't reveal.

Results & Impact

The numbers below alone made this project worth the time, however there were some items that were harder to measure but echoed loud still. This new tool was much easier to iterate on with new features, bugs decreased and new bugs were easier to debug, lastly this changed the way we thought about tooling and future projects.

Metric	Before	After	Improvement
Page load time	6s	3s	50% reduction
API calls per booking	15	5	66% reduction
Booking completion rate*	8%	10%	25% increase

*Completion rate = % of users who start booking flow and complete checkout

What I'd Do Differently

If I Had More Time

Create a true hold function that locked an appointment as soon as a user selected it and hold it for 5 minutes, further reducing the possibility of a double-booking edge case.
I would more aggressively prefetch data, on hover of buttons and for nearby locations, making the navigation to the schedule book seem instantaneous.

Lessons Learned

Try Early, Try Often: Early in the project, I was too scared to try different approaches and break stuff (I really just wanted to make sure I was able to ship on time). Ultimately this cost me some time in the long run, I had to backpedal anyway and well after I should have.
Think About Scale: I don't mean this in user count but in regards to additional applications, this project began as a single booking platform but quickly grew to needing other tooling for the website. At first I stood up repos for each of these projects which quickly became a mistake. I ended up creating a mono-repo shortly after the initial launch.
Flesh Out The Details: At times it is easy to stop asking questions to stakeholders in an effort to appear as if we have everything under wraps and understand it all. This is and was a mistake, there were several back-and-forths that I could have avoided if I asked more questions earlier on.
All That Glitters Ain't Gold: In development shiny and cool tooling seem necessary at times, and a lot of the time, for most use cases they are not. They can add unnecessary bloat and complexity to our projects. Like Dave Ramsey famously asks "Do I really need this library (car, jet, meal)".
Monitor Everything: What cannot be measured cannot be improved.

Connect With Me

Building solutions that drive revenue and solve real business problems make me excited, if you're working on similar problems or have questions about this project, feel free to reach out: