What if the hardest part of your bot isn’t the model, the prompt, or the API, but a postal worker in a sorting facility you will never meet?
In 2011, Apple shipped an app called Cards. You picked a design on your iPhone, typed a message, and Apple printed it on letterpress stock and mailed it for you. Two years later, in 2013, Apple killed it. The stated reasons were logistical and economic. Not a design failure. Not a bad interface. The atoms simply refused to cooperate with the bits at the margin Apple needed.
Fifteen years on, the story is circulating again as a curious footnote, usually framed as trivia. I read it as an architecture postmortem, and one that lands uncomfortably close to home for anyone building automated systems that reach past the screen.
Every bot has a Cards problem
The pattern is familiar if you have shipped anything that touches the real world. Your pipeline is clean. Input arrives, gets validated, gets transformed, gets handed off. The demo is lovely. Then you attach the final step, the one where something physical or human-operated has to happen, and your elegant graph acquires a dependency you cannot version, cannot test in CI, and cannot retry cheaply.
Cards connected a phone screen to restored printing presses, physical mail routing, and a custom stamp. Apple could control the app perfectly. It could not control the cost per unit of a low-volume physical good moving through infrastructure it did not own. The software was the easy half.
Substitute your own version:
- A support bot that drafts perfect replies but depends on a ticketing system with a rate limit nobody documented.
- An agent that orders supplies and quietly depends on one vendor’s fragile checkout flow.
- A print-on-demand or fulfillment integration where your per-order margin is thinner than your error rate.
- Anything with a human in the loop whose throughput is a fixed constant you do not get to scale.
In each case the failure is not in the logic you wrote. It is at the boundary where your system stops being software.
Unit economics are an architecture constraint
The lesson I keep relearning: cost per action belongs in your design doc next to latency and error handling. We are fluent at reasoning about tokens, cold starts, and cache hit rates. We are much worse at reasoning about the cost of the twelfth step in a workflow when that step involves a person, a machine, or a shipment.
If a bot action costs you three dollars to execute and users perform it seasonally in short bursts, you do not have a product. You have a subsidy with a nice interface. Apple, with more manufacturing use than almost any company alive, looked at that math and walked. It is a reasonable assumption that your two-person side project will not beat it.
Practical version of this for bot builders: before you wire up the integration, write down the marginal cost of one successful run and one failed run. Then estimate how many retries a bad day produces. If the failure cost exceeds the success value, no amount of prompt tuning saves you.
The same name, a different system
There is a second act worth sitting with. Apple Card, the credit product introduced in 2019, has evolved a lot since launch and remains an active part of Apple’s lineup. Same brand family, near-identical name, wildly different substrate. One moved paper through the mail. The other moves ledger entries.
Digital-native transactions scale on infrastructure that was already built to handle volume. A card transaction does not need a press restored, a stamp designed, or an envelope physically carried. The cost per additional transaction approaches something you can actually plan around.
That contrast is the most useful thing in this whole origin story. When you are choosing what your bot should automate, favor the work whose marginal cost trends toward zero and whose failures are cheap to undo. Reserve the physical-world integrations for cases where the value per action is high enough to absorb real overhead, and be honest about whether yours is.
Ship the ledger, not the letterpress
None of this argues against ambition. Cards was, by most accounts, a lovely piece of work, and the polish carried through to the object that landed in someone’s mailbox. Building things that cross from software into the physical world is one of the more satisfying uses of an automated system, and sometimes the right call is to build it anyway and learn what breaks.
Just go in knowing which half of the system will actually decide the outcome. For Cards, the app was never the problem. Design your bots with the same suspicion: the code you control is rarely where the project dies.
🕒 Published: