What You Take On When You Build a Trading Bot Yourself

Building your own automation means taking ownership of eight things that never finish: chain access, key handling, hosts, observability, records, upgrades, alerting and the person who answers. Writing the execution logic is a project with an end date. The other eight are commitments with a monthly cost, and they are what a build sheet has to price.

This page is deliberately not about how to design the software. It is about what arrives with it. If you are comparing an in-house stack against a hosted one, this list is the difference between the two columns, and every item on it needs an hours figure before the comparison means anything.

What build actually means

The word compresses two very different activities. There is construction, which is bounded, estimable and satisfying, and there is custody, which is unbounded, hard to estimate and mostly invisible. Estimates cover construction. Budgets get destroyed by custody.

The distinction shows up clearly in how the work arrives. Construction arrives when you schedule it. Custody arrives when a provider changes a limit, a library publishes a breaking change, a host needs patching or a run stops at an inconvenient hour. You cannot plan the arrival, only the response, and the response has to come from someone who understands the system.

The responsibility matrix

Before pricing anything, write down who is responsible for each component in each state: running normally, degraded, and stopped. The exercise takes twenty minutes and it reliably surfaces at least one component whose owner is nobody, which is the most expensive kind of owner.

Components of a self-hosted automation stack, the work each generates once live, how often that work arrives, and the failure that follows if the component is left unowned.
Component	Ongoing work	Arrival pattern	If unowned
Chain access	Capacity, fallbacks, plan and limit changes	Irregular, provider-driven	Silent throttling that looks like a strategy problem
Key handling	Generation, storage, access, rotation, recovery	Scheduled plus incidents	An irreversible loss with no support desk
Hosts	Provisioning, patching, restarts, renewals	Monthly and on advisories	An unpatched machine holding signing material
Observability	Log retention, metrics, alert thresholds	Set up once, tuned continually	Outages discovered by looking at a balance
Records	Run history, config versions, change log	Every run	No way to explain what happened last week
Upgrades	Runtime, libraries, clients, breaking changes	Unscheduled	A stack that becomes unupgradeable, then unfixable
Alerting	Routing, escalation, silencing, testing the path	Continuous	Alerts that fire into a channel nobody reads
On-call	Being reachable and able to intervene	Constant floor, spiky	Overnight failures that run until morning

Chain access

Every action the stack takes goes through an endpoint, which makes endpoint capacity a first-class operational concern rather than a configuration detail. The failure mode is not a clean outage; it is throttling, partial responses and timeouts under exactly the conditions where you most want the system to work, which is when activity is high.

Owning this means keeping a fallback configured and tested, knowing what your request pattern actually is rather than what you assumed it would be, and noticing when a provider changes limits or restructures plans. It also means being able to distinguish a slow endpoint from a slow strategy, which requires instrumentation you have to build.

The alternative of running your own node is a much larger commitment than it appears from the outside. The operational surface is documented publicly in the Anza operator documentation, and reading the requirements is the fastest way to decide whether that is a line you want on your build sheet at all.

Keys and the money they move

Key handling is the component where the cost of getting it wrong is unbounded and irreversible. A signature that lands cannot be recalled, there is no chargeback and there is no support queue, so the ownership question is not whether the design is clever but whether the process around it survives an ordinary bad day.

The ongoing work is unglamorous: deciding where signing material lives, controlling who and what can reach it, rotating it on a schedule you actually keep, and having a recovery path that has been tested rather than assumed. Every one of those is a recurring obligation rather than a setup task, and each one gets harder as more people join the project.

The one rule that never changes

No legitimate process asks you to paste a seed phrase or a private key into a website, a chat, a support ticket or a form. Anything that does is asking for permanent control of the funds. This holds whether you build or rent, and it is the single operational rule that survives every architectural decision on either side of the comparison.

Hosts and the things running on them

Something has to run continuously, and whatever it is becomes yours to patch, restart, renew and eventually migrate. A single small machine looks like a rounding error on the bill and is not a rounding error on the calendar, because it needs the same attention as a large one: updates, certificate renewals, disk that fills with logs, and a reboot that has to happen at some point.

The subtle cost is that hosts accumulate. A process, then a scheduler, then somewhere to keep state, then a staging copy so changes can be tested without touching the live one. Each addition is individually justified and collectively becomes an estate, and an estate needs someone whose job includes looking after it.

Knowing what it did

An automation you cannot observe is one you can only evaluate by looking at a balance, which is the slowest and most expensive detector available. Observability is the difference between knowing within minutes that something stopped and finding out the following morning when the numbers do not add up.

The ownership work is mostly tuning rather than building. Alert thresholds that are too tight train everyone to ignore alerts; thresholds that are too loose miss the thing they were installed for. Both states are reached gradually, and correcting them is a recurring task that never appears in an estimate because nobody thinks of it as work.

There is also a decision about retention. Logs are cheap until they are not, and the point at which they stop being cheap arrives at exactly the moment they become useful, because a busy period generates the most data and the most questions. Choosing a retention window is a cost decision disguised as a technical one.

Records that survive the week

Records are distinct from logs. A log is what the process printed; a record is what you can hand to another person to explain what the system did, when, with what configuration, and why. The difference matters the first time somebody asks a question about a run from three weeks ago.

At minimum, a record contains the identifier of every action attempted and its outcome, the configuration in force at the time, the version that produced the behaviour, and any deliberate stop with its reason. Public transaction identifiers make part of this easy, since anyone can verify a landed transaction independently, but the configuration and version context only exists if you deliberately keep it.

The upgrade treadmill

Dependencies move whether or not you do. Client libraries publish breaking changes, language runtimes reach end of support, and the software your endpoint provider runs changes underneath you. The public repositories make the pace visible: the release cadence of a project like the Agave validator client is not a secret, and it is a useful proxy for how often the surface you depend on shifts.

Staying current is unpleasant work that produces no visible benefit, which is why it gets deferred. Deferral compounds: a stack two versions behind is a routine upgrade, a stack two years behind is a project, and a stack that can no longer be upgraded at all is a rewrite you did not schedule. This is the mechanism by which technical debt turns into a build decision made a second time.

Price this line as a fixed monthly allocation rather than as a per-upgrade cost. Teams that book a recurring slot for dependency work spend less over a year than teams that batch it, because the batch always lands at the least convenient moment and always takes longer than the sum of its parts.

Somebody has to answer

If the system can act while nobody is watching, somebody has to be able to stop it while nobody is watching. That is the whole of the on-call requirement, and it applies at any size. A two-person team with a campaign running overnight has an on-call rotation; it just has not written it down or given it a name.

The cost of on-call in a month with no incidents is not zero. It is the constraint on being unreachable, the phone that stays on, and the low-grade attention tax of carrying something that might interrupt you. In months with incidents, add the response time itself plus the recovery time afterwards, which is usually longer than the incident.

This is the component that most cleanly transfers when you rent instead. A hosted automated Solana volume bot moves endpoint capacity, retries and overnight operation onto somebody whose working hours are defined in advance, which does not eliminate your attention cost but does change it from an obligation into a check.

A monthly hours model

The following arithmetic is illustrative. The hour figures are placeholders chosen to show the shape of the calculation rather than measurements of anything, and you should replace each one with your own tracked number before using the total.

Illustrative monthly ownership hours

Chain access and capacity: 1 hour. Key and access hygiene: 1 hour. Host patching and renewals: 2 hours. Observability tuning: 1 hour. Dependency upgrades: 3 hours. Incident response and write-up: 2 hours. Records and change log: 1 hour. Total: 11 hours per month.

At an hourly rate of H = 60 units, that is 660 units per month, or 7,920 units over a year, before a single line of infrastructure billing is counted. Substitute your own hours and your own rate; the point of the model is the total, not the placeholders.

Two things usually surprise people about this total. The first is that it exceeds the infrastructure bill in most small stacks, which means the invoice you can see is the minority of the cost. The second is that the largest single line is upgrades, which is the line nobody estimates because it produces nothing visible when it goes well.

Before the first live run

These have to exist before the system signs anything with real funds. Not because a checklist is virtuous, but because each item on it is cheap to build in advance and expensive to build during an incident.

A stop that a second person can operate without reading code.
An enforced ceiling on size and frequency that the software refuses to exceed.
A written record of every action attempted, its outcome and its identifier.
An alert that fires to a place a human will actually see within minutes.
A tested path back from the loss of the primary endpoint.
A funded wallet whose balance you have already decided you can afford to lose.
A named person who answers, and a named person who answers when the first is away.
A one-page runbook covering start, stop, and what to check first.

The second operator

A stack with one person who understands it is a stack that stops when that person is unavailable, and unavailability is not an exotic event. It happens on holidays, during illness, and permanently when somebody leaves. The cost of the second operator is real and it is the line most often deleted from a build sheet to make the total look reasonable.

Making a second operator possible requires artefacts that only exist if written: a runbook, a documented configuration, credentials that are reachable without one specific laptop, and at least one rehearsal where the second person does the work while the first watches. Two hours a quarter of deliberate handover is the cheapest insurance on the entire sheet.

Switching it off deliberately

The last thing you take on is the end. Systems built for a campaign outlive the campaign, quietly consuming infrastructure and attention long after the reason for them expired. Deliberate decommissioning means moving funds out, revoking access, cancelling the services, exporting the records you may still need, and writing down that the thing is off.

Nobody schedules this and it is a genuine cost, usually a day of unglamorous work. Put it on the sheet as a line item at the start, because a system that gets abandoned rather than decommissioned keeps its bill, keeps its keys live and keeps its unpatched host on the internet, which is a worse outcome than either building or renting.

Questions this sheet gets asked

How much maintenance does a trading bot need?

It is better measured as hours per month than as a total, because the work is recurring rather than finite. The realistic components are dependency upgrades, provider changes, log and alert tuning, and incident response. Track your own figure for two or three months and use that, because a borrowed number describes somebody else stack and not yours.

What is the biggest ownership risk in a self-built stack?

A bus factor of one. If a single person understands the configuration, the deployment and the failure modes, then holidays, illness and resignations all become trading outages. The fix is expensive, which is why it is usually deferred until the first time it causes a problem.

Do you need on-call for automation that only runs a campaign?

You need somebody reachable for as long as the automation can act without supervision. If it can open positions or spend fees while nobody is watching, then somebody has to be able to stop it, and that reachability is on-call whether or not you use the word.

How do you know when maintenance is out of control?

Two signals. Unscheduled work displaces planned work more than occasionally, and changes start being avoided because nobody is confident about what they will break. The second is worse, because a system nobody wants to touch is a system that stops receiving the upgrades that keep it working.

Is running your own endpoint infrastructure worth it?

Only if you have measured that a shared provider genuinely cannot serve your request pattern, and only if you have somewhere to put the operational work that running infrastructure creates. Otherwise it converts a vendor line item into a much larger internal ownership line, which is the opposite of what the build sheet needs.

What records should a self-built stack keep?

Enough to reconstruct any run without the author present: every action attempted with its outcome and identifier, the configuration that was in force, the version that produced it, and the reason for any deliberate stop. Records that live only in a terminal buffer are not records, because the buffer is gone before you need it.

Does using open-source libraries reduce the burden?

It reduces the writing and increases the following. Libraries move, deprecate interfaces and occasionally change behaviour in a minor release, so adopting one means adopting the obligation to track it. That is a good trade in most cases, but it is a trade rather than a saving.

What You Take On When You Build It Yourself