Skip to content
Raleigh-Durham, NC — custom systems & automation

Build it once. Then stop thinking about it.

I design, build and run the software a business actually depends on — the field app that works with no signal, the pipeline that files the paperwork by itself, the small tool that deletes a recurring phone call. Production systems, not slide decks.

0+

jobs a week through systems I built

0

daily users across field and office

Multiple

projects live in production for multiple clients

TypeScriptNext.jsReactFlutterPostgresSupabaseNodePlaywrightRow-Level SecurityDurable queuesOffline-first syncTwilioQuickBooksClaude / LLM pipelines
TypeScriptNext.jsReactFlutterPostgresSupabaseNodePlaywrightRow-Level SecurityDurable queuesOffline-first syncTwilioQuickBooksClaude / LLM pipelines
Selected work

Systems running right now, in the hands of people who cannot afford them to fail.

A selection of the systems I build and run for clients. Names withheld — the engineering is the point.

Live in productionsince 2026

techSync

Field capture → payment, without the paperwork

Around fifty technicians document cable-bearing work in places with no cell signal. Six photos and a set of meter readings per job. That paperwork is not admin — it is the thing that gets them paid. techSync captures it offline, routes it through supervisor review, and delivers it into the provider's system of record automatically, with a queue that will not drop a job.

jobs captured per week
0+

jobs captured per week

photos handled per month
0k

photos handled per month

technician & supervisor accounts
0

technician & supervisor accounts

systems stitched together
0

systems stitched together

Read the full breakdown
techSync — data pathlive
Job report inemail report · ~2hAuto-importparse · tag · screenField appoffline · SQLiteSupabase corePostgres · RLSSupervisor reviewapprove / rejectDurable queueretries · idempotentDelivery workerbuilds job packageSystem of recordtriggers tech pay

Everything right of the dashed line sits inside the provider’s own tenant — no VPN, no shared network, no credentials of theirs on our side.

Live in productionsince 2026

signalSync

The answer to a question that used to cost a phone call

Technicians finish an install and need to know one thing: did my equipment test upload, and did it pass? Getting that answer meant phoning a supervisor, who logged into a vendor portal and read a grid. signalSync turns that into a text message. Send a job number, get a plain-English verdict with the exact components that failed.

jobs a day in scope
~0

jobs a day in scope

from question to answer
~0s

from question to answer

automated tests, all green
0

automated tests, all green

monthly running cost
<$0

monthly running cost

Read the full breakdown
sS

signalSync

online

Illustrative. Real replies carry the client’s own compliance matrix.

What I actually do

Not a template shop. Not a no-code stack held together with tape.

The work is ordinary software engineering applied to unglamorous business problems — done properly, so it keeps working after the invoice is paid.

Apps that work with no signal

Offline-first mobile capture with a local database as the source of truth, and a sync engine that resumes instead of restarting. Built for crews in basements, trenches and dead zones.

Pipelines that don't lose things

Durable queues, idempotent writes, explicit state machines and per-item status. When something fails it retries; when it keeps failing it tells you, loudly, with a button to re-run it.

Integration with systems that resist it

Locked-down tenants, security policies that block the obvious route, portals with no API at all. There is almost always a path — it just has to be found, proven, and then made boring.

Data models you can still change later

Postgres, migrations under version control, row-level security so access is enforced by the database rather than hoped for in the UI. Schema decisions made once, deliberately.

AI where it earns its place

Transcription, extraction, classification, natural-language lookups — used when a model genuinely beats a rule, and skipped when it doesn't. No AI theatre on top of a problem a query solves.

Systems that stay run, not just built

Monitoring, alerting, runbooks, incident write-ups. Every failure in production ends in a document explaining what happened and what changed so it cannot happen the same way twice.

Starting points

Common problems I've already solved once.

These are patterns, not products off a shelf — each one gets shaped around how your business actually runs. They're here because they're the requests that come up most, and because they're a cheap way to find out whether we work well together.

How it works

Four steps, no mystery, no retainer you can't get out of.

You will always know what is being built, what it costs, and what happens if it breaks at 6pm on a Friday.

  1. A call, then a day of watching

    Week 0 — free

    Thirty minutes on the phone to work out whether this is even worth building. If it is, I spend real time watching how the work happens today — the spreadsheet, the group chat, the thing somebody retypes every Friday. Most of the value gets found here, not in the code.

  2. A written scope with a number on it

    Week 1

    What gets built, what explicitly does not, what it costs to build and what it costs to run every month. Fixed price. If I think the honest answer is "a spreadsheet and a rule", you get told that instead of a proposal.

  3. Something usable, early and often

    Weeks 2–6

    Small pieces in your hands quickly, so course corrections are cheap. The riskiest part gets built first — the integration nobody is sure is possible, the offline path, the bit that touches money. Never the easy screens first.

  4. Live, then watched

    Ongoing

    Go-live is the start of the job, not the end. Alerting on the paths that matter, a runbook for whoever is on the phone, and a written post-mortem for anything that breaks. You own the code and the accounts either way.

Who you’d be working with

One developer who has been on both sides of the problem.

I spent years building software for companies of every size, and kept running into the same thing: the inefficiency costing a business thousands a month was often a week of work to fix. Nobody was fixing it, because the companies who could afford to were chasing bigger contracts.

ClearPathFlow exists for that gap. Today that means everything from a text-message tool that saves a supervisor forty phone calls a day, to a full field-capture pipeline that fifty people depend on to get paid. Same standard of engineering either way.

I also lean hard on AI-assisted development — it is a real part of why one person can build and run systems at this scale, and I’m happy to show you exactly how on a call.

Ground rules

  • A small number of clients at a time, so each one gets real attention.
  • Standard platforms only — your data and your workflows can always leave with you.
  • Everything documented, so the next developer isn't starting from archaeology.
  • If an automation isn't saving real time or real money, it doesn't get billed.

Based in

Raleigh, North Carolina

Serving the Triangle in person, everywhere else remotely.

Questions

The things people ask before they trust a stranger with their operations.

If yours isn't here, ask it on the call — I'd rather answer it early.

One developer. I take a small number of clients at a time so each one gets real attention, and you always talk to the person writing the code — there is no account manager between us. Where extra hands genuinely help, I bring in people I've worked with before and I stay accountable for the result.

Tell me the thing your team retypes every week.

Thirty minutes, no pitch. I’ll tell you whether it’s worth automating, roughly what it would cost, and if the honest answer is “don’t bother” — you’ll hear that too.

hello@clearpathflow.io · Raleigh-Durham, NC