The AI Learning Hub Journal

The Services You Secretly Depend On

One page on the outside — a stack of other people’s services underneatheach service brings its own bill, its own limits and its own way of failing — and your product inherits all threeTHE STACK YOU ARE STANDING ONyour booking page — the only part with your name on itHOSTINGserves the pagesTHE FILING SYSTEMholds the bookingsEMAILsends the confirmationsPAYMENT — LATER, MAYBEtakes the moneythis is how nearly all modern software is made —including by large teams; it is not a flaw in yoursWRITE THE LIST — ON PAPER, NOT IN YOUR HEADTHE SERVICEITS JOB FOR YOUWHERE ITS BILL LIVESITS BAD DAY, TO YOUemailconfirmations arrivea monthly card chargenothing arrives at all…one row for every service in the stackprofessionals do not depend on fewer services —they can name what they stand onspending caps on every service in the stackVibecoding’s final module in one sentence: set themthe last column is the plan: what does your productlook like on the day that service is down?EMAIL — WHERE ‘WORKING’ AND ‘ARRIVING’ QUIETLY PART COMPANYthe app sends theconfirmation flawlesslyit lands in spam —or nowhere at allthe customer assumesthe booking failedbooks again · phones ·goes elsewherethe diary says one thing, the customer’s memory another — and the customer’s version has no nuance: ‘your app lost my booking’arriving is a feature you buy and test, not one you assume: a proper email service, a sending address that matches your product,and a habit of sending yourself test bookings — then checking the spam folder the way a stranger wouldFAIL LOUDLY AND HONESTLY‘bookings are having trouble — please phone’the business keeps running, the customer stays informedFAIL SILENTLYa form that accepts bookings that go nowhere —someone else’s hour of trouble becomes wrong data of your ownWHEN A SERVICE YOU STAND ON HAS A BAD DAY, YOUR PRODUCT HAS A BAD DAYthat cannot be avoided, only prepared for — the written list, the caps, and a plan that fails loudly
From the outside, one page with your name on it — underneath, other people’s services, each with its own bad days.

The Stack You Are Standing On

From the outside, your product looks like one thing: a page with your name on it. From the inside, it is a stack of other people's services. Something hosts the pages. Something holds the filing system. Something sends the email. Later, something may take the payment. Each one has its own bill, its own limits, and its own way of failing — and your product inherits all three. This is not a flaw in how you built it; it is how nearly all modern software is made, including software built by large teams. The difference between amateurs and professionals is not that professionals depend on fewer services. It is that professionals can name what they stand on. So write the list: every service, what it does for you, where its bill lives, and what your product would look like on the day that service is down.

  • One page on the outside; hosting, the filing system and email underneath
  • Each service brings its own bill, its own limits and its own way of failing
  • Professionals do not depend on fewer services — they can name what they stand on
  • Write the list: each service, its job, its bill, and what its bad day does to you

Email That Actually Arrives

Email deserves its own slide, because it is the service where 'working' and 'arriving' quietly part company. Your app can send a confirmation flawlessly — the code ran, the platform accepted it — and the message can still land in spam, or nowhere at all. Now watch what that does in the real world. The customer never sees the confirmation, assumes the booking failed, and books again — or phones, or goes elsewhere. The groomer's diary says one thing, the customer's memory says another, and Saturday gets interesting. From the customer's point of view there is no nuance: your app lost my booking. Email that actually arrives is a product feature, and it is bought, not assumed — a proper email service, a sending address that matches your product, and a habit of sending yourself test bookings and checking the spam folder the way a stranger would.

  • Sent flawlessly and landed in spam can both be true at once
  • A missed confirmation becomes a double booking or a lost customer in real life
  • The customer's version has no nuance: your app lost my booking
  • Arriving is a feature you buy and test, not one you assume

When a Service Has a Bad Day

When a service you depend on has a bad day, your product has a bad day. That sentence cannot be avoided, only prepared for, and the preparation is three small things. First, know which services you stand on — the list from earlier in this lesson, on paper, not in your memory. Second, know where each bill lives and what its limits are; spending caps were Vibecoding's final module, and one sentence is all that lesson needs here: set them on every service in the stack. Third, decide what your product does while a service is down. Given the choice, fail loudly and honestly: a page that says 'bookings are having trouble — please phone' keeps the business running and the customer informed. Failing silently — a form that accepts a booking that goes nowhere — turns someone else's one-hour outage into wrong data of your own, and you know by now which is worse.

  • Their bad day is your bad day — the only question is how prepared you are
  • Keep the list of what you stand on written down, not in your head
  • Caps on every service — Vibecoding's final module already taught this; set them
  • Fail loudly and honestly — a silent failure manufactures wrong data of your own

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.