SELECTED PROJECTS

Work

Complex challenges. Connected solutions. A closer look at the systems, platforms, and operations we bring together.

01 / COMMERCE SYSTEMS

Airline luggage logistics partner

Multi-airline Baggage Replacement Platform

  • Shopify
  • AWS
  • Multi-airline APIs
  • Agent portals
Situation
A multi-year baggage replacement program serving several airlines, each with its own systems, rules, and agent teams.
Problem
The program began as separate airline-specific storefronts. Agents needed products, inventory, and ordering in one place, while each airline brought different integration, access, and security requirements.
Approach
Over a multi-year engagement, we evolved separate Shopify storefronts into a centralized, agent-facing portal supporting multiple airline programs. Multiple airline backend systems connect through APIs, coordinating product catalogs, inventory availability, commerce transactions, and fulfillment. Agent permissions, service workflows, and operational dashboards support the people managing replacements, with access and security requirements shaped around customer information and each airline’s operating rules.
Impact
Agents handle replacements from one centralized portal instead of switching between independent airline storefronts. Each airline’s rules stay intact, and new airline programs can be added to the shared platform without starting from scratch.

TECHNICAL NUANCES

  • Separate Shopify storefronts evolved into one shared agent portal
  • Airline-specific business rules preserved across multiple API connections
  • Inventory, commerce, and fulfillment workflows coordinated across systems
  • Agent access and careful handling of customer personal information
  • Multi-year architecture evolution as airline programs joined
  1. Airline APIs
  2. Central agent portal
  3. Inventory & fulfillment

02 / PLATFORM MODERNIZATION

Specialty medical and orthopedic products distributor

B2B Product Catalog & Search Modernization

  • Joomla/K2
  • WordPress
  • Bricks
  • Advanced Custom Fields
  • Algolia
Situation
A specialty catalog of roughly 109,000 product records, supporting request-for-quote enquiries rather than online checkout.
Problem
The legacy catalog had gaps in catalog numbers and manufacturer relationships, images that needed reconciling with records, and buyers who search by alternate, legacy, and manufacturer part numbers.
Approach
We migrated approximately 109,000 legacy product records from Joomla/K2 to WordPress, using Bricks, custom post types, and Advanced Custom Fields to structure the catalog. Migration scripts populated records and gave each part number its own page. Algolia search was deployed around alternate, legacy, and manufacturer part-number discovery, alongside request-for-quote workflows. Catalog-number gaps, manufacturer relationships, and product-image reconciliation remained data-quality work in their own right, not something the migration would solve on its own.
Impact
Buyers can find products by alternate, legacy, or manufacturer part number and request a quote from a dedicated product page. The team administers the catalog on a structured, maintainable platform, with data-quality refinement handled as its own ongoing workstream.

TECHNICAL NUANCES

  • Approximately 109,000 records mapped into custom post types and fields
  • Bricks and Advanced Custom Fields supporting structured WordPress content
  • Data-quality refinement continued as its own workstream alongside the migration
  • Catalog-number gaps, manufacturer relationships, and image reconciliation
  • Similar-looking parts intentionally kept as distinct records
  • Algolia discovery across alternate, legacy, and manufacturer part numbers
  1. Legacy catalog
  2. Structured content
  3. Search & quote requests

03 / PROCESS AUTOMATION / PLATFORM MODERNIZATION

Regional nonprofit

Regional Nonprofit Intake & Reporting Platform

  • Supabase
  • Cloudflare Turnstile
  • GitHub
  • Workflow automation
Situation
A regional nonprofit needed a centralized platform to collect service referrals, document community needs, and provide administrators with meaningful reporting across multiple counties.
Problem
Disconnected intake and referral processes made consistent data collection difficult. Administrators needed different permissions by geographic region, funding imposed specific reporting requirements, and internal information had to remain distinct from publicly reportable data. Limited technical resources also made long-term ownership of a custom platform a planning concern.
Approach
Developed a custom application using a modern web architecture, with Supabase for application data and access controls, Cloudflare Turnstile for submission protection, and GitHub for source control. AI-assisted development was part of delivery—not AI-powered intake or reporting. Public referral forms, structured intake and needs assessments, client and referral management, administrative dashboards, and geographic reporting centralize the operational work. Role-based access and database row-level security govern regional access; Cloudflare Turnstile protects submissions. GitHub source control and infrastructure and ownership-transition planning support ongoing operation. The architecture supports eight regional counties while handling information outside the defined reporting scope separately.
Impact
Referrals and intake now arrive through one centralized submission process, and administrators review client and referral records in one place. Regional needs information is collected consistently, access and reporting are scoped by county, and staff have clearer visibility into submitted information and regional activity.

TECHNICAL NUANCES

  • Eight regional counties with geographically scoped administrative access
  • Internal information distinguished from public and funding reports
  • Out-of-scope information handled separately from regional reporting
  • Role-based access and database row-level security
  • Cloudflare Turnstile protection on public submissions
  • GitHub source control and infrastructure ownership-transition planning
  1. Public intake
  2. Role-based review
  3. Regional reporting

04 / MARTECH & MARKETING OPERATIONS

Multi-location franchise group

Multi-Location Franchise Marketing Operations

  • HubSpot
  • Zendesk
  • WordPress
  • Multi-location systems
Situation
A franchise organization coordinating marketing, customer engagement, and franchisee support across corporate and local teams.
Problem
Corporate and location teams had different operational requirements. Marketing, CRM, and customer service depended on multiple systems, while franchisees needed consistent processes and access to support resources and operational information.
Approach
We supported the organization’s marketing and operational technology environment: HubSpot CRM, marketing automation workflows, Zendesk customer and franchisee support, WordPress location websites, and franchisee-facing resources. The work focused on coordinating marketing and service operations across distributed locations while maintaining centralized technology standards and accommodating local needs.
Impact
Corporate and location-level marketing technology is coordinated in a more structured way, with CRM and marketing automation capabilities managed centrally. Franchisee support requests and resources follow organized workflows, giving multiple locations a more consistent technology foundation to work from.

TECHNICAL NUANCES

  • Centralized technology standards balanced with local operating needs
  • HubSpot CRM and marketing automation supporting marketing operations
  • Zendesk resources and support for customers and franchisees
  • WordPress location websites within a distributed operating environment
  1. Marketing
  2. Customer data
  3. Support operations

WHAT’S NEXT

Let’s connect the dots.

A platform to modernize. Systems to bring together. A process ready for a better approach.

Start a conversation