Landscape Supply was a communications-and-logistics problem before it was a storefront. I built a TypeScript React Native app and TypeScript Express backend around that reality, then added Twilio-backed voice and messaging, queue-driven follow-up, and delivery-scheduling automation. The hard part was keeping customer intent, app state, calls, messages, payments, and the final handoff in step.
The admin surface made communication operational instead of incidental. Email templates, campaigns, push notifications, unsubscribe handling, supplier research, and phone-call tooling lived in one place—part of the product, not a scattering of utilities.
I connected the customer app, backend workflow layer, and communication system into one operating product. That meant Node and TypeScript services, the React Native client, async jobs, Twilio, email flows, payments, and the admin surfaces that kept it usable day to day.
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.
I owned product decisions, frontend flows, backend orchestration, communication tooling, and operational debugging. Working across those seams kept the system coherent.
The details below trace the communication layer, backend structure, and operational tradeoffs that made delivery coordination work.
Landscape Supply sits between commerce and field operations. Buying material is easy; coordinating the right quantity, location, delivery window, and site constraints is the real work. Those details are often settled through calls, messages, and follow-up, so the communication layer has to be as reliable as checkout.
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 lifecycle rather than polish one narrow layer.
Success was not only more checkouts. It was fewer preventable mistakes afterward: cleaner scheduling handoffs, faster clarification, better delivery readiness, fewer details dropped between channels, and less thrash between buyer intent and field execution.
I liked this project because the communication layer could not be decorative. Sloppy calls, messages, or follow-up became operational mistakes immediately. That made webhooks, queue boundaries, environment setup, and real-world handoffs worth getting right.
Here is how the customer flow, Twilio-backed communication layer, backend structure, and delivery operations fit together.
This was the project’s core. Communication was not notification plumbing; it made scheduling, clarification, and follow-through work.
I still like this project because it ties communication systems to real-world logistics. It forced the app, backend, and follow-up layer to work together rather than pretend they were separate problems.
I want product context, backend contracts, provider setup, and the debugging path in the same mental model. Projects like this are why I lean toward TypeScript for full-stack work: it keeps the moving parts visible while letting me move quickly.
