RYAN ZERNACH

Senior AI Systems Engineer

Ryan_Zernach_2025_Senior_AI_Systems_Engineer_Remote_United_States

BUILDING RELIABLE

HEALTHCARE AI

SCALING PRODUCTION

LLM SYSTEMS

ENGINEERING TRUSTED

AI INFRASTRUCTURE

DELIVERING INTELLIGENT

PATIENT IMPACT

🌱 Landscape Supply: Agentic Communications and Delivery Scheduling

Landscape Supply started as a communications and logistics problem more than a typical storefront. I built it across a TypeScript React Native app and a TypeScript Express backend, then added Twilio-backed voice and messaging flows, queue-driven follow-up, and a layer of automation around delivery scheduling. What made it fun for me was how many moving pieces had to stay in sync: customer intent, app state, phone calls, messages, payments, and the actual delivery handoff.

Related Links
Visit Landscape Supply Website
Download on Apple App Store
Download on Google Play Store
Landscape Supply home screen showing delivery scheduling shortcuts and product categories for grass and rock.
Press to open landscapesupply.app and browse the live delivery catalog.

🖥️ Admin Surface For Communication Operations

I liked having a real admin surface for this part of the project. Email templates, marketing campaigns, push notifications, unsubscribe handling, supplier research, and phone-call tooling all lived in one place, which made the communication system feel like part of the product rather than a pile of disconnected utilities.

Landscape Supply admin actions screen showing Email Templates, Marketing Campaigns, Referrers, Push Notifications, Unsubscribes and Removals, Supplier Research, and Phone Calls.
Landscape Supply admin actions screen for lifecycle communication and coordination workflows.

Landscape Supply presentation

🧱 What I Built

This project pulled together the customer-facing app, the backend workflow layer, and the communication system around it. I worked across the Node and TypeScript services, the React Native client, async jobs, Twilio, email flows, payments, and the admin surfaces that made the whole thing usable day to day.

⚙️ Technical Spine

TypeScript React Native (iOS, Android, web), TypeScript Express services, queue workers, Twilio voice webhooks, Twilio media-stream endpoints, dedicated SMS and VOIP queues, IMAP and POP email handling, Stripe, and custom campaign scheduling logic.

🤝 Ownership Model

I worked across product decisions, frontend flows, backend orchestration, communication tooling, and operational debugging, which made it easier to keep the whole system coherent.

🧭 How The System Came Together

The sections below break down the communication layer, the backend structure, and the operational tradeoffs that made the project interesting.

Twilio and Channel Design

Messaging and Lifecycle Workflows

Backend Structure

Debugging Across Boundaries

🚧 Why This Was A Hard Communications Problem

Landscape Supply sits at the intersection of commerce and field operations. Buying material is easy. Coordinating the right quantity, the right location, the right delivery window, and the right site constraints is the real work. Many of those details are clarified through calls, messages, and follow-up, which means the communication layer has to be as reliable as the checkout flow.

🎯 What I Owned

I owned the build end to end: product direction, UX, frontend architecture, backend orchestration, communication systems, queue-driven workflows, automation, and lifecycle follow-up. That scope let me remove friction across the entire lifecycle instead of optimizing one narrow layer.

📈 What Success Looked Like

Success was not just more checkouts. Success was fewer preventable mistakes after checkout: cleaner scheduling handoffs, faster clarification cycles, better delivery readiness, fewer dropped details between channels, and less operational thrash between buyer intent and field execution.

🧠 What Kept It Interesting

I liked this project because the communication layer could not be fake. If calls, messages, or follow-up logic were sloppy, the operational mistakes showed up immediately. That made it a good place to think carefully about webhooks, queue boundaries, environment setup, and real-world handoffs.

🔍 Deep Dive: Communications, Backend, and Operations

This section gets into the customer-facing flow, the Twilio-backed communication layer, the backend structure, and the operational details that made the project worth building.

The Customer Experience Was Driven By Communication Quality

Clear scheduling details mattered more than a flashy checkout flow

Twilio In The Loop

Voice and messaging were part of the logistics flow

Backend Structure

Node and TypeScript with async boundaries where they helped

Why TypeScript Helped

Enough structure to keep the moving pieces visible

Debugging Across Boundaries

Real bugs moved between systems

📡 Communication Layer In Practice

This was the part of the project I kept coming back to. Communication was not just notification plumbing; it was the layer that helped scheduling, clarification, and follow-through actually work.

Voice, SMS, and Agentic Follow-Up

The communication layer was part of the core product, not an add-on

Configuration and Environment Setup

Provider wiring mattered because the flows were live

Queues and Failure Isolation

Async boundaries made the system calmer

Campaign Scheduling and Lifecycle Logic

Automation was useful when it stayed grounded in the workflow

Why I Still Like This Project

I still like this project because it sits in a space I find genuinely interesting: communications systems tied to real-world logistics. It forced the app, the backend, and the follow-up layer to work together instead of pretending those were separate problems.

How I Tend To Build

I usually want the product context, the backend contracts, the provider setup, and the debugging path to live in the same mental model. Projects like this are a big reason I lean toward TypeScript for full-stack work: it keeps the moving parts visible while still letting me move quickly.