Bills Must Be Paid Guides

Bills Must Be Paid is easiest to understand as a chain of small decisions rather than a passive clicker. You smash piggy banks to earn money, watch your stamina, decide when a bill deserves attention, and spend the rest of a run turning a fragile start into a better next run. This hub organizes those decisions without inventing fixed prices, drop rates or a permanent tier list. The Steam build and the separate demo can change, so a number shown in a guide is only useful when its product scope and date are clear.

Start with the loop

The Getting Started guide explains the first session in a safe order: learn the hammer interaction, keep enough stamina to finish a useful run, collect the money that actually appears, and open each bill or perk screen before committing to a purchase. The How to Play guide goes deeper on target selection, movement, loot, the skill tree and the difference between a good-looking balance and a good decision.

Choose the right decision page

If a bill is due, open How to Pay Bills before chasing another upgrade. If you are losing runs because the collector takes too much, read Bankruptcy and the Collector. If your route feels weak, compare Skill Tree choices and the Hammer Comparison guide. If a piggy is moving, lazy or carrying unusual loot, use Piggy Types and Random Loot and Rare Coins.

What this wiki confirms

The [official Steam listing](https://store.steampowered.com/app/4421010/Bills_Must_Be_Paid/ “Bills Must Be Paid on Steam” rel=“nofollow ugc”) confirms stamina-driven smashing, bills, perks, a multi-path skill tree, different hammers, piggy types and random loot. The developer’s [Bills Must Be Paid page](https://rikegames.com/bills-must-be-paid “Rike Games product page” rel=“nofollow ugc”) adds player-facing terminology and a broader overview. The Updates hub separates launch information, demo notes and live-check questions from evergreen strategy.

Read dates and scope

The full game is AppID 4421010. The free demo has a separate AppID and can have different systems, limits and bugs. Every page in this source set says when it was checked and flags details that need confirmation in the current build. That is intentional: an honest route that survives a patch is more useful than a confident table built from an old demo screen.

A route that scales past the first run

Before every serious attempt, write down the bill you are protecting, the hammer you are carrying and the skill-tree problem you are solving. This keeps the economy, weapon and upgrade decisions connected. If the bill is urgent, a reliable target and a payment perk can be worth more than a rare-loot test. If the bill is safe, use the time to test a moving piggy or a different hammer. After the run, compare the result with the intended problem rather than with another player’s finish time.

The most durable guide explains a decision and its evidence. It does not claim that one path works for every platform, build or player. When a Steam Community post reports a fix, record whether it belongs to the demo or base game. When the developer page names a piggy, record the name but verify its current behavior. When a store description confirms a system, use it for the broad rule and leave exact costs to the current UI. That keeps the hub useful after a balance patch.

Quick verification checklist

Confirm the title and AppID, read the current bill state, inspect stamina, note the active hammer, and identify whether the next action is income, payment or long-term progression. If any fact is unclear, pause and use the relevant child guide. This prevents a demo screenshot, an old discussion or an inherited article from steering a Steam run.

That checklist is also the handoff standard for every translated route: preserve the AppID, product scope, source URLs and live-check labels.

How to keep a guide useful

Write the stable explanation first, then attach the changing detail. The stable explanation is that stamina limits smashing, bills create pressure, perks can change the next decision and hammers trade speed, damage, critical chance and radius. The changing detail is the current amount, unlock, timer, drop result or balance. When those layers are mixed, a patch can make the entire paragraph wrong. When they are separated, only the dated live-check note needs revision.

The source order is also deliberate. The Steam store page identifies the base product and broad systems. The developer page gives intended terminology. Steam Community posts date launch features and fixes. The current game UI answers exact questions. A fan observation can point to a missing page but should remain labeled until reproduced. This hierarchy lets translated pages preserve meaning without inventing local facts.

A player handoff after any article

End a session by linking the next decision, not by forcing a sale. A reader who learned the loop should go to bills or stamina. A reader who failed on a moving target should go to piggies or hammers. A reader who reset should go to prestige. The navigation is successful when the next page matches the player’s next question. The reader also needs one more word: continue.

Keep decisions in their proper scope

The guide hub is a map, not a substitute for the current game screen. Use it to select the next question, then verify a cost, timer, drop or unlock in the base-game build. If a discussion describes the demo, keep that observation on the Updates page and do not silently promote it into a general route.