Build or Buy a Volume Bot: How to Cost the Decision

Build or buy is decided by four cost lines, not by capability. Line one is the one-off engineering to reach a first useful run. Lines two, three and four recur every month: infrastructure, unscheduled maintenance, and the attention of whoever answers when it stops. Total both routes over the period you intend to run, and the smaller number is the answer.

Almost every argument about this decision fails because it compares line one against a subscription. That is comparing a one-off cost to a recurring one, which is arithmetic that cannot produce a verdict. The comparison only becomes meaningful once both routes are expressed as a total over the same period, with the same rate applied to the same hours.

The four lines

Write them in this order, because the order reflects how visible each one is. The first line is the one everybody estimates. The fourth line is the one nobody estimates and the one that most often decides the case. Between them sit two lines that get estimated once, at the beginning, and then never revised as the system grows.

The four cost lines of a build-versus-buy comparison, the unit each is naturally measured in, and how each behaves over time.
Line	Measured in	Behaviour over time	Visible in a normal estimate
1. Build to first useful run	Engineer-days, once	Fixed, paid up front, sunk on the day it lands	Yes, and usually the only line present
2. Recurring infrastructure	Currency per month	Grows in steps as components and volume are added	Rarely, and usually priced at idle
3. Unscheduled maintenance	Engineer-hours per month	Irregular, arrives with upgrades and provider changes	No
4. Attention and on-call	Hours, often at bad times	Constant floor, spikes during incidents	No, because nobody invoices themselves

The renting side of the comparison has a shorter sheet. It has a subscription or usage charge, a small integration cost, and a residual attention cost that never reaches zero because you still have to watch what the tool is doing. Whether that shorter sheet wins depends on the size of lines two, three and four on the other side.

Not a technology question

Teams that can obviously build the thing still lose money building it, and that is not a contradiction. The question is not whether the engineering is within reach. It is whether the ongoing ownership fits inside the capacity of the team for as long as the strategy is meant to run, at a cost lower than paying somebody whose entire business is carrying that ownership.

This reframing matters because capability is the wrong test. A competent engineer can write execution logic against a documented interface in a manageable amount of time; the Solana developer documentation is public and thorough, client libraries exist, and none of the individual steps are exotic. The difficulty was never the writing. It is that the written thing then needs an owner, indefinitely.

Comparing tools before comparing costs is the other common inversion. If you have not yet totalled your own build sheet, reading how a best Solana volume bot shortlist is normally assembled is a faster way to learn which capabilities the category treats as standard than deriving that list yourself from a blank page, and it tells you what your build would have to match to be worth building.

Line 1: build to a first useful run

Estimates go wrong here because the target is defined as a demo rather than as an operable system. A script that completed one swap is not a first useful run. It is a proof that the interface works, which is a genuine milestone and roughly a fifth of the job.

A useful run is one you could hand to somebody else. That means it logs what it did, refuses to exceed limits you configured, stops on a condition you can state, records the identifiers needed to reconstruct the run afterwards, and fails in a way that is legible at a glance. Each of those is small on its own and none of them appear in a demo.

Definition to estimate against

A first useful run is a run that produces: a written record of every action attempted and its outcome, an enforced ceiling on size and frequency, a stop that a second person could operate, and enough context in the log that the run can be explained a week later without the author present.

Estimate against that definition rather than against the demo, and the number typically moves by a multiple rather than a percentage. It is the same work either way; the difference is whether it appears in the estimate or in the following month.

Line 2: the recurring bill

The recurring bill is every charge that arrives in a month where nothing happened. Chain access, one or more hosts, storage for logs, whatever you use for metrics and alerts, secret storage, a staging copy, a domain, and the small subscriptions that accumulate at the edges of a project without anybody approving them individually.

Two properties make this line hard to estimate at the start. It is priced at idle, before real request volume exists, and it moves in steps rather than smoothly: a plan that comfortably absorbs a quiet week hits a limit during a busy one, and the response is a jump to the next tier rather than a small increase. The full itemisation lives in the monthly cost sheet.

The other thing that makes this line deceptive is that most of it feels free at the beginning. Free tiers, shared capacity and a host somebody already pays for all conceal the true marginal cost until the workload grows past the point where the concealment holds, at which point the bill arrives all at once and gets treated as a surprise rather than as a forecast that was never made.

Line 3: maintenance you cannot schedule

Maintenance is the line that separates a project from a system. Client libraries release breaking changes. A validator client publishes a version with new behaviour, and the operational notes in the Anza validator documentation exist precisely because that surface moves. Providers change limits. A venue adjusts an interface. None of these arrive on your calendar.

The cost is not the individual fix, which is usually small. It is the interruption pattern: unpredictable work that arrives at whatever moment it arrives, displaces whatever was planned, and requires the one person who understands the stack. Over a year, a handful of hours a month of unscheduled work costs more in disruption than the same hours would cost as a scheduled block.

Estimate this line as a monthly hour figure rather than as a per-incident cost, because you cannot forecast incidents but you can forecast a rate. Any figure you write down is better than the implicit zero, and after two or three months of actual tracking you will have a real number to replace it with.

Line 4: attention and the on-call tax

The fourth line is the one that decides most real cases and appears in almost no estimates. If the system trades unattended, somebody has to be reachable when it stops, and being reachable has a cost even in months when nothing goes wrong. That cost is paid in constrained evenings, delayed holidays and the low-grade attention tax of carrying a thing that might page you.

There is also a structural problem underneath the cost. A single-owner stack has a bus factor of one, which means the answer to "what happens if that person is unavailable" is "the system stops trading until they are available again". Fixing that requires a second person who understands it, and a second person is not a cheap line item.

The cost that is not money

Some of line four never converts into currency at all. It shows up as a strategy that runs at reduced size because nobody wants to watch it over a weekend, or as a campaign that gets paused during a holiday, or as a founder who is one interruption per week less effective at the thing they are actually supposed to be doing.

These are real costs and they are legitimately hard to price. The minimum honest treatment is to name them in the decision record even if the field next to them stays blank, because an unnamed cost is treated as zero by everyone who reads the sheet afterwards.

A total-cost model with your inputs

The model below is illustrative arithmetic. The numbers in it are placeholders chosen to demonstrate the shape of the calculation, not estimates of what anything costs, and every one of them should be replaced with a figure from your own situation before the total means anything at all.

Inputs, all supplied by you: D is your fully loaded engineer day rate, B is the number of build days to a first useful run as defined above, I is the monthly infrastructure total, M is maintenance hours per month, A is attention hours per month, H is your hourly rate, and P is the number of months you intend to run.

Build route total over the period is (D x B) + P x (I + H x (M + A)). Rent route total over the same period is P x S plus a one-off integration cost C, where S is the monthly subscription or usage charge and C covers the work of pointing your process at it. Residual attention applies to the rented route as well and belongs inside S if you want the comparison to be fair.

Worked example with placeholder inputs

Take D = 500 units, B = 20 days, I = 300 units per month, M = 6 hours, A = 4 hours, H = 60 units, and P = 12 months. These are placeholders, not observations.

Build cost is 500 x 20 = 10,000. Monthly recurring is 300 + 60 x (6 + 4) = 300 + 600 = 900. Over twelve months that is 10,800. Total build route over the period: 10,000 + 10,800 = 20,800.

Now suppose a hosted alternative charges S = 700 per month with C = 1,000 of integration work. Rent route total: 1,000 + 12 x 700 = 9,400. On these placeholder inputs the rented route is cheaper by 11,400 over the year, and the single largest contributor on the build side is not the build at all, it is the 7,200 of hours.

Change one input and the verdict changes. Set A and M to zero, which is what an estimate that ignores your own time effectively does, and the build route total falls to 13,600, narrowing the gap dramatically. That single substitution is the difference between most published build-versus-buy arguments and a defensible one.

The break-even period

The more useful output is not which route wins today, it is how long the build has to run before it wins. Break-even in months is the build cost divided by the monthly saving, where the monthly saving is the rented monthly charge minus the built monthly cost: (D x B - C) / (S - (I + H x (M + A))).

Using the placeholders above, the denominator is 700 - 900, which is negative. A negative denominator means there is no break-even: the built stack costs more per month to run than the rented one, so building never catches up no matter how long you wait. This is the single most useful thing the model tells you, and it is invisible in any comparison that stops at the build estimate.

When the denominator is positive, the result is a number of months, and the only question left is whether you will genuinely still be running this in that many months. Compare it honestly against the lifespan of the strategy rather than against the lifespan of your enthusiasm for it, and treat any break-even beyond the horizon you can actually forecast as a verdict against building.

Where building genuinely wins

There are real cases, and they share a shape: the ongoing cost is already being paid for something else, or the thing being bought cannot supply what is needed at any price. Both are specific conditions rather than general preferences, and if neither applies to you, the case for building is weaker than it feels.

The platform already exists. Hosts, logging, alerting and an on-call rotation are running for other reasons, so the marginal recurring cost is genuinely small rather than nominally small.
The behaviour is the strategy. If the specific sequencing, sizing or timing logic is the thing that produces the result, renting a tool that decides those for you removes the point of the exercise.
Disclosure is unacceptable. Some approaches cannot be described to a third party at all, which rules out any hosted option regardless of its cost or quality.
The horizon is long and stable. A system expected to run for years, with a team that will still exist, amortises a build cost over enough months for a positive break-even to be real.

Where renting genuinely wins

The renting case is equally specific. It wins when the period is short, the team is small, the requirement is common rather than bespoke, and nobody in the building wants to carry a pager for a component that is not the actual business. Campaign work fits this shape almost perfectly, because the horizon is measured in weeks and the build cost never gets amortised.

It also wins in a subtler situation: when you do not yet know what you need. Renting produces real numbers about your own consumption within a few weeks, and those numbers are exactly the inputs the build model above is missing. A Solana volume bot that is already running gives you an observed monthly figure to substitute for the guess in field S, and observed inputs beat estimated ones in every model.

Ten questions before you choose

Answer these in writing. The value is not in the answers individually; it is that a sheet with three blank fields is telling you the decision is not ready to be made yet.

How many months do you actually intend to run this, and what would end it early?
What is the fully loaded hourly rate you are applying to your own time?
Who is the second person who can operate it, and do they know that yet?
What is the recurring bill in a month with no activity at all?
Which components are genuinely shared with existing systems, and at what marginal cost?
What happens to the strategy if the stack is unavailable for a full day?
Which specific behaviour do you need that a hosted tool does not expose?
Is there anything about the approach that cannot be described to a vendor?
What is the break-even month, and is it inside your forecast horizon?
What event would make you revisit this decision, and who is watching for it?

Writing the verdict down

The output of this exercise is a short record, not a conversation. Name the two routes, list the inputs you used with the date you used them, state the period, give both totals, state the verdict, and state the trigger that would cause a review. Five sentences is enough, and the discipline is that the inputs are printed rather than remembered.

Records matter because assumptions expire quietly. The rate you assumed changes, the period shortens, the person carrying maintenance leaves, or the recurring bill drifts upward one small subscription at a time. None of those events announce themselves as a reason to revisit a decision, which is why the review trigger has to be written at the moment the decision is made rather than discovered later.

The scored decision sheet turns this into a repeatable format with weights and a record template. If you only take one thing from this page, take the shape of the model: four lines, three of which recur, totalled over a period you name in advance and evaluated at a rate you are willing to defend out loud.

Questions this sheet gets asked

Is building a trading bot cheaper than buying one?

Over a short period, almost never; over a long enough period, sometimes. Building front-loads a one-off engineering cost and then adds three recurring costs of its own, so the answer depends entirely on how many months you divide the build cost across and how many hours per month the stack asks for once it is live. Fix the period first and the arithmetic settles the rest.

What is the most commonly missed cost when building?

Unscheduled maintenance and on-call attention, in that order. Both are real, both recur, and neither generates an invoice, so they are invisible in a comparison that only counts money leaving a bank account. A build sheet that prices your own hours at zero will always conclude that building is cheaper, which is why it is not a comparison.

How long does it take to reach a first useful run?

The desk does not publish a figure, because it depends on the venues involved, the team, and how much of the surrounding platform already exists. What is more useful is the definition: a first useful run is not a script that completed once, it is a run with logging, limits, a stop switch and a record you could hand to someone else afterwards.

Does building give you an advantage worth paying for?

It can, and the advantage is specific rather than general: control over behaviour that a hosted tool does not expose, and privacy about a strategy that you would otherwise describe to a third party. If neither of those applies to what you are doing, you are paying a premium for control you will not use.

Can you start by renting and build later?

Yes, and it is usually the cheaper sequence. Renting first gives you a working baseline, real numbers for what your campaign actually consumes, and a period during which the build decision can be made from evidence rather than from an estimate. The reverse order, building first and renting after it disappoints, wastes the build.

How should the comparison treat existing infrastructure?

At the marginal cost of adding this workload, not at zero and not at the full bill. If you already run hosts, logging and alerting for something else, the new stack costs the increment plus the share of attention it consumes. Counting shared platform as free is the second most common way a build sheet flatters itself.

When should the decision be revisited?

On a date you set now, and on any of three triggers: the run period changes, the recurring bill moves by a material amount, or the person who carries the maintenance leaves. A verdict without a review trigger quietly becomes policy, and policies survive the assumptions that produced them.

Build or Buy a Volume Bot: The Decision, Costed