0x.Dev

0x.Dev · full-stack engineer

Software that works while I sleep.

I build products end to end: interface, API, payments, servers, and the AI agents that keep them moving.

  • readsthe whole path
  • shipssmall, reversible
  • provesit live

I’m 0x.Dev, a full-stack engineer who likes owning the whole thing, from the first sketch to the server it runs on.

I’ve built distribution platforms, white-label software, payment systems, real-time apps and a newsroom staffed by AI agents. I run them on infrastructure I set up and harden myself. I move fast, I verify everything, and I write down what I learn so the next fix is quicker.

alias
0x.Dev
based
the internet
role
engineer, product, ops
writes
TypeScript, PHP, Python
runs
Linux, nginx, Cloudflare, AWS
status
shipping

Ship log.

Counted by the servers themselves every fifteen minutes: commits that land on live repos, releases cut, and server changes made by hand.

ships
active days
longest streak
days in a row
busiest day

asking the server…

Five rules I don’t bend.

They’re boring on purpose, because boring is what survives contact with production.

  1. Read the whole path.

    Before I change a line, I follow the request from the click to the database and back. Most bugs live in the hand-offs between the parts.

  2. Secure by default, not by phase.

    Least privilege, no secrets in code, nothing running as root that doesn’t need to. Security gets built in as I go, so there is never a big clean-up sprint at the end.

  3. Ship small, verify live.

    Every change goes out in a slice I can roll back in seconds. It counts as done once I’ve watched it work in production, whatever the tests said.

  4. Write it down.

    Runbooks, decisions, and the trap that caught me last time. The next person to touch this might be me, at 2am, half awake.

  5. Automate the second time.

    Do it by hand once to understand it. The second time, it becomes a script, a cron job or an agent, with logs and an off switch.

  • TypeScript
  • PHP
  • Node.js
  • React
  • Next.js
  • Python
  • MariaDB
  • PostgreSQL
  • Redis
  • nginx
  • Docker
  • Linux
  • Cloudflare
  • AWS
  • WebRTC
  • Electron

Every job, the same four moves.

Big change or one-line fix, it goes through the same loop, and the loop is what keeps it safe.

  1. Map

    Read the code, the logs and the data before touching anything. Name every root cause, including the quiet ones.

  2. Build

    Small, reversible changes. Boring tech where it matters, sharp tools where they pay for themselves.

  3. Prove

    Test in a real browser, against real data, at real screen sizes. Then check it again, live.

  4. Hand over

    A short report: what changed, what I verified, what’s still open, and how to roll it back.

What I do.

Mostly the unglamorous middle: the parts that move money, data and messages around without drama.

Platforms

Multi-tenant products, admin consoles and the APIs behind them. Built to carry many customers on one codebase.

Payments

Checkout, invoicing, recurring billing, and the reconciling nobody sees.

Infrastructure

Linux, nginx, DNS, TLS, backups. I run what I build.

Automation and agents

Crons, queues and AI agents with guardrails, logs and an off switch.

Real-time

Chat, presence and live dashboards that stay in sync.

Meet Hex.

My rubber duck, upgraded. Hex reads the logs with me, cheers every deploy and dozes off when the cron jobs take over.

or give Hex a tap

Defaults, written down.

If you work with me, this is what you get without having to ask.

0x.dev/working-style.toml
  1. # the defaults, so nobody has to ask
  2. [working_style]
  3. read_before_write = true
  4. change_size = "small, reversible"
  5. done_means = "verified live"
  6. secrets_in_code = false
  7. runs_as_root = "only when it must"
  8. docs = "every trap, written down"
  9. reviews = "line by line"
  10. automate_after = 2 # times by hand

Working together

  • Async first. A clear written update beats a long call.
  • I keep what I verified apart from what I assume.
  • Bad news travels first, because a problem found early is cheap.
  • Reports in plain language, so anyone can act on them.

Good software is mostly invisible. It loads fast, fails loudly, recovers quietly and leaves a trail you can follow. I build for the day something breaks, because that day always comes.