One person's memory is holding your operation together.

Most small operations already have a system. They have several, and keeping them lined up has become somebody's second job. Part of the work sits in one app, part in a spreadsheet, part in somebody's inbox, and the rest is in your head. I build the internal tool that pulls those pieces into one place, shaped around how your work actually happens.

The person who became the system

It happens by default, to whoever understands how everything connects. Everyone knows who to bring a question to, and who can turn a pile of loose information back into something usable. It holds up until that person is buried, or misses something, or wants a week off.

I know that job because I had it. Six years in operations, two of them running parts for an auto dealership, sitting between the dealer management system, the vendor portals, a spreadsheet somebody built in 2019, and the people who needed answers out of all three. Two thousand active part numbers. Fifty to two hundred purchase orders and vendor invoices reconciled every month.

I rebuilt the administrative playbook the department ran on, and it took roughly three hours of unnecessary work out of an eight hour day. I followed the work end to end and wrote down what I found.

That is still the first half of the job. The difference now is that software comes after it.

Two ways to work together

Every build starts with an audit. I will not quote a system for a workflow I have not watched.

One week

Workflow Audit

I spend a week on how the work actually happens: what you are trying to keep organized, where the information lives, who touches it, what gets typed twice, and which steps depend on somebody remembering at the right moment. We also decide what should stay human, because a system can carry the coordination without taking over the judgment that makes the work yours.

The brief is yours to use without me. Take it in house or take it to a developer. You can also decide the answer is to change a process and build nothing at all. Those are all real outcomes, and none of them owes me anything further.

  • A map of how the work moves today
  • Where information is duplicated, delayed, or held in someone's memory
  • A prioritized recommendation for what to change first
  • A written build brief: scope, information sources, integrations, risks, success criteria, timeline

Up to four weeks

Focused Build

If the audit says a custom tool is worth building, we agree the scope and the price before anything gets built, with the definition of done in writing. Then I build one system around the workflow we mapped. That might be inventory, purchase orders, vendor follow-up, scheduling, reporting or reminders arriving in a single view. The shape comes from your operation.

New features and new integrations are scoped separately, so a focused build does not turn into a permanent one.

  • The working tool and the agreed integrations
  • Deployment into accounts you own
  • Source code, documentation, and a training session
  • Thirty days of support afterward for defects and handoff questions

How the work moves

  1. 01

    Tell me where the friction is

    Start with the contact form: what you are trying to keep organized, where it lives now, and what depends on somebody remembering. We talk, and we decide together whether the problem is specific enough to audit.

  2. 02

    Map the real workflow

    I follow the process that exists, not the tidier one everybody wishes existed. The people, the tools, the handoffs, the work that gets done twice, and the calls that need a human.

  3. 03

    Agree on the first useful build

    One problem, one written definition of done, and a clear list of what I need from you, all settled before development starts.

  4. 04

    Review it while it is still moving

    I build in short iterations and show you working versions, so a misunderstanding about how your work happens surfaces in the first week instead of at launch.

  5. 05

    Launch it inside the operation

    I connect the sources, configure access, test against real work, and help your team start using it. Implementation is part of the build rather than a separate invoice.

  6. 06

    Hand it over

    The tool, the source code, the documentation, and a recorded training session. Thirty days of support begin at launch, and my access comes down to whatever level you choose when they end.

The work behind this

Everything I know about this pattern, I learned by building it.

Lumen Daily is the planning app I use every day: an installable phone app on a Cloudflare Worker backend with its own database, push notifications and scheduled jobs. AI Workspace Hub is the private workspace I run my own builds from. It drives three coding agents against my repositories from one place and carries a project's context across a change of model. It will not touch a repository without asking me first. Both are written up in full, with the architecture and the decisions included.

I have also built and delivered a system for a curated events business here in Austin. The strongest decision on that project was one I argued myself out of: the software proposes the guest groupings and shows its reasoning, and the owner still makes every call.

Straight answers

What if AI is not the right answer?
Then I will tell you. Sometimes the fix is a simpler process, one source of truth, or deleting a step nobody needs. The audit exists to find that out before either of us commits to building the wrong thing.
Do you do IT support?
No. I can connect a system I build to the tools you already use, but I do not troubleshoot unrelated technology or take over maintenance of software I did not write.
What does it cost?
Both engagements are quoted as a fixed price in writing after we have talked, and the build price comes out of the audit brief rather than a guess. Tell me what you are dealing with and I will tell you what it would take.
Can you promise it will save a specific number of hours?
No, and I would be careful with anyone who does before they have seen your workflow. What I will commit to is a written definition of done, agreed before development starts.
What happens if you disappear?
You own the accounts, the code and the documentation from the beginning, and the handoff includes a recorded training session. That is exactly why I build in your accounts rather than mine.
Who is this actually for?
Small businesses and independent operators with real back-office volume and no internal technical team. Parts and service operations are where my own experience runs deepest, though the pattern is not particular to them. I am in Austin, so in person locally and remote everywhere else.

Tell me what you are trying to keep organized.

Use the contact form. What the moving pieces are, where they live now, and what becomes harder than it should be because nothing brings them together.

If an audit is the right next step, I will explain why. If I think you would be paying me to solve the wrong problem, I will tell you that instead.