What It Actually Takes to Fix It

I’m ready…

By the time most IECs get to this point, something has already shifted.

They've stopped describing the problem in general terms. They know specifically what's happening, when it happens, and what it costs. They've identified where it originates, not just where it shows up. And they're ready to do something about it.

That readiness is exactly where the next assumption takes over.

"I just need to build something that solves this."

It's a reasonable instinct. If the problem came from something that was never defined, the natural response is to create what's missing. And sometimes that's exactly right.

But in my experience working with IECs across every practice model and caseload size, the build decision is where things go sideways more often than anywhere else. Not because IECs aren't capable of building good systems. Because the real cost of building something that actually holds up is almost always underestimated.

This article is part of the 12-part Business Architecture for IEC Practices series. Sections 9 and 10 focused on defining a problem specifically and diagnosing its origin. This section addresses what comes next: evaluating whether to build a solution yourself or adopt an existing one, and what that decision actually costs in either case.

Download the Section 11 PDF
This includes the build vs. adopt framework and guided prompts to evaluate one specific solution you're currently considering.

Download the IEC Business Tool Evaluation Guide Part 3: Decide
Part 3 of 3: A standalone decision framework you can use right now to evaluate any tool, system, or operational change you're facing in your practice.

What Building Actually Involves

There is a version of building that most advisors picture when they decide to create something new in their practice.

It looks like this: identify the gap, design a solution, implement it, move forward.

That sequence is accurate. It's just incomplete.

What it leaves out is everything that happens after the build. The testing. The refining. The moment three months in, when a situation arises that the system wasn't designed to handle and a judgment call is made. The gradual drift that happens when maintenance falls behind. The realization, the following season, that something needs to be updated again.

Building something that works once is not the same as building something that runs consistently across students, across seasons, across the situations that don't go exactly as planned. And that distinction matters enormously when you're already running a full caseload.

The Cost Nobody Talks About

When an IEC decides to build something, the conversation usually focuses on what it will take to create it. The time to design it. The effort to put it together. The satisfaction of having something that's entirely your own.
What rarely gets factored in is the ongoing cost of ownership.

Every system you build is a system you are now responsible for maintaining. Every process you create is a process you have to update when something changes. Every template you design is a template that will eventually need to be revised, refined, and adapted as your practice evolves.

That's not an argument against building. It's an argument for being honest about what building actually commits you to before you start.

I spent years building and rebuilding pieces of my own process before I finally asked the question that changed how I approached it:
Is what I'm about to build something that already exists somewhere? And if it does, what is the actual ROI of building it myself versus adopting something already tested?

For most IECs, when that question is answered honestly, the math rarely favors building from scratch.

What Adoption Actually Means

Adopting something that already exists isn't a shortcut. It's a different kind of decision with a different kind of cost.

Instead of designing, you're learning. Instead of building, you're implementing. Instead of maintaining from scratch, you're working within something that has already been refined through real use in real practices.

The tradeoff is ownership and control. When you build, everything is yours. When you adopt, you're working within someone else's design, which means it may not fit your practice perfectly out of the box and will require adaptation.

But here is what adoption gives you that building almost never does on the first attempt: a starting point that already works. Something that has been tested across different practice models, different caseload sizes, and different student populations. Something where the design decisions have already been made and refined so you don't have to make them yourself under pressure during application season.

The question isn't whether building or adopting is better in the abstract. The question is which one actually addresses the problem you've defined and diagnosed, at the level where it originates, within the capacity you actually have right now.

How to Evaluate the Decision

This is where most IECs get stuck, not because they don't know what they need, but because they don't have a structured way to evaluate whether what they're considering actually fits.

The IEC Business Tool Evaluation Guide was designed specifically for this moment. It walks you through the decision in five sections: defining the business problem clearly, diagnosing where the constraint exists, evaluating the structural fit and real ROI, assessing system fit, and making the decision with a concrete next step.

It works for any operational decision you're facing, whether that's a new platform, a workflow change, a curriculum adoption, or a process you're considering building yourself. And it works whether you've been following this series from the beginning or you're picking it up here for the first time.

Work through it with one specific decision you're currently facing. Not a general evaluation of everything that needs to change. One decision. By the end, you'll know whether you're looking at something to build, something to adopt, or something that isn't ready to be solved yet because the problem hasn't been defined clearly enough.

Where This Leads

Once the build vs. adopt question has been worked through honestly, something becomes clear that wasn't visible before.

The decision in front of you isn't just about fixing one problem. It's about how you want your practice to operate going forward, and what you're willing to put in place so it actually runs that way.

That's what Section 12 addresses.
And it's where this series, all twelve sections of it, comes together into a single decision that shapes everything that follows.