In this solo presentation, Isaac from Apps Over Code explains why many automation initiatives in service firms—especially accounting practices—miss their ROI targets and outlines a three‑pillar framework for "strategic automation" that ensures projects are both effective and sustainable. The first pillar, Consulting, stresses aligning automation ideas with business outcomes, mapping high‑level processes (instead of isolated tasks), prioritizing initiatives for maximum impact, and documenting workflows to capture tacit knowledge. The second pillar, Design & Architecture, advocates minimizing future maintenance by selecting the simplest appropriate technology (SaaS, no‑code platforms like Zapier) and avoiding custom code unless absolutely necessary, thereby reducing human effort required to build and sustain solutions. The third pillar, Support, focuses on post‑implementation activities: continuous error monitoring, rapid issue resolution, thorough documentation, and proactive training to drive team adoption. Isaac illustrates each pillar with concrete examples (e.g., an accounting firm presenting a list of tasks rather than processes) and warns of common failure patterns such as "random acts of automation," over‑engineering, and neglecting user adoption. He concludes by teasing a follow‑up video on a five‑level workflow systemization framework, urging viewers to apply the three pillars within a structured workflow to achieve lasting efficiency gains.
Chapters
Hey, this is Isaac from Apps Over Code. And in this video, let's talk about the foundation of doing automation right and why your last project probably failed to deliver a return on your investment. I'll be talking about just 3 core pillars, 3 simple but incredibly crucial 3 pillars that's going to ensure that you actually build the right thing the right way in a way that people actually use it. If you miss any of the 3 pillars, you'll have to like just waste your time, waste your money on random acts of automation rather than really defining or refining a business systems that scale and drive margin. With that, let's get into it. So 3 pillars of strategic automation, as we have here, the first that I'll be talking about, which is consulting. Now, fancy term that you've probably heard. This doesn't necessarily sound groundbreaking, but let me walk you through why this is actually important and what it actually means. From our perspective, the job of a consulting period before we jump straight into automation, it's aligning those initiatives with business outcomes. Usually in the form of efficiency gains and margin improvements. Because more often than not, what both clients want to do and other agencies, you know, follow and do with them is just jump straight into it. I have this idea, this idea, this idea. Cool. Let's build and let's start just doing random acts of automation, as I like to call them, that may not lead to an outcome further down the road. Now, what does this actually look like in tangible, actionable terms? First is listing your high-level processes, not your tasks. Literally yesterday, I was talking with an accounting firm that wanted to work with us, and they just shared with me a list of just individual tasks that they wanted to automate that were not really cohesive. And that if we were to just say, cool, let's do exactly what you have on that list in that order, we wouldn't really drive an outcome at all. So I always like to tell clients to think about first the higher-level processes that they're business is composed of, and then we can kind of like attack one of those processes one at a time. Of course, part of consulting is also prioritizing work, meaning of all of those processes, which ones will give us the most bang for our buck? And also something that I've noticed, and it's actually even a common term in automation circles, is like, we'll automate your low-value work, which again, I think that there's value in that. I also want to Look at, see if we can automate your actual work and your high-value work and the core pieces of the things you do to drive value for your clients and for your business. The other one is really also getting clarity on your processes. If you don't have any documentation, I'd suggest, you know, you have something in place. And it's often where we come with a client, if they don't have any documentation, we do some process clarity sessions to map that out and get a better understanding of what is actually getting done. 'Cause sometimes there's just a lot of knowledge in people's heads. Now, what does it look like when consulting is missing? Okay, as I kind of alluded to earlier, you're going to build the wrong thing the right way. You have a lot of activity and the random acts of automation with little results, and you'll end up with a lot of deliverables that might on their own deliver value, but there's not really a cohesive plan that's leading you towards a business outcome that ultimately would justify the investment. So that is consulting. The second pillar I have for you is, can you guess it? Design, design and architecture, really. And what this is about is minimizing the humans required to build and maintain your systems. The whole point of a system and on automation and all of these things that we do, it's to enable you to gain leverage on the things your people do. If now we're adding something that also requires additional work to maintain, It's kind of like it defeats the purpose, right? And I like that definition of minimizing human resources required to build and maintain. Actually, I stole that definition from a book called Clean Architecture. It's really in the context of what software architecture is meant to be for, but I do think that there's a lot of similarities between software architecture and systems design or systems architecture within a services firm environment. Now, what does this actually look like in practice? In the context of a firm, this is betting and optimizing your tech stack, because that's, it's really the tools your team use to do the processes that we talked about in the consulting pillar. And it's also being very mindful of not only what is this going to cost to build, but what is this going to cost to maintain in the future? That's why we are big fans of choosing the simplest tool for the job, which often means we are potentially using SaaS or software applications that already exist in the market and helping our clients leverage those to the best of our ability. When those are not enough, we're using and leveraging visual development tools or no-code development platforms, things like Zapier, which is the one that people more easily know of, but tools like it, such that in the event that something doesn't work, in the event that something needs fixed and we're no longer there, at least a business user, not technical user, can understand and get around it. And potentially even fix it if we've done it in a way that's as simple as possible. And I have here code as a last resort. Definitely code, it's really becoming a commodity and it's much easier to write in the age of AI. But even if we could build it more quickly, again, it's going to be harder to maintain. I go back to the definition. It might be easier for us or quicker for us to build it using code in certain instances if there's a particular system that needs to be created or a process that needs to be automated. But we know from experience that it will be more challenging to maintain, especially if this is— if we're no longer there and the client's left on their own to do that. So what does this look like when you have— maybe you have the consulting piece, but you don't have the design pillar in place? What this looks like is your vendors over-engineering solutions, right? Creating code and this fancy thing for things that you could have done with much simpler tools. Again, if things break, You need them. And this is really where the return on your investment starts to erode as more and more maintenance is needed. So maybe once they built the thing, you were like, oh, this is a good deal for what I paid. I'm getting these efficiency gains or whatever. It makes sense. It makes financial sense. But as they need more and more maintenance and you incur additional and additional costs in maintaining the solution, you just start to question like, was this really worth it, right? So this is really about making sure you are not building the right thing the wrong way, right? We consult to make sure you're working on the right thing, and we design and architect the solution in a way that will make it effectively require as little maintenance as possible, which would be effectively the equivalent of building the right thing the right way. Now, if you build the right thing the right way, is that it? Not really, because if you build it, they will come. That's a saying in the kind of like product world of like, if you build a product, will people just come in to buy it? But in the systems world, I like to think about If we build it, will they use it? Probably not on their own, or it's something we have to be proactive and intentional about. So the 3rd pillar is really about support. And what does this actually mean? It's ensuring the adoption and well-functioning of the systems that have been put in place. Pretty self-explanatory, but let's look at what does that actually look like in terms of what actions are taken to ensure that that's the case. From a technical standpoint, monitoring errors to make sure we catch them as quickly as possible before they lead to to, you know, additional work. Because if something is not working, we find out 6 months from now, maybe there's a lot of things that were not automated in the way they should have that then we need to fix. So monitoring errors is a big piece of it, making sure that you are aware of the things, the systems are running the way they're supposed to, and being available to quickly fix or iterate on any improvement that maybe the, for example, the firm or the team member that's working and using the systems identifies. It's also about driving team adoption because one of the things that could happen Then it's okay, we have the thing and we don't even have data to see if there's any errors because no one's using it. So making sure we're driving team adoption for the systems we've built and also documenting those new systems so people are aware or can have a reference to consult if they have questions and doubts on how the system actually works. So again, what does it look like when it is missing? A lot of half-built bridges, things that you built once and that you never took the time to just do the few iterations that We're going to perfect it. As I mentioned earlier, the team having no idea how things work and sometimes even knowing, not knowing how to use it. And sometimes honestly, even not knowing that it exists because you build this beautiful thing and maybe there are people not even aware that there's this tool that's going to automate the things that they're currently doing manually. So again, if we don't have this pillar in place, we might build the right thing because we consulted and did all of the action items we talked about in that phase. We build it the right way because we had the foresight to design it in a way that's going to reduce maintenance and reduce human labor to maintain the systems in the first place. But we also have to make sure that people actually use it and that those systems are working correctly. And that's what the support component, it's all about. Again, usually in the form of monitoring, in the form of documentation, and in the form of training with the team to make sure they know how to use things and we're driving that adoption. Now, knowing this is not really enough because you have to apply these pillars inside a structured workflow, which is what this next video where I break down 5 levels of workflow systemization will help you do. So click that to watch that next. I'll see you on the next one. And until then, stay efficient.
