Work With Me.

Alongside my primary businesses, I take on one or two clients a year whose companies have outgrown the systems holding them together. We start with the business problem, not a predetermined software project.

I approach client work as an owner. The systems I build for my own businesses have to hold up in production, so I bring the same questions to yours: Is it worth building? Will the team use it? Can the business own it without depending on me?

Where I Help

Most clients do not need another all-or-nothing software decision. They need someone who can understand how the business operates, identify the real constraint, and carry the work from diagnosis through implementation.

  • Reporting nobody fully trusts
  • Workflows held together by spreadsheets and duplicate entry
  • Disconnected field, office, sales, and customer systems
  • A product or internal platform the business can no longer operate without
  • AI plans built on scattered data and undocumented decision rules

Real estate, construction, and the trades are my bread and butter, but not my boundary. I know these industries well enough to ask the right questions early and learn how your business actually runs faster. The more complex the operation and the more expensive the mistakes, the more useful I am in making the business legible and turning that complexity into a coherent system.

My Software Design Philosophy

Business operators and software developers tend to view the world from very different perspectives. Whether it's implementing off-the-shelf solutions or designing custom tools, this difference in worldviews is the cause of much business-related pain.

The central problem has always been, and for the foreseeable future will continue to be, the ability to translate business needs into software requirements. Even then, software cannot succeed when it is asked to impose a digital solution on a flawed real-world system or process.

In a world dominated by AI this matters more than ever because AI makes software easier to produce, but it does not make a business easier to understand. When applied before the workflows, data, and decision rules are clear, software solutions will make a bad system worse. This has always been true, but AI is accelerating the consequences.

Before deciding what software should do, you must first understand how the business actually works, where it breaks down, and whether software is even the right answer (handwritten checklists have worked for thousands of years!). In that sense, my software development process begins many feet away from the computer.

How I Work

  1. 1

    Make the business legible

    Map how work, information, decisions, and handoffs move through the company before deciding what the technology should do.

  2. 2

    Choose the right intervention

    Keep what is working, connect what should talk, remove what is getting in the way, and build only where the gap justifies ownership and maintenance.

  3. 3

    Ship for real use

    Design and implement the system with the people who will use it, then document it so the business can own it without depending on me forever.

What I Build

  • Custom Operations Platforms. Internal platforms, dashboards, and reporting designed around real-world processes and tested with the people who will use them, so adoption problems surface early and the data stays trustworthy.
  • Data & Automation. Pipelines and process automation that remove duplicate entry and unnecessary manual work, turning scattered data into decisions people trust.
  • Field & Client Software. Field operations tools, client portals, and mobile apps that connect the office, the field, and the customer.
  • AI-Assisted Workflows. AI where it actually helps, structured around your business knowledge and decision rules instead of bolted on.

Those are components, not the offer. The deliverable is a business that no longer depends on duct tape to run.

Ongoing Leadership

For companies that need ongoing technical leadership, I also work as a fractional CTO. I take responsibility for the architecture, roadmap, data model, vendor decisions, and implementation rhythm.

A typical fractional CTO owns the technology function. I extend that ownership into the operating model and ship the software that makes it durable.

Who It Fits

I work best with founders and operators who know their business deeply, feel the operational drag, and want a builder who will understand the business model before touching the technology.

I'm probably not the right fit if you want the cheapest engineering resource, a pixel-for-pixel build from a fixed spec, or an advisor who stops at strategy.

The operating businesses and products in my portfolio show what that looks like in practice.

The right system reduces what your team has to remember and re-enter. It fits the real work well enough that people will use it. If that is not what you have,