Diamondback Systems LLC

I make AI‑assisted software
safe to ship.

Senior engineer and former CTO. Two decades of judgment about what to build, how to prove it works, and when the model is confidently wrong — pointed at regulated, security-intensive systems that businesses actually run on.

Greenfield products · Legacy modernization without rewrite risk · Advising founders who need to get it right the first time

How I work

Speed is the consequence. Judgment is the product.

Every developer now says they use AI to move faster. That claim is worth very little on its own — and it invites exactly the discount it deserves. What I actually built is a delivery system that produces the artifacts of a mature engineering organization, from one person.

  1. Design before code, written down

    Over a hundred dated design, implementation, and handoff documents in the last year alone. Each one states the problem, the options I considered, the tradeoffs, and the decision — before any code exists. The thinking becomes a committed, reviewable artifact instead of something that evaporates when the session ends.

  2. Interface contracts between tiers

    When a change spans a web app, an API, and a mobile client, I write the contract first — including the alternatives I rejected and why, plus the test cases that prove it. That is how one engineer coordinates work that normally needs three teams. Hiring me is not buying a pair of hands; it is buying the delivery function around them.

  3. An executable definition of "healthy"

    My deployments are gated by a command that verifies the system before it takes traffic — every database connection, cache, queue, extension, and writable path, plus the settings that are dangerous when wrong. It exits non-zero and fails the deploy automatically. This is the honest answer to the real question about AI-assisted development: how do you know it works?

  4. Compliance and security as architecture

    Encryption, append-only audit trails, and non-negotiable data-handling rules belong in the structure of the system, not in a checklist somebody reviews later. I encode them as invariants the codebase enforces on every contributor — including the AI ones.

  5. Context that survives me

    Every project carries living documentation of its architecture, its failure modes, and the domain quirks that would otherwise live in one person's head. Across four languages — PHP, Dart, TypeScript, Java. The thing clients fear most about hiring a contractor is what leaves when the contractor does. I write it down from day one.

How the work actually moves

Five stages, each leaving a durable artifact behind. The speed comes from the structure, not from skipping it.

  1. Design doc

    Problem, options, tradeoffs, decision — written before any code exists.

    dated markdown, in the repo

  2. Interface contract

    What each tier owes the others, including the alternatives rejected and why.

    handoff doc + test cases

  3. Build

    AI writes a great deal of the code, against invariants the codebase enforces.

    reviewed commits

  4. Verification gate

    A command that proves the system is healthy. Non-zero exit fails the deploy.

    automated, blocking

  5. Committed context

    Architecture, failure modes, and domain quirks documented for whoever comes next.

    survives the engagement

The loop that makes it compound

What the verification gate catches becomes a new invariant. What surprised me becomes a line in the context doc. The next project starts further along than the last one did — which is why the pace is sustainable rather than a sprint.

Every box is a file in the repository. Not a process diagram describing intentions — the actual artifacts, dated and reviewable.

AI writes a great deal of my code. The judgment about what is correct, what is safe, and what is about to break is mine — and right now, that is the part that is hard to buy.

Selected work

Products that had to be right.

Some of this is mine. Some was built under contract and stays unnamed. The engineering is described either way.

ScrybeX

Founder & lead engineer

A HIPAA-conscious clinical documentation platform for licensed speech, physical, and occupational therapists. Laravel API, Flutter apps for iOS and Android, admin console, and the full AWS footprint — designed and shipped end to end in about five months.

  • Laravel
  • Flutter
  • AWS Bedrock
  • Terraform
  • HIPAA

Read the architecture →

Legacy modernization

Confidential

Regulated document platform

A mission-critical platform producing high-stakes, legally binding documents. I replaced the aging render tier with a modern one that produces byte-for-byte identical output — modernization the business never had to bet on.

  • Java Lambda
  • Laravel
  • Strangler fig
  • AWS

Read the architecture →

Renovation Defenders

Founder & sole engineer

Six substantial product domains inside one platform: video course delivery, e-commerce with Stripe checkout, a multi-step estimator that generates PDFs, an SEO-driven publication, a user video contest, and an admin back office — plus a Flutter companion app.

  • Laravel
  • Flutter
  • Stripe
  • Elastic Beanstalk

Read the architecture →

Multi-role venue CRM

Confidential

Built under contract

A real-time operations platform for a hospitality setting, with seven distinct user types — each with its own authentication path, permissions, and interface. Live messaging, GPS-based presence, SMS escalation, and a three-way payment split via Stripe Connect.

  • React
  • Firebase
  • Stripe Connect
  • Real-time
  • PWA

Self-directed product work

Fully owned

A mobile game platform with a shared Laravel backend, scheduled content generation, and full AdMob monetization — live on both app stores as Decode Daily, with further games running on the same engine. Alongside it, a set of owned apps covering every major mobile monetization model, built to keep the craft sharp.

  • Flutter
  • Laravel
  • AdMob
  • App Store
  • Play Store

Read the architecture →

Under the hood — a real-time, multi-role platform

Built under contract for a hospitality setting. The client and the product stay unnamed; the architecture is the part worth showing.

Seven roles, two authentication paths

  • Four QR-entry roles

    Phone number and one-time code. Entry is a QR link that establishes the location context before auth, so a walk-in never installs anything or creates an account.

  • Three credentialed roles

    Email and password, scoped by tier: on-site operations, location ownership, and platform administration across every location.

Real-time core

  • Live roster
  • Presence & session state
  • In-app messaging
  • SMS escalation when a session goes quiet
  • Moderation queue
  • Per-role theming

The two hard parts

  • Three-way payment split

    Stripe Connect: a platform fee and a location fee are deducted before the recipient's payout, handled in cloud functions with onboarding and webhooks. Money moving three ways means the edge cases are the product.

  • Geofencing

    GPS-bounded entry with a configurable radius per location, plus automatic checkout when someone leaves. Presence has to reflect physical reality, not just an open tab.

Seven user types is the design problem. Each one needs a different view of the same live state, on the same device, in the same room — with permissions that hold when two of them are looking at the same record.

This work is under NDA. The patterns are shown; the client is not.

The long view

Twenty years of systems that stayed up.

The methodology above is recent. The judgment behind it is not — and it is the reason the speed is trustworthy rather than alarming.

Still running

scout

The configurable auditing platform I built two decades ago as Diamondback's founding product. It is still in production today, still used by hospitals. Software I wrote before most of today's frameworks existed is still doing its job.

2009 – 2023

Dealer Safeguard Solutions

Fourteen years as CTO. An automotive SaaS platform on AWS serving more than 50,000 users across 1,000+ dealerships, under PCI compliance. Now part of Informativ. I am proud of that run, and it is where most of this judgment was earned.

M.S. Computer Engineering, Southern Methodist University — a formally trained engineer, not a recent convert.

Contact

If it has to be right, I would be glad to talk.

Whether you are building something new that cannot afford to be wrong, or you have inherited a system nobody wants to touch — those are both the interesting problem.