OUR WORK

Real Problems.
Practical Fixes.

Use cases from products and client work — what was broken, how we solved it, and what shipped.

01Automation & Integration

Legacy pricing updates for 10k+ products

The problem

The ask was simple on paper: automate pricing updates for a large catalog so staff could stop chasing SKUs by hand. The reality was messier — prices lived in a Rocket D3 / Pick-style legacy system, while the live storefront ran on Miva with several product setup types (master products, option and unit variants, and volume/quantity breaks). Every change meant manual lookups across systems that did not talk to each other.

How we solved it

We did not rip out Rocket D3 or rebuild Miva. The bridge started in the legacy stack: D3 was configured to write current price changes into a SQL table (base price and quantity-break tiers). That gave us a clean, queryable feed without fighting Pick files directly from the storefront side.

A PowerShell job connects to that table over ODBC (DSN pointed at D3), pulls the open change set, and optionally dumps the raw rows to CSV for audit and replay. Each row’s product ID is parsed into the pieces Miva cares about — full SKU, base product code, option code, and unit of measure.

Then the script asks Miva what kind of product it is dealing with and updates accordingly. Master products get a direct Product_Update. Variant products load their dimensions and match on option and/or unit (strict two-dimension match when both exist, single-dimension fallback when the variant only has one). That same price is applied to both the 10-digit child SKU and the 7-digit parent when variants live at either level.

Volume pricing is a second pass: all quantity tiers for a product are grouped, the script finds which Miva discount_volume price group the product belongs to, and pushes a ProductPricingTable through Miva’s Rest API. When the run finishes, an email summary reports master, variant, and volume successes and failures so ops can trust the batch without watching the console.

LEGACYPrice changes land in SQL

Rocket D3

Legacy system

SQL

Price rows

PowerShell

Parse & classify

Miva Paths

Master · variant · volume

Miva Store

Live + email

Master

Product_Update on full SKU

Variants

Option + unit on 7 / 10 digit

Volume

discount_volume tier tables

Rocket D3 → SQL. Rocket D3 writes base prices and quantity-break tiers into a shared SQL table — a clean feed instead of trapped Pick files.

PowerShell → Miva Rest API

function Send-MivaRequest {
    param([hashtable]$Body)
    $json = $Body | ConvertTo-Json -Depth 5 -Compress

    # Pad Base64 key if needed
    $remainder = $signingKey.Length % 4
    if ($remainder -ne 0) {
        $paddedKey = $signingKey + ('=' * (4 - $remainder))
    } else {
        $paddedKey = $signingKey
    }
    $keyBytes = [Convert]::FromBase64String($paddedKey)

    $hmac = [System.Security.Cryptography.HMACSHA256]::new($keyBytes)
    $sig  = [Convert]::ToBase64String($hmac.ComputeHash([Text.Encoding]::ASCII.GetBytes($json)))

    $headers = @{
        "Content-Type"             = "application/json"
        "X-Miva-API-Authorization" = "MIVA-HMAC-SHA256 $apiToken`:$sig"
    }

    try {
        $response = Invoke-RestMethod -Method Post -Uri "https://www.example.com/mm5/json.mvc" `
                                      -Headers $headers -Body $json -ErrorAction Stop
        return $response
    }
    catch {
        Write-Log "API ERROR: $($_.Exception.Message)" "ERROR"
        return $null
    }
}

Results

  • Automated pricing for 10,000+ products from D3 → Miva
  • One run handles master, variant, and volume pricing setups
  • Owners recovered 10–20 hours per week of busywork
02AI Voice & Operations

24/7 tee-time booking that never misses a call

The problem

Golf courses lose revenue when the phone goes unanswered after hours or during busy rounds. Staff can’t sit by a phone all day — but every missed call is a tee time that never gets booked.

How we solved it

We built Assistant Pro inside Club Pro GMS so the phone line itself becomes a booking channel. Callers dial the course number on Twilio; the call is bridged into a voice AI agent (Vapi) that greets them as the golf shop and runs a real booking conversation — date, player count, preferred time — instead of a rigid phone tree.

The assistant doesn’t invent open slots. It calls backend tools that read the same course database the pro shop uses: opening and closing hours, tee intervals, and how many players each tee time can take. Availability is filtered against what’s already booked, then spoken back as clear options the caller can pick.

When they confirm, a create-booking tool re-checks capacity, writes the reservation into Club Pro GMS (tagged as a phone booking), creates or matches the customer by phone, and returns details to Assistant Pro Voice AI so it can speak the confirmation number back on the live call. Cancel flows the same way. Call start/end and transcripts are logged so staff can review what happened.

The pro shop stays in control of the tee sheet, blocks, members, and day-to-day operations in Club Pro GMS. Assistant Pro extends that inventory to the phone after hours and during peak call volume — without hiring night staff to answer every ring.

TWILIOGolfer dials the course

Golfer

Dials course

Assistant Pro Voice AI

Runs the call

Club Pro GMS

Tee sheet DB

Assistant Pro Voice AI

Confirms on call

checkAvailability

Rest call — is the tee time open?

createBooking

Rest call — write reservation

Voice AI confirm

Assistant Pro reads booking # back

Incoming call. The golfer dials the course phone number. Twilio answers and bridges the live call into Assistant Pro Voice AI.

See it in action

Results

  • Twilio + voice AI answers and books tee times 24/7
  • Live availability and bookings against the Club Pro GMS database
  • Confirmation numbers on the call; SMS-ready notification pipeline
clubprogms.com
03Custom Software

Golf leagues without the spreadsheet chaos

The problem

Competitive golfers and league organizers were stuck with outdated tools and clunky spreadsheets for groups, formats, and scoring. Running a season meant chasing scores manually and rebuilding pairings every week.

How we solved it

We built Weekend Warrior from scratch: a full-stack web app and mobile-friendly PWA for groups, leagues, and tournaments — with live scoring, leaderboards, and 8+ game formats so organizers stop reinventing the same process.

Results

  • Live scoring and leaderboards for competitive play
  • Eight-plus game formats in one platform
  • Shipping product used by real leagues and groups
weekendwarriorgolf.com
04Infrastructure

Zero-downtime failover for Supabase apps

The problem

Apps on Supabase have a single point of failure. When the primary database goes down, users can’t read or write — and “wait for the cloud provider” is not a recovery plan for a live business.

How we solved it

FaaS (Failover as a Service) is a managed hot-standby for your Supabase database with automatic edge-level failover. We continuously replicate your data to a dedicated Aurora standby on AWS. Your app hits a single endpoint — a Cloudflare edge router handles the rest.

Health checks run every 5 seconds. When Supabase stops responding, traffic reroutes to the hot standby in about 15 seconds — full read, write, and auth, with no DNS propagation and no code changes in the client. During the outage, users keep working on standby.

When Supabase comes back, FaaS replays every write made during the outage back to primary, re-syncs replication, then returns traffic automatically. Zero data loss. Zero downtime. You can prove it with a one-click Test Failover in the dashboard.

HEALTHY

Your App

Next.js, Flutter, etc.

traffic

Edge Router

Routes traffic

reads + writes

Supabase

Primary database

rerouted
real-time sync

FaaS Standby

AWS

Hot replica — ready to take over in seconds

EC2

EC2

Compute

|
Aurora

Aurora

Database

Monitored every 5 seconds

Built on
Cloudflare
|
AWSAWS
|
AuroraAurora
|
Supabase

Logos are trademarks of their respective owners.

See it in action

Results

  • 5-second health checks and ~15s automatic failover
  • Full REST, auth, reads, and writes on the standby
  • Automatic write-back when the primary recovers — zero data loss
failoveraas.com
05Infrastructure

Capacity that shows up before signup fails

The problem

FaaS does not scale like a typical web app. Each customer is a home — a dedicated standby database, containers, a tunnel — packed onto a real server with a hard ceiling. AWS Auto Scaling Groups add identical copies of a stateless service. That does not help when the next paying customer has nowhere to unpack. If a host fills up and nothing happens, onboard dies.

How we solved it

We built a control loop that watches occupancy, not CPU. When any host hits about six of eight customers, or disk crosses sixty percent, the system starts a new server: golden image, launch, bootstrap, tunnel, register it in the fleet. Silent failure is not allowed — the job is a state machine with alerts.

Signup itself pushes the work forward. If every host is packed, the product does not return a dead error. It starts the next box — or keeps advancing the one already spinning — and tells the customer a new server is coming in about eight minutes. Capacity stopped being an ops secret and became part of the path they were already on.

HEALTHY

New customer

Hits subscribe

Signup succeeds

signup

Fleet control plane

Watching customer density and disk — not CPU

placed
EC2

Host A

Most free disk — chosen

4/8

Disk 41%

EC2

Host B

Healthy — not the bottleneck

3/8

Disk 38%

EC2

Host C

Not needed yet

0/8

Disk 8%

New customers land on the host with the most free disk

Built on
AWSAWS
|
EC2EC2

Results

  • Scale on customer density and disk, not load average
  • New hosts are bootstrapped and registered — not just launched
  • Signup gets an ETA instead of a hard failure
06Websites

Guide service sites that convert on mobile

The problem

Guide services on Lake Texoma were held back by outdated WordPress sites or no real booking flow. Guests couldn’t easily find rates, galleries, or request trips — and owners had no simple way to manage inquiries.

How we solved it

We rebuilt Four Seasons Guide Service as a fast custom static site, and built Trophy Hunters Guide Service as a Next.js app with online booking requests, gallery media, and an admin dashboard for trip management.

Results

  • Mobile-first sites with clear rates, galleries, and CTAs
  • Online booking requests with email confirmation
  • Admin tools for managing bookings without a third-party maze

Got a messy problem like these?

Tell us what's eating your week. We'll map a plain-English plan — or tell you honestly if you don't need us.