Increasingly, business leaders are asking: Do we need AI for our business? We’ve found that the answer can vary. In fact, our Director of Engineering has a philosophy he comes back to constantly: identify the right tool for the right job. It sounds simple, but you’d be surprised how often this part is overlooked. In practice, it’s the thing that separates a good technical partner from a vendor who just wants to start a build.
This philosophy helps us match the solution to the problem the business is trying to solve, rather than chase the latest AI innovation. Sometimes the answer is an integration. Sometimes it’s modernizing what’s already there. Sometimes it’s a POC to test an assumption before anyone commits to a bigger budget. Sometimes the answer is the latest AI innovation. But it’s critical to assess where AI fits, and where it doesn’t first.
We use agile software development practices. Agile development means delivering working software every sprint. That goes beyond a methodology preference. It’s how good software gets built. You’re not architecting a massive monolith upfront and hoping you got everything right. You’re building, learning, and adjusting as you go.
That matters because clients change their minds, and lately AI solutions change frequently as well. What a client thought they needed in month one isn’t always what they realize they need in month four, and the ways to solve the original problem may have evolved, too. Real usage surfaces things that a requirements document never will. We’ve taken plenty of projects through an initial phase and then into additional phases as the picture got clearer. It’s a way to make room for what would be considered scope creep in other situations, and it helps us meet the demands of our customers as needs – and solutions like AI – take shape.
A lot of companies come to us with existing systems, something that’s been patched and extended past its original design, or a platform that mostly works but has gaps a new build could fill. The question we ask isn’t “should we rebuild this?“, but instead “what does this situation actually call for?”.
A ground-up build is one option, but many times it’s not the first one we reach for if a better answer is to modernize what exists or to add capabilities like AI features, a new module, or better reporting.
Off-the-shelf SaaS
If the problem is common, SaaS probably has it covered. Project management, CRM, accounting, HR all have good tools that exist to handle these functions. The trade-off is adapting your process to fit the tool instead of the other way around. Sometimes that trade-off makes the most sense. Other times, that adaptation is a deal-breaker – and that’s where we come in.
Workflow automation and integrations
A lot of what looks like a software gap is a workflow gap. The tools exist, but they don’t talk to each other. Someone is being the connection layer manually, copying data between systems, reconciling reports, chasing approvals over email. Fix the workflow, connect the systems, automate the handoffs. In a lot of cases, that’s the whole answer, and often we can include AI integrations into this type of solution.
Quick builds and AI-assisted tools
For low-stakes internal tools, a fast build is often the right call. Speed matters more than longevity for some things. The question we ask: would you be comfortable if this broke and nobody could fix it without rewriting it from scratch? If yes, build it fast. If no, it needs more engineering behind it.
When none of the above fit. When the process is genuinely unique. When the workarounds built around off-the-shelf tools cost more in time, errors, and people than a real build would. When you’re building something that’s a competitive advantage. That’s where a full custom build earns its place.
The same thinking applies to AI, and right now, that thinking is getting skipped constantly.
Here’s a real example of the kind of decision we work through with clients. A company wants better visibility into their data. The instinct is to build a giant BI system, but what they actually need might be a smaller, well-structured data layer with AI-generated visuals on top, something that surfaces the right information without the overhead of a full enterprise build. Or it might be the full BI system. It depends on the data, the users, the decisions that need to get made, and what breaks if something goes wrong.
That’s the conversation. AI is one option in the bucket, a genuinely useful option in the right situation. FOMO aside, “we should add AI” is not an answer to a business problem. It’s the start of a set of questions: What problem are we solving? Is AI the right tool? What data would it need to access? What happens when it gets something wrong? What compliance and security factors should we consider? Who owns the outcomes?
We’ll get into those questions specifically in the next post. But even if the first question is “does your business need AI?”, the next one should always be: what does the problem call for?
We’ve had this conversation with companies across healthcare, manufacturing, ag, logistics, and professional services. Regardless of what type of build or integration we land on, we always have a clearer picture of the right tool for the job, whether that’s an integration, a phased approach, or the modernization of something that already exists. The more thoughtful and intentional we can be upfront, the better results you’ll get in the end.
And that goes double for anything related to AI. There are needs and problems that are easily and quickly solved with a vibe-coded solution or agentic workflow. Others require more strategic thought and a combination of solutions that include AI integrations and features.
Need help figuring it out? We’re happy to talk through your use case.