10x with DexRelay · published March 17, 2026

Future of building is on phone.

I have roughly 25 apps running, and I code from my phone all day now. DexRelay turned my iPhone into the control plane for Codex on my Mac, so work keeps moving when I am away from the desk, in transit, or sitting in a coffee shop.

The Mac is still the machine. The phone becomes the company.

Remote Codex threads Build and install iOS apps OTA over Tailscale Speech to code

What changed

Why DexRelay feels 10x.

1

One surface for prompts, approvals, project context, build status, and install links.

24/7

Work no longer waits for “when I get back to my laptop.” Idle time became operating time.

25

Multiple active projects, multiple threads, multiple live loops from the same phone-first workflow.

This is not “mobile coding.” It is mobile orchestration of a real runtime.

What DexRelay actually does

Real operations from an iPhone.

Code and control

Connect to Codex on a Mac over WebSocket and continue any thread.
Approve commands and file changes without touching the desk.
Browse Mac project files from the phone.
Queue follow-ups and planning tasks beyond a basic chat box.

Build and ship

Build and install iOS apps without touching Xcode’s UI.
Publish OTA install artifacts and open them from the phone.
Persist project, scheme, and device defaults for faster loops.
Keep selected-thread build status visible while away.

Operate the Mac

Upload files, images, and attachments quickly from the phone.
Run backend services on the Mac through a command center.
Work outside the home network through Tailscale.
Use speech dictation because talking to code is the obvious next interface.

How DexRelay works

iPhone control plane. Mac execution host.

1. iPhone app

SwiftUI client that lists threads, starts turns, streams activity, handles approvals, attachments, dictation, planning notes, and build actions.

connects to :4600

2. DexRelay bridge

Node bridge that normalizes WebSocket behavior for iOS, trims oversized history for mobile safety, and exposes local helpers for shell execution and media upload.

local/exec · local/uploadMedia

3. Codex app-server

The Mac runs Codex thread and turn logic against local source trees, tools, files, and git state. This is where actual execution happens.

app-server on :4500

Network shape

Phone and Mac sit on the same tailnet. The iPhone connects to the Mac’s Tailscale address on port :4600. The bridge forwards upstream to Codex on :4500. DexRelay also uses launchd services on the Mac so the relay survives normal day-to-day use.

Why the bridge exists

Direct iPhone-to-app-server WebSocket behavior was unstable in this setup. The bridge fixed handshake issues, reduced payload size, and made large thread history safe enough for the phone UI.

How I am building

DexRelay was built using DexRelay.

Recursive product loop

I use the phone client to steer Codex on the Mac, approve edits, inspect files, trigger builds, install new versions, and then use the improved app to build the next improvement. The tool compounds itself.

That loop matters more than any single feature. The product is useful because it is inside its own feedback cycle every day.

Why that is 10x

The delay between idea, prompt, approval, build, install, and reaction collapses. Instead of losing momentum every time I leave the desk, the system keeps compounding through the day.

It is not that I type on glass. It is that I keep the factory running from the phone.

A product becomes serious when it can build more of itself.

Interfaces dying

Terminal is dead. IDE is dead. PRD is dead.

Terminal is back-end infra

The shell still exists, but it stops being the primary user interface. It becomes a service layer the agent can call.

IDE is execution context

Xcode and editors still matter, but more as toolchains than as the center of attention. The control layer is moving upward.

PRD becomes live steering

Instead of freezing intent in a static doc, you keep a project thread, subthreads, plans, and approvals alive. The spec now updates while the product is being built.

Interfaces don’t disappear. They get demoted.

Model opinion

For this workflow, Codex > Claude Code.

Why

DexRelay is built around Codex app-server semantics: thread lifecycle, turn execution, approvals, streaming output, and project continuity. That protocol-driven shape makes remote control feel operable rather than hacked together.

The actual difference

Once you can orchestrate many threads, persist project context, and keep approval/build loops moving from a phone, the winning tool is the one that behaves like an operating substrate, not just a smart autocomplete or a single-agent chat.

This is not a benchmark claim. It is a workflow claim. In a phone-first remote setup, the stack with the better control surface wins.

From coding to orchestration

Orchestrating beats typing.

Old loop

Open IDE. Write code line by line. Switch to terminal. Wait. Fix. Repeat. The operator is buried inside tools.

New loop

Set direction. Allocate work across threads. Approve critical actions. Check build and user feedback. Adjust taste, not just syntax.

The scarce skill is no longer “can you code?” It is can you steer intelligence toward something people actually want?

Declaration

All that needs to be built can be built using Codex.

If you cannot build it, the first limiter is often token budget.
The second limiter is willingness. Most people stop before the steering gets good.
The third limiter is taste. Intelligence without taste just produces more output.
Put simply: the job becomes learning how to steer an intelligence.

Soon nobody will care that someone can “build with AI.” The harder question will be whether they can make something adopted, wanted, and worth returning to.

Org design

Multi-nested threads can mimic an org chart.

One person company

Project

Owns the mission, constraints, and release target.

VP Product Thread

Writes plan, validates user value, keeps scope coherent.

VP Design Thread

Owns interface quality, screenshots, hierarchy, and taste.

Senior IC Subthreads

Implementation, QA, release ops, content, support docs, and follow-up fixes.

What changes

You do not need a giant org to create functional specialization. You need a clean thread hierarchy, reusable skills, clear context, and an operator who can assign work well.

The future builder looks less like a solo coder and more like a CEO managing a bench of VP agents.

The leverage comes from structure: project → thread → subthreads, as deep as needed.

Value shifts

Building becomes cheap. Adoption becomes the test.

What stops mattering

“Can you build a product?” rapidly becomes table stakes. The internet will be full of demos, clones, launch screenshots, and fake momentum.

What matters more

Distribution, product instinct, retention, social proof, and network effects. Not the claim that you built it, but whether people use it.

The moat shifts from code production to taste + adoption + distribution.

Close

Phone-first building is here.

DexRelay is my current proof: remote Codex threads, approvals, project files, backend service control, build/install loops, OTA distribution, and speech-driven prompting from one iPhone UI. That operating model changed how I work.

Core thesis

Future of building is not one more desktop IDE panel. It is a control system for intelligence, available from the device already in your hand.