Your team spends hours every week retyping information the business already has, and chasing down answers that already exist somewhere. That's time you're paying for twice, and jobs that could have gone out the door.
I find the places where work stops moving, and I build simple systems that keep it moving. Usually inside the tools you already pay for.
Book a free callThirty minutes. If it's worth digging into, a day on one process runs $1,000.
None of this is anybody's fault. It's just what happens when the only thing holding an operation together is people remembering to tell each other things.
Open the back of two service vans and you can tell in three seconds which operator is making money and which one is just staying busy. The guy with the messy van isn't lazy. He's working as hard as anybody. He just loses fifteen minutes on every single job hunting for a fitting, and that never shows up on a report. It shows up as one less job a day and a bad mood at six o'clock.
The same thing is happening in your office right now. Somebody is retyping information that already exists. Somebody is calling to ask a question the company already knows the answer to. Work is sitting still, waiting for a person to carry it to the next place.
You can see a messy van. You can't see a messy back office.
It's spread across an inbox, a spreadsheet, a whiteboard, a text thread, and whatever's in your office manager's head. No single part of it looks broken. That's exactly why it never gets fixed.
A small property management company was taking maintenance requests by phone and email. Someone typed each one into a spreadsheet. The spreadsheet got printed every morning — sometimes twice — so the maintenance team had something to work from. At the end of the day, their handwritten notes got typed back into the same spreadsheet.
That was two to three hours a day of pure re-typing. Requests got logged wrong. Nobody in the office could tell a resident what was happening without walking down the hall to ask. And a request took four days on average to get closed out.
I moved their data into Google Sheets, put a simple request form on their website, and built a straightforward app on top of it so requests could be captured, assigned, and updated in the field. When a tech marked a job complete, the resident automatically got an email telling them what was done.
Four days down to one. Ten to fifteen hours a week back. And residents stopped calling to ask for a status update, because they already had one.
No AI. No new software subscriptions. A form, a database, and a few triggers, set up correctly.
An accounting firm was building journal entries by hand. Every week someone exported a spreadsheet out of a system with no way to connect to anything, worked out the debit and credit amounts line by line, then keyed each entry into QuickBooks — account names, journal numbers, dates, customers, classes, all applied from memory and habit.
I built the calculation and the entry creation into the spreadsheet itself, behind a button. The team fills in the columns they were already filling in, presses go, and the entries land in QuickBooks. Nobody retypes anything. And the rules that used to live in one person's head now live in the script.
They didn't have to learn any new software to use it. That was the point.
Before this, I spent six years at Wells Fargo doing the same kind of work at a much bigger scale. One project: call center reps were opening four separate systems to answer a single customer question — while the customer sat on the line. We pulled all of it into one view that loaded in about five seconds.
That's the same problem a six-person office has when answering "where does my job stand?" means checking a spreadsheet, then an email thread, then calling the tech. Same problem, fewer zeros, and a whole lot cheaper to fix.
I managed a rental portfolio for three years — maintenance dispatch, crews, resident calls, the whole thing — and later spent a year running construction projects. I've done the retyping. I've made the phone calls to find out where something stood. And I've been the person everybody had to ask, because the answer only lived in my head.
I'm an industrial engineer out of Iowa State and a certified Lean Six Sigma Black Belt. This isn't something I picked up from a course last year. It's the actual discipline, and I spent six years applying it at one of the largest banks in the country.
I'll only reach for something complicated when the simple thing genuinely won't do the job. Most of the time it will. If a form and a shared database fixes your problem, that's what you're getting — not a platform you'll be paying for in five years and nobody uses.
I'm based near Ames, and a day walking your operation tells me more than a month of video calls. I work remotely when that's what makes sense — but if you're nearby, I'll come to you.
Tell me what's driving you crazy. Thirty minutes, no pitch, and I'll ask enough questions to tell you honestly whether it's worth paying anybody to fix. Sometimes the answer is no. That's a fine outcome and it costs you nothing to find out.
One process. The one we agreed was worth digging into.
I spend a day with you and the people who actually do that work — not just you, because the people doing it know things nobody upstairs does.
That's yours whether or not you ever hire me again. If you go ahead with a build within 60 days, the $1,000 comes straight off the price.
Most first builds are running inside a month and fix one workflow completely — not three of them halfway. Fixed price, quoted before we start, so there's no meter running.
The build itself is usually a matter of days. What stretches the calendar is getting time with your people to nail down requirements, test it, and learn it — so how fast this goes is partly up to you.
Sometimes the answer isn't software at all.
A fair number of problems get solved by changing the order things happen in, or by one person stopping doing something two other people are also doing. If that's your situation, I'll tell you, and it'll cost you a lot less than a build.
When it is software, I write down exactly what the thing needs to do — in language you can check — before I build anything. I build and test it somewhere separate from your live business, so nothing gets interrupted while it's half-finished. We turn it on gradually. Your people get trained on it, and you get documentation written for a normal person, not for a developer. And I stay close for the first 30 days after go-live, because that's when the real problems show up.
Here's what usually happens to projects like this: someone renames a column, two of the people who knew how it worked move on, the business changes shape, and eighteen months later everyone's quietly back on the spreadsheet.
So there's an optional monthly arrangement — keeping an eye on it, small changes as you grow, a check-in every quarter on whether the system still matches how you actually work, and getting me on the phone quickly when something breaks. Plenty of clients don't need it. It's there because the alternative is watching good work go stale.
Book a call — it's freeUsually not. Most of what I fix is the tools you're already paying for, set up the way they should have been. Where AI genuinely helps I'll use it and I'll explain exactly what it's doing. Where it doesn't, I'll tell you that too.
Mostly it means their day gets less tedious. The retyping and the chasing goes away, and the work you actually hired them for gets more of their time. This isn't about running the same operation with fewer people — for most businesses it's about taking on more work without adding any.
You get documentation a normal person can read, training for the people using it, and 30 days of me staying close after go-live. After that, the monthly arrangement above is there if you want it — and it exists because leaving is the point at which most of these projects quietly die.
The call is thirty minutes. If we go ahead, the assessment is a day with you and a written report back within two weeks. Most first builds are running inside a month after that.
Size isn't really the question. A one-person shop can have the same problem a fifty-person company has. What matters is whether there's manual work happening that doesn't need to — somebody retyping, somebody chasing, somebody looking up an answer that already exists somewhere else. If that's going on, there's something here worth a look.
Usually not. Most of the time it's building on what you already have, or adding one light tool alongside it to cover a gap. Sometimes replacing something is genuinely the right move, and I'll say so if I think it is — but that's not where I start.
Probably. Plenty of owners could. The real question is whether you're going to — it's been on the list since March and you've never had a free Saturday. That's most of what you're paying for: somebody whose entire week is this.