One person’s memory is holding your operation together.
Most small operations run on several systems at once, 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 happens.
The person who became the system
Whoever understands how everything connects becomes the system by default. 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’s 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 won’t quote a system for a workflow I haven’t watched.
One week
Workflow Audit
I spend a week on how the work happens day to day: what you’re 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.
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 the audit 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.
I scope new features and new integrations separately, so a focused build doesn’t 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
You own what I build
Your system shouldn’t turn into a dependency on me.
Wherever possible, I build inside accounts you own from the first day: the code repository, the hosting account, the domain, the billing, the service credentials, the production data. I’m invited with the access I need to build and deploy, and that invitation can be withdrawn the day I hand the system over.
I design the system, direct the build, test it, and stand behind the result. You work with me start to finish, and nothing gets handed to a team you never meet. The decisions that matter are mine, including where the security boundary sits.
Both engagements are fixed in scope and fixed in price, agreed in writing before the work begins. I don’t bill hourly and I don’t sell retainers.
How the work moves
01
Tell me where the friction is
Start with the contact form: what you’re 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.
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.
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.
04
Review it while it’s 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.
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.
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
I learned everything I know about this pattern 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 won’t touch a repository without asking me first.
I’ve 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 isn’t the right answer?
- Then I’ll 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 don’t troubleshoot unrelated technology or take over maintenance of software I didn’t write.
- What does it cost?
- I quote both engagements as a fixed price in writing after we’ve talked, and the build price comes out of the audit brief rather than a guess. Tell me what you’re dealing with and I’ll come back with what it’d take.
- Can you promise it’ll save a specific number of hours?
- No, and I’d be careful with anyone who does before they’ve seen your workflow. What I’ll 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’s exactly why I build in your accounts rather than mine.
- Who’s this 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 same pattern shows up in other back offices. I’m in Austin, so in person locally and remote everywhere else.
Tell me what you’re 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’ll explain why. If I think you’d be paying me to solve the wrong problem, I’ll say so.