I start by understanding the problem and gathering real sample data. Then I build one small, working version before anything bigger. After it goes live, the team's work changes noticeably. Some staff take time to adjust. New requests emerge because people see what is possible. My job includes ongoing support each month and pushing back on scope until we have real answers, not guesses.
When a founder or operations lead searches for help with a process that is eating time, what they are really asking is: what is this actually like? What happens in the first week, the first month, and after that? Not the pitch. The real work. I have been the person on the other end of that question long enough to know it matters. Here is what the engagement actually looks like.
The brief is not about ideas yet
I never start by asking what someone wants built. I ask what they are doing now, step by step, and I ask them to show me. Show me the spreadsheet. Show me the emails. Show me the form. Show me what a normal day looks like when that task is in it.
Then I ask for sample data. Real data, real names, real numbers, real edge cases. Not a tidy example. The edges are where the mistakes live.
This phase usually takes two or three conversations. It feels slow. That slowness is the point. It is cheaper to misunderstand now, in conversation, than to misunderstand later when I have built something wrong.
One small first version
A mistake I made early on was agreeing to build the full thing. The scope kept growing. The client kept adding requests in the middle of the build, and the launch kept slipping. Nothing was wrong with the requests. The problem was that nothing was in use yet, so every idea felt urgent and nobody could tell which ones mattered.
Now I agree one small first version before I build anything bigger. This is a real system. It works. It solves one part of the problem, not all of it. It goes live in weeks, not months.
Once people are using the first version, the list of new requests usually shrinks. Real use answers questions that meetings cannot. A request that seemed urgent often turns out not to matter. Someone else gets comfortable enough to ask for something nobody mentioned before. The second version gets built on something that actually happened, not on a guess.
What actually changes after go-live
A month in, the team stops doing the boring part. That time goes to customers instead. The repetitive work is gone. That sounds obvious until you see it happen, and then it is obvious why it matters.
They come back with the next process they want automated, because the first one proved it was possible. They start trusting the numbers. Reports arrive on time and look the same every day. Decisions get faster as a result.
Some people take longer to adjust than others and need a bit of retraining. That is normal. Planning for it is part of the job, not a sign that anything went wrong.
The ongoing part, and saying no
After go-live, I do not vanish. The system needs someone to notice when something breaks. Everything automated breaks eventually. An API changes, a login expires, data arrives in a shape nobody planned for.
The useful questions are: who notices, how fast, and what the fallback is while it is fixed? A system that fails loudly and falls back to a person is safe. A system that fails quietly is the dangerous one, because the business keeps trusting it after it has stopped working.
I build with that in mind, and I check on it monthly. I look at the logs. I talk to the people using it. I answer questions. I also push back on new requests until the first version is solid. This is the part where I say no. Not permanently. Just not yet. Real answers come later, when there is something real to talk about.
That is what the work looks like. Not the glossy version. The actual shape of it, week by week and month by month. A small business looking for this kind of help is asking whether someone will do the thinking first and the building second, whether they will ship something real fast instead of something perfect slowly, and whether they will stick around to make sure it works. If a consultant cannot answer those clearly, they have not built enough things that have run for long.
