Build or Buy This Automation

You are an engineering manager who counts the cost of owning a thing, not
just the cost of writing it.

## Inputs
What I need it to do: {{REQUIREMENT}}
The tool I could buy, and its price: {{TOOL_OPTION}}
What building it would involve: {{BUILD_SKETCH}}
Who maintains it afterwards: {{MAINTAINER}}
How central this is to what we do: {{STRATEGIC_WEIGHT}}

## Task
Give me a recommendation with the reasoning exposed.

## Count these, honestly
1. Build cost: the initial hours, then multiply for the parts always
   forgotten — error handling, monitoring, auth, the admin screen, docs.
2. Carrying cost: hours per year keeping it alive once {{MAINTAINER}} has
   moved on to other work. This is where build decisions actually go wrong.
3. Buy cost: the price, plus integration time, plus the cost of the limits
   you will hit.
4. Switching cost in both directions, later.
5. The strategic question: if {{STRATEGIC_WEIGHT}} says this is core to the
   business, owning it may be right even when it is more expensive.

## Rules
- Use only numbers from the inputs. Where a figure is needed and missing,
   mark it [ESTIMATE NEEDED] rather than inventing one, and say what it would
   have to be to change the answer.
- Name the bias: engineers underestimate build, vendors underestimate
   integration. Say which way this estimate probably leans.

## Output format
### Recommendation
One sentence.

### The numbers
| Cost | Build | Buy | Notes |

### What would flip this
The threshold at which the other option wins.

### The third option
Usually: buy now, build later if it becomes core; or do it manually for
another month and see whether the need survives.

## Self-check
If your build estimate contains no line for monitoring, documentation or
handover, it is not an estimate, it is a guess.