Why My Best Client Calls Run Long

Andy O'Neil

19 Feb 2026 — 6 min read

The Partnerships of Co-Building

Last week I finished a client call and we just kept talking. For over an hour. About family, about work, about my family’s dog. My task list sat there judging me the entire time. I didn't care a bit.

His name is William. He was referred to me by my friend Carl, a former client who retired recently. Carl's handoff was five words: "You could not be in safer hands."

Not a transition document. Not a spec sheet. Seven words.

I've been thinking about why that handoff even worked. Why William trusted it. Why Carl trusted me enough to make it. And the answer has almost nothing to do with how good my automations are.

The Accidental Intimacy of Custom Apps

Here's something nobody tells you about building custom Knack apps and Make.com automations for someone: you end up understanding their business better than almost anyone outside their company.

That's not a flex. It's just what the work requires.

When you build a custom Knack app for a client, you have to understand every field in every record, every relationship between tables, every workflow that connects the data to an actual human decision. You can't fake that understanding. The app won't work if you get it wrong. The data has to flow the way the work actually flows, which means you have to know how the work actually flows before you write a single line of configuration.

Same with Make.com scenarios. Every trigger, every condition, every branch, every "but sometimes we do it differently on Thursdays" exception. You're not just mapping a process. You're mapping the reality of how someone's team operates when nobody's watching the process documentation.

That level of detail forces a kind of intimacy with someone's business that most professional relationships never reach. You're not getting the polished boardroom version. You're getting the real version. The version with workarounds and sticky notes and "we've been meaning to fix that for two years."

Not Everyone Slows Down for This

I should be honest: not every client co-builds with me.

Some are too busy. Running too fast. They need the thing built and they need it yesterday, and sitting on a Zoom call watching me configure automation modules isn't how they want to spend their Tuesday afternoon. I get it. I build for those clients too, and the work is still good.

But the clients who are willing to slow down and do the work together? They get something extra.

They learn what's actually being built for them. Not the summary version, not the "here's what it does" walkthrough after the fact. They watch it come together in real time, ask questions while it's still wet, and understand why the system works the way it does. Which means when something breaks six months later (and something always breaks six months later), they have a fighting chance of understanding what went wrong instead of calling me in a panic.

And here's the part I didn't expect when I started working this way: they learn a lot about me, and I learn a lot about them.

Co-building sessions are short bursts of intense work on a project. There's no fluff. No status updates that could've been an email. Just two people looking at the same screen, solving the next problem. And honestly? There's no one better to project manage me than the business owner sitting across a Zoom call telling me the next issue we need to address. They know their business. They know what hurts. They know what's next. My job is to understand the process deeply enough to build the right thing, and their job is to point me at the right problem. It works because both people are actually doing something valuable.

That rhythm, week after week, builds something you can't manufacture with a kickoff meeting and a Gantt chart.

What Carl Built With William

Carl co-built with his clients. That's how he worked. He sat with business owners, walked through their processes, built custom Knack apps and automations alongside the people who'd actually use them. He asked the hard questions about how work really moved through their operations, not how the org chart said it should.

William was one of those clients. They'd worked together for years. Carl understood William's business at the macro level (how everything connected) and the micro level (what happened at each individual step). That dual understanding is rare. Most consultants operate at the macro level and hand you a report. Most technicians operate at the micro level and configure tools without understanding why the process works the way it does.

Co-building lives at both levels at the same time. And when you do that with someone long enough, you stop being a vendor and start being something closer to a partner.

So when Carl retired, the handoff wasn't a cold introduction. Carl knew how I work because we'd spent time in co-building sessions together. He'd watched me think out loud, back up when I was wrong, dig into process details until the system actually matched the reality. You can't hide behind a slide deck in a co-building session. The screen is shared. The thinking is out loud. The client sees everything.

Carl knew what William needed. He knew how I worked. Seven words was enough.

The Process Work That Actually Frees People

Here's the part that connects all of this to something bigger than the tools.

When you understand someone's workflow at the micro-task level, you start to see where their team is spending time on things that drain them. Data entry that could be automated. Handoffs that require three emails when they should require zero. Approval bottlenecks where one person has to touch everything because nobody documented the criteria for "good enough."

The automations we build aren't about efficiency for its own sake. They're about giving people back the hours they need to do work that actually requires a human brain.

A Knack app that captures client intake properly means the assistant stops re-entering data and starts spending that time on actual client communication. A Make.com scenario that routes work based on clear criteria means the owner stops being the bottleneck and the team stops waiting around for permission to move.

Those are small changes. But they compound. The team member who used to feel like a data entry machine starts feeling like a valued part of the operation. The owner who was drowning in approvals starts trusting the process enough to step back. The business that ran through one person's head starts running through systems that anyone can follow.

That's the work. Not just building apps and automations. Building processes that free people up to do their best work without being blocked by invisible bottlenecks or trapped in tasks that don't need a human brain.

The Thing That Transfers

William and I are still early in our co-building partnership. He's sharp, asks great questions, and fully understands how he needs me to help him streamline his processes. (That's exactly what I love about a client. Clarity to know what you want and when.)

The Knack apps will get rebuilt eventually. The Make.com scenarios will get deprecated. That's how this industry works. But the process understanding that comes from sitting inside someone's real business, the trust that forms when you do the work together instead of just talking about it, the relationships that grow in those short intense sessions where both people are actually solving problems?

That stuff doesn't deprecate.

Carl knew that. William knows it. And every time a client call runs an hour longer than it's supposed to because we're just talking, I'm reminded that the best work I do has almost nothing to do with the technology.