# What you now owe it
Course: Vibe Coding 101 — https://zero2vibecode.com/learn/vibe-coding-101
Canonical URL: https://zero2vibecode.com/learn/vibe-coding-101/4-3-what-you-now-owe-it
Shipping starts an obligation: updates, secrets, cost, backups, and the decision to shut it down cleanly when it stops being worth it.
The link works. Someone used it. That is the good part.
Here is the part nobody mentions in a vibe coding pitch: a shipped thing is an ongoing commitment. Small, but not zero, and it never quite reaches zero until you deliberately shut it down.
## Updates
Your code will sit still. Everything around it will not.
- **Dependencies get security fixes.** A problem is found in a package you use. Your code did not change — the world learned something about it. That is a patch you now need.
- **Platforms change.** Browsers, hosting services, and any API you call all move on their own schedule.
- **Certificates and integrations expire.** Some quietly.
For a static page with no dependencies, this is genuinely almost nothing. That is one more argument for keeping version one small.
For anything with packages, a practical rhythm: check for security updates when you are notified, and once every few months even when you are not. You can hand this to the agent:
```text
Check the dependencies in this project for known security problems.
List anything that needs updating and what would break if we did.
```
## Secrets
If your project has keys, they are now a thing you own.
- **Never in the code.** Environment variables, always.
- **Rotate them** — replace them with new ones — on a schedule, and immediately if one might have been exposed. Exposed includes: pasted into a chat, committed once and removed, sent in a screenshot, or in a repository that used to be public.
- **One key per purpose** where you can. Then a single compromise does not hand over everything.
- **Set spending limits** on any paid key. Most providers offer them. A key with no limit is an unbounded liability if it leaks.
A key that was public for five minutes is compromised. Automated scanners watch public repositories for exactly this, continuously. Rotate it and move on — do not spend the evening deciding whether anyone noticed.
## Cost
Three habits, all cheap, all before you need them:
- **Set a spending cap** on anything with a bill: hosting, AI providers, storage. Set it now, not after a surprise.
- **Turn on billing alerts.** Learning about your costs from a bank statement is the expensive version.
- **Know your per-user cost.** If each visitor triggers a paid call, then popularity is a bill. That is fine — as long as you knew before it happened.
The horror stories are not people getting hacked. They are a loop with no limit, or a free tier that silently became a paid one, running unnoticed for a month.
## Backups
If your project holds anything a person would be upset to lose, you need a copy somewhere else.
Readlist stores links in the visitor's own browser, which is a quiet design decision with a real consequence: clearing browser data wipes it. That is acceptable for a personal link list. It is not acceptable for anything someone spent an hour typing.
The escape hatch that costs almost nothing: an export button. One click, everything in a file the user keeps.
```text
Add an Export button that downloads all saved links as a JSON file,
and an Import button that reads one back in.
```
That is fifteen minutes of work and it converts "my data is gone" into "I have a copy".
## Writing it down
Six months from now you will not remember how any of this works. Neither will the agent — a new session starts with nothing.
Keep the project notes file current, and make sure it answers three questions:
```text
How to run it: ...
Where the secrets live (names, not values): ...
What breaks first, and what to check when it does: ...
```
That is the whole handover document. It is enough for a future you, and enough for another person.
## Knowing when to stop
Not every project deserves indefinite maintenance. Most do not.
A project you no longer use, that still runs, still holds keys and still costs money, is a small ongoing liability with no upside. Retiring it is a task, not the absence of one:
- Tell anyone who uses it, with a date.
- Export the data and give people a way to take theirs.
- Revoke every key it used.
- Cancel the services.
- Take it down and remove the DNS record.
Done properly, that takes twenty minutes and ends cleanly. Done by letting a card expire, it ends with a broken link someone still has and a database somewhere you no longer control.
Shutting a project down cleanly is a sign of judgement, not failure. The alternative — a graveyard of half-running services with live keys — is the thing that actually looks bad.
## Try it yourself
One shipped project, one leaked key, and the decision nobody makes on purpose.
## Where you are now
You can do the whole loop: pick something finishable, describe it, steer it, read what came back, catch the expensive mistakes, ship it, and look after it.
That is the skill. It does not depend on which agent you use, and it will not expire when the tools change.
What is left is depth: the terminal that most agents live in, and the specific tools themselves.