The reason so much online content right now feels like a coping mechanism is that the old arrangement, work hard and an average salary buys an average life, stopped holding. The gap shows up in the housing numbers most clearly: in England the median home cost 7.9 times median disposable household income in the financial year ending 2024, and over a longer window the divergence is starker still, with house prices in Wales roughly quadrupling between 1999 and 2024 while household incomes roughly tripled (ONS, Housing purchase affordability, Great Britain: 2024).
If your income is going up and your life is not getting easier, that is arithmetic, not a personal failing. The useful response is not a new worldview. It is a new playbook, tested rather than believed.
A Claude Project is a container that holds files and instructions so every chat inside it already knows your context. You do not have to re-explain yourself, and the playbook can build on itself over weeks. Projects work on the free plan, capped at five of them, so you do not need to pay for any of this (Anthropic's Projects article).
income.md. List every source of money coming in, the amount, and whether it is reliable, seasonal or one-off. Include the boring ones. Add it to the project.costs.md with your fixed monthly costs, your variable ones, and one line at the bottom: the number you need to cover each month to be fine. That last number is the one every experiment gets measured against.skills.md. Not a resume. Write what you can actually do, including things you were never paid for: the software you know deeply, the thing colleagues ask you for help with, the hobby you are unreasonably good at, the industry whose jargon you speak.skills.md, write how many hours a week you genuinely have, how much money you can lose without it hurting, and anything off the table (no client calls, no public posting, no weekends). Constraints make the output usable instead of fantasy.You are helping me build and run an income playbook. My income, costs, skills and constraints are in the project files. Read them before answering anything, and never invent a number that is not in there.
Rules for everything you produce in this project. Always work from what I can actually do this month, inside the hours and budget I listed, not from an idealised version of me. When you suggest something that depends on market rates, demand or pricing, give me the source you are basing it on and tell me plainly how confident you are. If you do not know, say you do not know rather than producing a plausible figure.
Never tell me what I will earn. Frame everything as a test with a cost, a time box and a result I can check. When I report back with real results, update the playbook to match the evidence, including deleting your own earlier suggestions if the evidence says they were wrong.The mistake here is asking Claude for side hustle ideas. You get a listicle everyone else already has. What you want is the intersection of what you can do and what someone is visibly paying for right now, with the evidence attached so you can check it yourself.
Read my skills file and my constraints. For each skill I listed, find where that skill already has visible paid demand right now, and show me the evidence rather than asserting it.
For every match, give me: who is paying for it (the specific type of buyer, not "businesses"), where I can see that demand with my own eyes (a job board, a freelance marketplace, a specific community, a competitor selling it), the rough price range that work goes for and where you got that range, and how crowded the space looks. Rank the matches by how quickly I could plausibly get a first paying result given my hours and budget, not by how big the market is.
Then be blunt with me: which of my skills have no real market on their own, and which two of them are worth more combined than separately. Where you are guessing about rates or demand, label it a guess.An idea you can research forever is not a plan. An experiment has a cost, a deadline, one number that decides it, and a rule for when you stop. Three at once, because one test tells you almost nothing and five will not get finished.
From the demand matches above, design exactly three income experiments I can run in the next thirty days inside my stated hours and budget. Make them genuinely different from each other, so one is the obvious low-effort test, one is the higher-effort higher-ceiling test, and one is a cheap long shot.
For each experiment give me: the one sentence version of what I am testing, the smallest possible first version I could put in front of a real person this week, the total hours it needs and the money it costs, the single number that counts as the result (a reply, a call booked, a sale, a paid deposit), the specific threshold that means keep going, and the specific threshold that means stop. Include a kill rule with a date attached, so it ends on its own rather than quietly dragging on.
Then tell me which one to start first and why, in terms of what I would learn fastest, not what would earn most.This is the step people skip, and it is the one that makes the whole thing work. Without a tracker you remember experiments by how they felt. With one, every test produces a verdict you can act on.
Build me a tracker for these three experiments as a single table I can keep updating, and output it as a downloadable file I can open in a spreadsheet.
Columns: experiment name, week number, hours I actually spent, money I actually spent, the outcome number for that week, running total of the outcome number, one line on what I learned, and a status of running, paused, killed or scaled. Pre-fill one row per experiment per week for four weeks so I only have to fill in what happened.
Underneath the table, write the decision rules in plain language: what the numbers have to look like at the end of week two for me to keep going, and what they have to look like at the end of week four for me to scale it or drop it. Use the thresholds we already set, and keep them specific enough that I cannot argue my way out of them later.The plan matters much less than the feedback loop. Almost every first plan is partly wrong, and the value comes from how fast it corrects. Run this same prompt in the project once a week with your real numbers pasted in.
Here are this week's real results for the three experiments: [paste your tracker rows, including the weeks where nothing happened].
Give me a verdict on each one against the thresholds we set, not against how it felt. Say plainly whether it is on track, off track or dead, and where a result is too small to draw a conclusion from, say that instead of reading meaning into noise.
Then update the playbook itself. Tell me what these results prove about my skills and my market that we did not know last week, what assumption we made that is now clearly wrong, and exactly what I should do differently in the next seven days. If one experiment should be killed, kill it and reallocate its hours to a named replacement rather than leaving them floating.To show the shape of the output rather than a result you should expect: say your low-effort experiment was offering a specific service to a specific type of small business, with the outcome number set as "replies to a first message" and the week-two threshold set at three replies from thirty messages.
A useful verdict reads like this. One reply from thirty is below the threshold, which is a real signal, but it is a signal about the message and the audience rather than about the service itself, because nobody has seen the service yet. So the next test changes one thing, either who you contact or what you say, and holds the rest constant. That is a playbook updating. Compare it to the version where you conclude "this does not work" and quit, which teaches you nothing and costs you the month.
ONS, Housing purchase affordability in Great Britain: 2024 (the 7.9x figure and the long-run price versus income divergence)
What are Projects, Claude Help Center