PhortixLet’s talk
03 / Infrastructure

Every part
has a purpose.

Good infrastructure connects a useful input to a dependable next step—with boundaries you can understand.

Explore the pipeline
PHORTIX / A MORE SYSTEMATIC TOMORROW
A documented system

Connected by design.
Distinct by responsibility.

The LeadBackstop pipeline is our concrete reference: intake, processing, persistence and human follow-up.

LEADBACKSTOP / DOCUMENTED PIPELINEInteractive illustration · not live data
01 / Inbound phone call

The conversation begins.

A customer calls while a contractor is occupied. The inquiry enters the automated intake path.

Select a step to explore the system.
Engineering principles

Clarity at
every boundary.

01

Separate responsibilities.

Voice intake gathers context. Event processing carries it forward. Persistence keeps it available. Each component has a defined role.

02

Make state understandable.

Captured, processed, stored and reviewed are different states. A successful handoff should never be confused with a completed human action.

03

Design for inspection.

Structured fields and explicit component boundaries make it easier to reason about what entered a system and what needs to happen next.

Failure-aware thinking

The exception is
part of the design.

These are engineering considerations, not uptime guarantees or claims about unverified monitoring features.

BOUNDARYQUESTION TO RESOLVE

Incomplete intake

Can a human distinguish missing information from information that has been confirmed?

Processing interruption

How can work be inspected or retried without confusing a repeated event with a new inquiry?

Notification failure

Does the stored lead remain distinguishable from the email alert that announces it?

Human handoff

Is the next action clear, without implying that an appointment has already been booked?

Infrastructure in context

The foundation.
Not the headline.

Cloudflare, Vapi, Supabase and Resend are components of the documented LeadBackstop system. Phortix’s focus is the useful whole they help create.

See the product boundaries
Read the system

What crosses
each boundary?

A component name explains where work happens. A contract explains what the next component needs to receive.

ComponentResponsibilityWhat it does not prove
Vapi

Capture the caller’s information through automated voice intake.

That a reported symptom is a diagnosis.

Structured output

Represent the inquiry as defined lead fields.

That every field is complete or independently verified.

Cloudflare Queue / Worker

Process and carry the structured event through the pipeline.

That a person has read or acted on the inquiry.

Supabase

Persist the lead information for the dashboard data layer.

That the inquiry has become an appointment.

Resend / dashboard

Surface information for human follow-up.

That the contractor has contacted the caller or completed a job.

An engineering note

A notification is not
the record itself.

Processing, storage and delivery solve different parts of the problem. Keeping those responsibilities separate makes a system easier to reason about.

The email tells someone that an inquiry is available. The stored context explains what that inquiry contains.

Those two events should not be treated as equivalent. A message may be delayed or overlooked even when the underlying information exists. Likewise, storing information does not prove it has been reviewed.

This distinction matters when defining operational states: captured, processed, persisted and available for review. A person’s follow-up remains a separate action.

Retries, duplicate-event handling, delivery monitoring and access rules belong in implementation review. They are engineering questions to verify, not capabilities or guarantees to assume from a diagram.

The next useful conversation

Start with
the problem.

What is getting in the way?
Let’s give it some structure.

Start a conversation