The build sheet: what the word build actually includes

Build is a one-syllable word covering about fourteen separate commitments, most of which outlive the person who made them. This section itemises them, and then turns the list into a decision you can write down and defend.

The Build Sheet Desk 2 sheets Updated 13 August 2026

An estimate for building trading automation is usually an estimate for writing it. That is the smallest of the four cost lines and the only one with a natural end date. The rest of the sheet is ownership: things that must keep working, keep being upgraded, keep being watched and keep being paid for, from the day of the first live run until the day the system is switched off deliberately.

The two sheets here work in opposite directions. The first expands the word build into a responsibility matrix, so a comparison against a hosted alternative is a comparison of like with like. The second compresses the whole thing back down into a scored decision with the assumptions attached, which is the artefact you actually need when somebody asks in March why you chose what you chose.

Neither sheet contains a recommendation. They contain structure, and the inputs are yours. A team with an existing platform group, a spare host and a person who already carries a pager reaches a different answer from a two-person team running one campaign, and both answers are correct for the team that produced them.

02 What you take on when you build Ownership Building is not writing the thing, it is owning it. The responsibility matrix behind the word build: keys, endpoints, upgrades, alerts, records, and the person who answers when it stops at an inconvenient hour. 05 A decision sheet you can defend Framework A weighted decision sheet with inputs you supply, a written record of the assumptions behind the verdict, and the review trigger that tells you when the answer has quietly changed.

The ownership matrix in one view

Every component below exists whether you build or rent. The difference is only who is responsible when it stops, and that difference is the entire economic argument.

Components a running automation stack needs, the ownership work each one generates, and what happens to that work when the component is rented rather than built.
Component	Ownership work if you build	Cadence	What renting changes
Chain access	Choose a provider, watch rate limits, keep a fallback, react to plan changes	Continuous	Becomes a vendor problem you notice only as latency
Key handling	Generation, storage, rotation, access control, disaster recovery	Ongoing plus incidents	Reduced but never removed; you still own whatever you fund
Execution logic	Write, test, adjust as venues and interfaces change	Per venue change	Removed, at the cost of not controlling the behaviour
Hosting	Provision, patch, monitor, renew, migrate	Monthly plus upgrades	Removed entirely from your bill and your calendar
Observability	Logs, metrics, retention, dashboards, alert thresholds	Set up once, tuned forever	Reduced to whatever the console exposes to you
Alerting and on-call	Routing, escalation, someone awake and reachable	Continuous	Shifts to the operator, within their stated hours
Records	Run history, signatures, config versions, who changed what	Per run	Depends entirely on what the tool exports
Upgrades	Language runtime, libraries, client versions, breaking changes	Unscheduled	Removed, and this is the line most estimates omit

Read the third column before the fourth. Cadence is what turns a small task into a large cost: a two-hour job that recurs unpredictably every few weeks costs more attention over a year than a two-week job that happens once. That is why the comparison has to be made over a period rather than at a moment.