I run Echelon Advising LLC. We build and run AI infrastructure inside established companies, and the question I get before any other is what it costs. This is the whole answer, minus a number. The reason there is no number is the point.

Why is the price a policy and not a number?

A price on a website is a guess about your company made before anyone has looked at it. I do not know how many workflows you run, how many systems they touch, or how many approvals sit above the work. Until I do, any figure I publish is either padded to protect me or low enough to get the call. Neither one serves you, and both of them get renegotiated in month two.

So the policy is this. We map first. Then you get one set price for the whole build, in writing, before anything is built. It changes only if the scope changes, and only in writing. If we mis-scope, we absorb it. Ongoing operation is a separate monthly line, disclosed next to the build price so nothing appears later.

The mapping call is where this starts. You bring one process the company still runs by hand. We map it together on the call, and you leave knowing what we would build, roughly how long it takes, and what it would cost. That last part becomes exact once the operating map is done, which is the first two weeks of the sprint.

What are the five drivers of the price?

Every set price we write is built from the same five things. All five are visible in the operating map, which is why the map comes first and the price comes second.

  1. 01ScopeWhich parts of the business the system covers. One department that answers and books every lead is a smaller build than four modules running on one layer.
  2. 02Number of workflowsHow many distinct paths the work takes. Each workflow has its own inputs, exceptions, and acceptance criteria, and each one gets built and verified on its own.
  3. 03Systems and their directionHow many tools the system reads from and writes to, and whether each connection runs one way or both. A CRM we only read is a smaller job than one we write into with a readback.
  4. 04Approval complexityHow many approval gates the design needs, who sits at each one, and how exceptions escalate. More gates is not worse. It is more design, and it is where control lives.
  5. 05Work after launchWhat the system needs each month to keep running well: monitoring, retuning as tools and models change, the weekly report, and the next system built on the same layer.

Because the drivers are written down, the price does not move afterward unless one of them does. When you ask for a sixth workflow in week seven, that is a scope change, priced in writing before it is built. When a connection turns out to be harder than we mapped, that is our problem, not yours.

Why not bill hourly?

Hourly billing bills my uncertainty to you. If I am unsure how long a connection will take to verify, the hourly model makes that your cost. It also rewards the wrong thing: the slower I am, the more I earn. I have sat on the client side of that arrangement, and it produces a specific feeling around month three. You stop asking for changes because every question has a meter running on it.

A set price flips the incentive. Once the scope is in writing, the fastest path to a system running in production is also the best outcome for me, and any hour I waste is mine.

Why not an open retainer?

An open retainer rewards staying needed. If I am paid a flat amount each month for unspecified work, the quiet incentive is to keep the system a little dependent on me. Echelon does run systems month to month after launch, so this distinction matters, and I want to be precise about it.

The monthly operation line is not an open retainer. It is scoped to a system that is already built, with a written list of what it covers. You own the outcomes, the data, and the documentation. We run the system because a system nobody operates degrades: models change, tools deprecate, and people stop trusting it long before anyone notices. If you wanted to run it yourself, the documentation exists to let you.

What does the monthly operation line cover?

  • Monitoring every connection, so nothing unverified is ever presented as live.
  • The weekly report: what ran, what it handled alone, what waits on a decision, and who owns it.
  • Retuning when a tool changes its API, a model changes its behaviour, or your process changes.
  • The exception queue, reviewed with your named owner.
  • The next system, built on the same layer, scoped and priced in writing like the first.

It is disclosed with the build price, as a separate line, so the total is known before you sign anything. The pricing page lays out the same policy in full.

Where we start instead

Sometimes the mapping call shows that the answer is not a build yet. We do not turn that into a refusal. We turn it into the first step.

  • If your process still changes every week, we start by making it repeat.
  • If the bottleneck is getting customers, we start with the system that answers and follows up with every lead.
  • If nobody inside owns the work yet, we name the owner in the map.
  • If one small tool already solves it, we tell you, and build what sits between the tools.

What we cannot yet claim

Echelon Advising LLC was founded in February 2026. The number of installs priced this way under our own name is small, and I would rather say that than imply a decade of pricing data. The production numbers on this site come from systems this team shipped and runs, and every figure is from a system in production, not a projection.

What I can claim is the policy itself, because it is written into every agreement next to the guarantee: If at least one system we deploy does not measurably save time, reduce a cost, or support revenue, we keep working until it does. When the sample is large enough to say more, this article will be updated and the date at the top will say so.

If you want to see the policy applied to your own process, bring it to the mapping call. You leave with the design, the price, and the date it goes live.