AI & Automation

We Got Tired of Managing Around Bad Software.
So We Built Custom AI Software for Our Own Practice.

Every tool is great at some things and a liability at others. The friction compounds. Carrie and I made a different decision — stop adapting our process to fit the software, and build software that fits the process. Here is what we built, how we built it, and why we can do the same for your business.

By Jason Anderson·16 min read
Building custom AI software for small business — 406 Consulting Group's proprietary platform on AWS

Every piece of software we have ever used has been great at something. QuickBooks is great at bookkeeping. A CRM is great at contact management. A project management tool is great at tasks. And every single one of them has been bad at something else — sometimes several things — and the bad stuff creates friction that compounds every single day. Building custom AI software for our own Montana accounting and advisory practice was not the plan. It became the only answer that made sense.

For most of our careers, the answer was: find better software. Switch platforms. Add an integration. Hire someone to manage the tool. We watched clients do this. We did it ourselves. And at some point the pattern became impossible to ignore: the software was never going to fit the process, because the software was built for a generic business, and no business is generic.

So Carrie and I made a different decision. Stop adapting the process to fit the software. Build software that fits the process.

What started as a solution for our own practice has become something larger — a proof of concept that the same approach works for any business with a complex, high-friction process. We are building custom AI-powered software on enterprise-grade infrastructure, running our own firm on it, and beginning to offer the same capability to a select number of clients in other industries.

This article is not a product pitch. It is the story of why we built it and what we have learned — because if you have ever said "there has to be a better way" about a core process in your business, this story probably sounds familiar.

By Jason Anderson — Co-Founder, 406 Consulting Group. Background in large-scale operational finance at BP. Building software with Carrie Anderson, Co-Founder, because the alternative was managing around friction for the rest of our careers.

This is Article 1 in an ongoing series on AI and custom software for small business. Future articles will cover industry-specific builds — starting with general contractor invoicing.

1

The Software Friction Problem Nobody Talks About — And Why It's Costing You

Software companies sell you on the good stuff. The demo is always the features that work brilliantly. The sales call covers what the platform does well. Nobody demos the friction.

The friction shows up after you're committed — six weeks into implementation, when you realize the workflow you actually run doesn't map to how the software expects you to work. Or when you need two systems to talk to each other and the integration is either expensive, fragile, or both. Or when you're paying for a platform's full suite of features and using 30% of them, while the 70% you don't use clutters the interface and slows everyone down.

The software friction problem — why good software creates bad workflows for small businesses
01

The feature you need is three clicks too deep

Every platform optimizes for its own internal logic, not yours. The thing you do fifty times a day is buried. The thing you do twice a year is on the home screen. You adapt. You build muscle memory for the workaround. You stop noticing how much time it takes.

02

The integration that almost works

Zapier, native integrations, API connections — they work until they don't. A field name changes in one platform and the data stops flowing. You find out when a client asks why something fell through the cracks, not when the error happened.

03

The platform built for someone else's business

QuickBooks was built for a manufacturing company in 1983. Salesforce was built for enterprise sales teams. The templates, the defaults, the terminology — all of it reflects a business model that probably isn't yours. You spend the first year of any new platform unlearning its assumptions.

04

The total cost you didn't calculate

Software subscriptions are visible. The time cost of managing friction is invisible. How long does it take to manually move data between two systems that don't integrate? How many hours per week does your team spend on workarounds? Nobody puts that on the invoice, but it shows up on the P&L.

The breaking point is usually not dramatic

Most businesses don't decide to change because of one catastrophic failure. They decide because the accumulation of small frictions finally tips the scale. The workaround that used to take five minutes now takes twenty. The report that should be automatic is still manual. The platform you switched to eighteen months ago to solve Problem A has created Problems B, C, and D. At some point the cost of staying is higher than the cost of changing.

2

The Frustration That Finally Broke It

I have been intrigued by software my entire career. Not as a developer — as someone who runs processes and watches where they break. At BP, I worked with systems managing billions of dollars in fuel inventory and pipeline operations across thousands of miles of infrastructure. The processes were serious. And even at that scale, with enterprise budgets and dedicated IT teams, there were friction points that everyone just learned to live with because rebuilding them wasn't worth the disruption.

Running a CPA and advisory firm is a different scale but the same pattern. Client onboarding. Document collection. Workflow routing. Reporting. Marketing. Business development. Every function touched a different tool. Every tool had a learning curve, a subscription cost, a set of limitations, and a set of workarounds that became unofficial standard operating procedure.

Process first, software second — the philosophy behind building custom business software

Carrie and I would look at a process, see exactly what it should do, and then spend time figuring out how to make existing software approximate that. Not achieve it — approximate it. The gap between what we needed and what the software could do was always there. Sometimes it was small. Sometimes it was significant. It was always there.

The question that changed the direction

"What if we stopped trying to find software that fits our process, and built software that IS our process?"

Not a full replacement of everything at once. Modular. One process at a time. Build it exactly right for how we actually work, then connect the pieces. No feature bloat. No paying for functionality we don't use. No workarounds baked into the standard operating procedure.

The answer, it turned out, was that we could. Not because the technology suddenly became available — it has been available for years. Because we finally decided the friction cost was high enough to justify the build cost.

3

Process First, Software Second: The Right Way to Build Business Process Automation

The first thing we did was not write a line of code. The first thing we did was document exactly what needed to happen — step by step, handoff by handoff, decision by decision — for every process we were building. Not how existing software handled it. How it should actually work if the software were perfect. That document becomes the spec for the business process automation — not a vendor's template, not a platform's default workflow. Ours.

This sounds obvious. It is not how most software implementations go. Most implementations start with the software and work backwards to the process. You buy the platform, attend the onboarding sessions, and learn how the platform wants you to work. The process bends to fit the tool.

How most software implementations go

Buy the platform based on the demo
Attend onboarding and learn how the software works
Adapt your process to match the software's workflow
Build workarounds for the gaps
Train your team on the workarounds
Repeat when you switch to the next platform

How we approached the build

Document the ideal process before touching software
Identify every step, handoff, decision, and output
Define what low friction looks like at each stage
Build software around that process — not vice versa
Build modularly so each piece does one thing well
Connect the modules cleanly with no manual bridges

Modular architecture matters because it keeps friction contained. When one module has a problem, it doesn't corrupt the whole system. When a process changes, you update the relevant module without rebuilding everything around it. And because each module is purpose-built for a specific function, it is dramatically simpler than a platform trying to handle fifty use cases with one interface.

The low friction spec

Every module we build has one requirement above all others: it must be lower friction than the alternative. Not just lower friction than the software it replaces — lower friction than any reasonable way of handling the same task. If a feature adds complexity without adding more value than it costs in attention and time, it does not ship. This is a harder standard than it sounds. It means saying no to functionality that looks good in a demo but creates overhead in daily use.

4

The Platform: AWS and AI Agents

We built on Amazon Web Services — AWS. If you have not heard of AWS, here is the short version: it is the cloud infrastructure platform that powers Goldman Sachs, the CIA, NASA, Netflix, Airbnb, and a significant portion of the internet. When organizations that cannot afford infrastructure failure need a platform they can trust at scale, they choose AWS. It is not the cheapest option. It is the most capable and the most reliable.

AWS platform — who uses Amazon Web Services and why it's the infrastructure backbone for enterprise and custom business software

Building on AWS means our system has the same infrastructure backbone as organizations running operations at a scale most businesses will never approach. For an accounting and advisory firm in the Flathead Valley, Montana, that might sound like overkill. It is not. It means the system scales as we grow, handles sensitive financial data with enterprise-grade security, and does not go down when we need it.

AI Agents — What They Actually Do

An AI agent, in plain English, is software that can take in information, make decisions, and take action — without a human directing every step. Think of it as the difference between a calculator (you input, it outputs, you decide what to do next) and an employee who understands the workflow, knows what needs to happen when, and handles the routine parts without being told each time.

Orchestration

Routing tasks to the right place in the right order. When a client submits documents, an agent determines what type they are, where they need to go, what's missing, and what the next step is — without a human triaging the inbox.

Pattern recognition

Identifying anomalies, inconsistencies, or flags in data that a human reviewing quickly might miss. Not replacing the human judgment call — surfacing the information that needs judgment.

First-pass analysis

Doing the initial work on structured, repeatable tasks so the human sees a 90% complete output rather than a blank page. Drafting, categorizing, summarizing, extracting.

Running 24/7

The most underrated advantage. An AI agent processing incoming information at 2am on a Saturday costs nothing extra and misses nothing. A human doing the same work is either expensive or unavailable.

What AI agents do not do: replace the judgment calls that require context, relationship, and expertise. Carrie still reviews the tax strategy. I still have the client conversation. The agents handle the work that should not require us — so that we are available for the work that does.

5

The Marketing Command Center

One concrete example of what this looks like in practice: we built a marketing command center for our own firm. We are not a marketing agency. We do not have a marketing department. What we have is a module that manages our content pipeline, tracks performance, coordinates distribution, and surfaces what is working — with AI agents handling the orchestration.

Marketing command center — how 406 Consulting Group built a custom AI-powered marketing system without a marketing department

We have seen what dedicated marketing agencies use. We have seen the platforms purpose-built for content management, SEO tracking, distribution, and analytics. Our system, built as a process problem rather than a software problem, is more capable for our specific needs than what most marketing agencies have access to — because it was built around exactly what we need it to do, with nothing it doesn't.

What the marketing command center handles

Content pipeline visibility

Every article, at every stage, with no manual status updates required

SEO and GEO tracking

Performance data surfaced automatically — not pulled manually from multiple platforms

Distribution coordination

Content reaching the right channels at the right time without a human managing the calendar

Performance signals

What is working, what is not, and what to prioritize next — without a monthly agency report

AI agent orchestration

Routine tasks handled automatically so the focus stays on strategy and content quality

Single source of truth

One place for everything — no switching between platforms, no reconciling data from three dashboards

The marketing command center is one module. We have built others for client workflow, document management, reporting, and practice operations. Each one follows the same principle: document the ideal process, build software around it, no friction added for friction's sake. The whole platform runs on AWS with AI agents connecting the pieces.

6

Running Our Own Practice On It

We made a deliberate decision early: 406 Consulting Group runs on this system before we offer it to anyone else. Not a pilot version. Not a limited deployment. The actual platform, handling actual client work, surfacing actual problems we have to fix.

This is not a common approach. Most software is sold before it is stress-tested. Most vendors find out what breaks in production after the client is already depending on it. We find out what breaks on our own time, with our own operations, before a client's business is on the line.

Why this matters for you

We find the failure points first

Every module we have built has broken in ways we did not anticipate. We fixed it before a client ever saw the problem.

The process is proven, not theoretical

When we tell you a workflow runs without friction, it is because we run it every day. Not because it looked good in a demo.

We have skin in the game

Our business runs on this platform. If it fails, we feel it directly. That is a different level of accountability than a software vendor with ten thousand customers.

We know what to build for you

Having built it for ourselves, we understand where the hard problems are. We are not guessing at the design. We have lived it.

This is what it means when we say we are a proof of concept. Not a demo. Not a prototype. A live production system that handles real work for a real business, that we depend on every day, and that we have been refining based on actual use rather than anticipated use.

7

What Custom AI Software for Small Business Actually Looks Like

The same approach that works for a CPA firm works for any business with a complex, repeatable process that is currently generating friction. The problem does not have to be accounting. It does not have to be marketing. It has to be a process — something your business does regularly, that matters, that costs more time and error than it should.

Custom AI software for small businesses — what the build process looks like and which industries benefit most

A concrete example: General contractor invoicing

Consider a general contractor running $3–5 million in annual revenue. The invoicing process involves: receiving subcontractor invoices in multiple formats, reconciling them against job budgets, tracking retainage, marking up and billing to the client, managing the client payment cycle, and doing all of it while the job is still active and changing. This is not one process — it is four processes colliding in the middle, with a human manually bridging them.

Current state

  • Subcontractor invoices arrive in different formats
  • Manual reconciliation against job budget
  • Retainage tracked in a spreadsheet
  • Client billing assembled by hand
  • Cash flow driven by the slowest step

With AI agents

  • Invoices processed and categorized automatically
  • Reconciliation against job cost in real time
  • Retainage tracked and flagged automatically
  • Client billing assembled from verified data
  • Cash flow visible before the bottleneck hits

The result

  • Hours of manual work eliminated per project
  • Errors caught before they reach the client
  • Retainage never missed or miscalculated
  • Cash flow visible and manageable
  • Team focused on the job, not the paperwork

The GC example is one version of this problem. The same pattern — high-friction, multi-step process with manual bridges between stages — shows up in medical practices, trucking companies, property managers, professional service firms, retail operations, and manufacturing. The specific process is different. The opportunity is the same.

The questions worth asking about your own business

  • What process in your business creates the most friction for your team every week?
  • Where are humans manually moving data between systems that should talk to each other?
  • What repeatable tasks are eating time that could be spent on higher-value work?
  • Where do errors happen most often, and what is the manual step just before them?
  • What would your business look like if that process ran without friction?
8

Who Custom AI Software Is For — and Who It Is Not

Custom AI software is not the right answer for every business or every problem. We are selective about what we take on — we work with Montana businesses and clients across the region — because a poorly defined project produces poorly designed software, and that is worse than the friction you started with. Take our Financial Maturity Assessment first if you are not sure where your business stands operationally.

Who should consider custom AI software — criteria for businesses ready to build versus those who aren't

This is a fit if:

  • You have a clearly defined process that repeats frequently and generates consistent friction
  • The cost of the friction — in time, errors, or missed revenue — is significant and measurable
  • You have outgrown off-the-shelf tools or can see that you will
  • You can articulate what the process should do, even if you can't build it yourself
  • You are willing to invest in a proper build rather than the cheapest possible solution
  • You want something that works for your business, not a platform you adapt to

This is not a fit if:

  • The problem is vague — 'we need to be more efficient' without a specific process in mind
  • Off-the-shelf software you haven't tried yet would solve it at a fraction of the cost
  • The process itself is not defined — building software around an undefined workflow creates expensive chaos
  • You are looking for the cheapest possible solution rather than the right one
  • You need something deployed in two weeks — good builds take the time they take
  • The problem changes frequently enough that a stable build is not achievable

We are taking on a select number of projects

Carrie and I are not building a software company at scale. We are extending what we have built for ourselves to a limited number of businesses where the problem is clear, the fit is right, and we can actually make a significant difference. If you are reading this and a specific process came to mind, that is probably worth a conversation. If the decision also touches your entity structure or compensation — for owner-operators especially — our S-Corp Calculator is a useful first step.

Frequently Asked Questions: Custom AI Software for Small Business

Do I need to be technical to work with you on this?

No. The most important thing you need to bring is a clear understanding of your process — what it is, where it breaks, and what it should do. We handle the technical architecture, the build, and the AWS infrastructure. What we need from you is the business knowledge: the workflow, the edge cases, the places where the current process fails. You know your business better than we do. We know how to build software around it.

How is this different from hiring a software developer?

A software developer builds what you spec. If the spec is wrong, you get well-built software that solves the wrong problem. What we bring is the combination of software development capability and deep operational finance and business process expertise. We have run complex processes at scale — at BP and in our own practice. We can look at your process and identify the friction points before we write a line of code. The build is more expensive than hiring a freelance developer. The outcome is more likely to be right.

What does the process look like to get started?

It starts with a conversation about the specific process you want to address — not a sales call, a working session. We want to understand what the process is, where it breaks, what you have tried, and what the ideal outcome looks like. From there we assess whether a custom build is the right answer or whether something off the shelf would serve you better. If we move forward, we document the process in detail before touching any technology, define the build scope, and develop in phases so you see working functionality early rather than waiting for a complete system.

Is this only for accounting and finance processes?

No. The approach works for any complex, repeatable business process. We started with accounting and advisory because that is our expertise — but the methodology is industry-agnostic. We have thought through applications in construction, trucking, medical practices, and property management, among others. The question is always the same: is there a clearly defined process generating significant friction that a well-built custom module would solve? Industry is secondary to that answer.

What size business makes sense for this?

There is no perfect revenue threshold, but practically speaking: the friction has to be costing enough that the build investment is justified. For most businesses, that starts somewhere in the $1–2M revenue range and up — not because smaller businesses do not have friction, but because the ROI calculation on a custom build tends to work better at that scale. We will tell you honestly if we think your situation is not a fit for a custom solution.

How long does a build take?

Depends entirely on the complexity of the process. A well-defined, single-process module can be built and deployed in 6–10 weeks. A multi-module system handling several interconnected processes takes longer. The process documentation phase — which happens before any build — typically takes 2–4 weeks and is where most of the real design work happens. The builds that go wrong are almost always the ones that skipped or rushed the documentation phase. We do not rush it.

Custom AI Software

If a Specific Process Came to Mind While Reading This, That Is the Conversation to Have.

We are taking on a select number of projects for Montana businesses and clients across the region with clearly defined, high-friction processes that a custom AI-powered build would solve. Built on AWS. Process-first design. No off-the-shelf compromises. Let's talk about whether your situation is a fit. More in this series: the GC invoicing build is next.

The Build at a Glance

What we built and how

PlatformAmazon Web Services (AWS)
Who else uses AWSGoldman Sachs, CIA, NASA, Netflix
ArchitectureModular, process-first design
AI agents handleOrchestration, routing, first-pass analysis
Humans handleJudgment, strategy, client relationships
Built for406 Consulting Group — live in production
Available for clientsSelect number of projects
Typical project start2–4 week process documentation phase
Build timeline6–10 weeks for a single-process module
Best fitClearly defined, high-friction, repeatable processes

Is This a Fit?

Three questions to ask yourself

Do you have a process that repeats frequently and generates friction every time?

Yes → worth a conversation

Is the cost of that friction — time, errors, missed revenue — significant?

Yes → the ROI math likely works

Can you describe what the process should do, even if you can't build it?

Yes → we can work with that

Start the ConversationS-Corp CalculatorFinancial Maturity Assessment

About the Authors

Jason Anderson

Co-Founder, 406 Consulting Group

Large-scale operational finance at BP. Has spent a career watching where processes break and building better ones. Currently building the software that runs 406 Consulting Group on AWS.

Carrie Anderson

Co-Founder, 406 Consulting Group

Tax professional with deep expertise in tax strategy and advisory. Co-architect of the platform — bringing the process expertise that ensures what gets built actually reflects how the work is done.

Read the Full Story