Review
Flow.

01 / THE BUILDAn automation you can actually follow

A review request normally disappears into the background: someone starts it, a message goes out, and the customer sees a different screen. That makes the workflow difficult to show in a portfolio.

I built Review Flow so one visitor can try both sides. The business portal starts a request. An interactive phone shows the simulated message. Opening it leads to a review screen. Instead of asking someone to imagine the automation, the demo lets them follow it.

This is a simulated automation project. No SMS is sent by this page, and completing the review example does not publish a review anywhere.

02 / THE BUILDStart the request. Then change seats.

The original interface puts the business form and the phone next to each other. The form collects a name, phone number and delay; the phone makes the result visible after that delay.

The explanation below uses fixed fictional details rather than asking for customer information. Move the clock forward, open the message, and try the review interaction. The important part is the handoff from one perspective to the other.

A status label needs to mean what it says. In this demonstration, simulated means the scheduled point in the example has arrived. It does not mean a phone carrier accepted a message or a customer received it.

03 / THE BUILDTwo backends, one demonstrated interaction

The published build uses React, TypeScript, Vite and Tailwind CSS. Its source account describes an Express backend with an optional Twilio path, restricted to one allowlisted number, and a separate Cloudflare Worker deployment running in simulated mode.

Those are different operating modes, not interchangeable evidence of delivery. The public demonstration shows the interaction; the optional real-message path is not exercised here.

The Worker avoids keeping pending requests in a server-side store. Its identifier contains the submitted fields and the creation time. A status request decodes that identifier and compares the clock with the selected delay. The companion article shows the actual excerpt.

That is a useful simplification for a deterministic simulation. It is not a substitute for tracking a real provider response. The identifier also contains data, not just an opaque reference, so the demonstration should use fictional information.

04 / THE BUILDWhat I worked on

My contribution covered the interface, the two-perspective interaction, the Worker API and deployment. The visible design and the backend approach serve the same goal: make a small workflow understandable without requiring a visitor to set up a messaging account.

The phone is not there just to decorate the page. It gives the next state somewhere to appear. The adjacent business controls make it clear what caused that state to change.

05 / THE BUILDThe next changes are specific

The original write-up identifies three improvements: replace one-second polling with a more deliberate status-update approach, share the API types between the Express and Worker implementations, and configure a genuine business review destination for a real deployment.

Those remain proposed changes. Before turning this into a customer-facing messaging system, the real delivery path and data handling would need their own implementation review.