Skip to content

Operator + Technologist

Why an operator, not an agency

I run a real business and build the AI systems that run inside it. Everything on this site, the services, the framework, the opinions, comes out of that combination.

The operating experience

I own and operate Rent With Heldy, a vehicle rental fleet business. Running it means living inside the operational grind every owner recognizes: guest messages at all hours, scheduling, logistics, damage documentation, reporting, and the same information re-entered into different systems more times than anyone would admit.

That kind of work teaches you something no consulting deck does: which problems are actually expensive, which ones are merely annoying, and how little patience a working team has for tools that create work instead of removing it.

Why AI became useful

The interesting shift wasn’t chatbots. It was that software could finally read. Most of the administrative load in a real business is language: messages, documents, requests, notes. Software used to be useless against it, so people carried it. Once AI could read, classify, and draft, that load became automatable, and the economics of a small operation changed.

So I started rebuilding my own workflows around that fact: inbox triage, damage documentation, reporting, the movement of information between systems. Some of it worked immediately, some of it failed usefully, and the pattern of which was which became the basis for Ascension and for the way I now scope this work for other businesses.

What I build now

The Ascension Audit comes first; everything below is implementation that follows from what it finds. Websites built around what visitors should do, dashboards and portals shaped to how a business actually operates, workflow automation where the repetitive load sits, and custom AI that works from a company’s own records. Alongside the building: advisory for owners working out what is worth doing, and training that survives contact with Monday morning, including Safe AI for Students for schools.

How I decide what to build

  1. 01

    Workflow before technology.

    Start with how the work actually happens, then pick the lightest tool that fixes it: sometimes better process, sometimes ordinary software, sometimes automation, and only where language and judgment-shaped work create value, AI.

  2. 02

    The goal is allocation of attention, not maximum automation.

    People should spend their day on judgment, relationships, and exceptions. Systems should carry the repetitive, structured, information-heavy load. When that split is right, the tooling question mostly answers itself.

  3. 03

    Nothing ships that I wouldn’t run.

    The systems I recommend get built and tested inside a real operation first, usually mine. If it isn’t reliable enough for my own fleet, it doesn’t get proposed to yours.

  4. 04

    Teaching is part of the build.

    A system the team doesn’t understand is a system the team stops using. Implementation without teaching doesn’t stick, which is why training is a first-class service and not an afterthought.

Running today

If your business has a grind you can name, we should talk.