What a blockchain pipeline really costs

A pipeline has four cost lines. Almost every internal comparison counts one of them.

• Build. Engineer time to get from nothing to a dataset you trust. This is the one everybody estimates, and the one everybody underestimates, because the estimate usually covers the happy path only.
• Run. Infrastructure, storage, and the quota you pay your data source every month whether or not anyone queries the result.
• Repair. The work that arrives after launch and never stops: chain reorganizations, schema changes, node upgrades, a contract that starts emitting a new event. This is the line that has no budget and no end date.
• Opportunity. What those same engineers would have shipped instead. It does not appear in any ledger, and it is usually the largest of the four.

Write the four lines down before you put numbers in any of them. A comparison that counts only the first line will always conclude that building is cheaper, because it is comparing a partial cost against a complete one.

"We will index it ourselves" is a sentence about a system, not a script. The system has parts, and each part is somebody's week.

• Extraction. A reader that pulls blocks without losing any, that survives the endpoint rate-limiting you, and that can be restarted without starting over.
• Decoding. Raw logs and instructions turned into the entities your product talks about. Every contract you add is a new decoder, and every proxy upgrade is a decoder that silently stops matching.
• State. Somewhere to keep what you have computed so far, versioned by block, so a reorganization can undo it.
• Backfill. A separate path for history, because the live reader is too slow to replay years of blocks and the historical reader is too wasteful to follow the head.
• Delivery. Writes into your database that are idempotent, because they will be retried.
• Operations. Monitoring that tells you the pipeline is behind before a customer does.

Count the parts you need. Multiply by what an engineer-month costs in your organization. That number is the floor, not the estimate.

Estimate in engineer-months, not in weeks, and estimate each part separately. An estimate given for the whole pipeline is a guess; an estimate given per part is a plan.

Three corrections that make a first estimate credible:

• Count the second chain. The first chain teaches you the shape of the problem. The second one tells you whether what you built is a pipeline or a one-off. If the roadmap has more than one chain on it, the honest build estimate is the first chain plus the refactor.
• Count the first reorganization. Not the handling of it, the discovery of it: the day someone notices the numbers moved and nobody knows why. Teams lose weeks there, once.
• Count the hiring. If the work requires a skill the team does not have, the clock starts at the job posting, not at the first commit.

Write the result as a range with the assumption attached. "Four to seven engineer-months, assuming one chain and no new hire" is a number a director can act on. "About a quarter" is not.

The run cost has a predictable half and an unpredictable half, and the unpredictable half is the one that ends budget conversations badly.

Predictable: compute for the pipeline, storage for the state and the output, and the database the result lands in. These scale with the data you keep and they are easy to forecast.

Unpredictable: what you pay your data source. Pricing in this market is not comparable across vendors, so a line-item comparison in a slide is usually wrong. Some vendors publish fixed tiers. Others bill by consumption unit, which means your monthly cost is a function of how your code happens to poll, not of how much data you actually need. A backfill, a retry storm or a loop that got deployed on a Friday all land on the same invoice.

The practical test: can you state today what a full re-sync of your largest chain would cost you? If the answer is no, the run cost is not estimated, it is hoped for.

This is the line that separates a project from a product, and the one that never appears in the original estimate.

• Reorganizations. The chain changes its mind about recent blocks. If your writes are not reversible, your database now holds a number that was true for ninety seconds and is wrong forever.
• Reconnection. Every stream drops. The question is whether it resumes at the right block or quietly skips a range. Finding out which, in production, is expensive.
• Contract changes. A proxy is upgraded, an event gains a field, a token starts using a different standard. Your decoder does not error. It returns nothing, and the dashboard shows a flat line that looks like a quiet week.
• Chain upgrades. Networks change their node software on their own schedule, not yours.

Budget repair as a standing percentage of one engineer, forever, not as a one-time hardening sprint. Teams that budget it as a sprint discover it as attrition.

The buy side of the comparison is not "a lower number". It is a shorter list of things that are yours to keep alive.

• You stop operating the extraction layer and the backfill path.
• You stop versioning your own state by block, and you stop writing the code that unwinds it on a reorganization.
• You stop maintaining the glue between the pipeline and your database.
• You keep the part that is actually your product: the modelling decisions, the business rules, and what you do with the result.

This is the honest framing of the trade. You are not buying a cheaper pipeline. You are buying a smaller surface of things that can break at two in the morning, and paying a predictable amount for it.

The comparison worth making is not price against price. It is price against the fully loaded cost of the four lines in chapter one, over the same period, with the same number of chains.

Fill this in with your own numbers. It takes an hour and it ends the argument, whichever way it ends.

Build, once

• Engineer-months per part, from chapter two, summed
• Plus the second-chain refactor, if more than one chain is planned
• Plus hiring time, if the skill is not in the team
• Times your fully loaded engineer-month cost

Run, monthly

• Compute and storage for the pipeline
• Database cost attributable to this data
• Data source cost, stated as a range between a quiet month and a re-sync month

Repair, monthly

• Percentage of one engineer, held permanently
• Times your fully loaded engineer-month cost

Opportunity, over the horizon

• What those engineer-months were otherwise going to ship
• Stated as the feature that gets postponed, not as a dollar figure

Then compare

Put the build cost over the same horizon as the run cost. A three-year horizon is fair; a one-year horizon flatters building, because the build is amortised against a single year while the repair line has not yet arrived.

If the two columns are close, the deciding factor is not cost. It is whether owning an indexing stack is something your team wants to be good at.