When to Spend a Token (And When to Save It)

The Decision Framework

Knowing that tokens are limited is only half the model. The harder question is: when is it worth spending one?

A token is worth spending when all three of these conditions are true:

1. The problem is core to your business. This is the thing your customers pay you for. If you are a video streaming company, video encoding is core. If you are a bank, transaction processing is core. Everything else is plumbing.

2. Boring alternatives are genuinely inadequate. Not "slightly slower" or "less elegant" — genuinely unable to meet the requirement. PostgreSQL handles an astonishing range of workloads. Before spending a token on a specialized database, prove that PostgreSQL cannot do the job with proper indexing and query optimization.

3. You can absorb the operational cost. You have (or can hire) people who understand the technology deeply enough to operate it in production, debug it under pressure, and upgrade it safely. If the answer is "we'll figure it out," you cannot afford this token.

Here is a decision tree:

Is this problem core to our competitive advantage?
  ├── No → Use boring tech. Full stop.
  └── Yes →
      Can boring tech solve it adequately (with effort)?
        ├── Yes → Use boring tech. Optimize it.
        └── No →
            Can we hire/train people to operate the exciting alternative?
              ├── No → Reconsider the requirement, or use a managed service.
              └── Yes → Spend the token. Document WHY you spent it.

The "Managed Service" Escape Hatch

Before spending a token on exciting self-managed technology, always ask: "Does a managed service exist that gives us the capability without the operational burden?"

A managed service converts an exciting technology into something closer to boring. Amazon RDS for PostgreSQL is boring — AWS manages backups, patches, failover, and monitoring. A self-managed PostgreSQL cluster on bare metal is more exciting — you own all of that. Similarly, Amazon MSK (Managed Streaming for Kafka) is significantly less token-expensive than self-managed Kafka, because AWS absorbs the operational complexity of broker management, replication, and upgrades.

The managed service escape hatch does not eliminate the token cost entirely — you still need to understand the technology's data model, query patterns, and failure modes. But it dramatically reduces the operational component of the cost, often turning a one-token choice into a half-token choice.

Real-World Token Spending Examples

Good token spend: Airbnb investing heavily in a custom search and pricing infrastructure. Search and dynamic pricing is their product differentiator. Using a generic search solution would have limited their ability to innovate on the thing customers care about most.

Bad token spend: A 10-person startup using a self-managed Kubernetes cluster to deploy a monolithic Rails application that handles 500 requests per minute. Heroku, Railway, or a simple EC2 instance with a deploy script would have been zero tokens. Instead, they spent months building and debugging their deployment infrastructure — time they did not spend building features.

Ambiguous token spend (the hardest case): A mid-size company adopting Rust for a performance-critical microservice when the rest of the stack is Python. If the service genuinely needs the performance characteristics Rust provides (memory safety without garbage collection pauses, predictable latency), this might be worth a token. If the team chose Rust because "it's cool" and the service could have been written in Go (which the team already knows), this is a wasted token.