Naval Ravikant's ideas about wealth are often compressed into slogans about building once or finding unique knowledge. Those phrases can start a useful inquiry, but they can also hide the difficult work of solving a problem and reaching people who need the solution. This guide reads the ideas as a set of questions you can test. Modic's original games provide simplified decision environments; their points and income equations are teaching devices, not formulas supplied or endorsed by Naval.
Start with the actual idea, not a get-rich shortcut
In Naval's How to Get Rich conversations, knowledge, accountability, judgment, and leverage appear as complementary ingredients. Code and media can be reusable forms of output; financial capital and labour introduce other kinds of scale and dependence. The framework is worth reading in context. None of those ingredients supplies a guaranteed opportunity, audience, or income level on its own.
For a practical application, separate four questions: which problem can you understand, what useful output can you create, how will it reach people, and what evidence would show it works? Those questions make the framework operational without treating a successful author's perspective as an empirical forecast for every reader. Modic's games isolate small tradeoffs, leaving the harder business uncertainties visible.
Specific knowledge is easier to investigate through a concrete problem
The specific knowledge game asks you to combine three skills for a disclosed customer brief. Coding, logistics, and data analysis fit the local delivery-tool task; design, teaching, and writing fit the educational task. The point is not that these combinations are universally best. It is that usefulness depends on a problem and on how capabilities complement each other.
Look for evidence from projects, recurring questions people ask you, or unusual combinations of experience. Avoid turning the concept into a test of whether you were born exceptional. A capability can grow through practice and feedback. Ask what someone can do better after using your work, and whether you can demonstrate that improvement with a small output rather than a broad personal-brand claim.
Reusable output changes costs; it does not create demand
In permissionless leverage, divide a twelve-hour studio week between service work and building a reusable product. A supplied audience can use the product repeatedly, with a smaller delivery charge per use. Try the small and large audiences before repeating distribution. The first build has a cost, while later distributions reuse it. A low-copying-cost output can still lose money on its first launch.
The supplied audience is a deliberate simplification. In the real world, distribution, trust, support, competition, and maintenance consume effort too. Do not read the score as a forecast. Instead, explain which cost repeats with every customer and which is shared across many uses. A template, article, or small tool can make that distinction tangible without requiring a large startup or an elaborate launch.
A worked example: a small tool before a large business
Imagine someone with experience helping local shops who wants to create a simple delivery tracker. This is an original teaching scenario, not a case study of an actual company. The immediate goal is to test usefulness and distribution before investing months in a polished platform. Use the game for cost intuition, then replace its assumed demand with observations from real conversations.
- Define one task: help a shop see delayed deliveries without opening several spreadsheets. Identify the domain knowledge and delivery skills needed for that task.
- Build the smallest usable output and have one willing user try it on a real workflow. Record where it saves effort, where it causes confusion, and what support it requires.
- Only then test repeat use or distribution to another user. Compare the new delivery and support cost with the work reused from the first version; revise before expanding.
Include the work you are giving up
The opportunity cost experiment is a useful companion to the studio game. Hours spent building cannot simultaneously produce the same service output. If you compare a product's revenue with zero, you can make an expensive experiment look attractive. Compare it with a real available alternative, while recognising that learning and future options can also have value.
A small experiment can be worthwhile even when its first return is low, provided you can explain what it teaches and how you will limit the downside. The explore or exploit experiment examines spending effort on an uncertain option versus a currently better-known one. It does not tell you which career to choose; it makes the cost of learning and the benefit of better information visible.
Long-term thinking needs feedback and boundaries
Naval's discussion of long-term games emphasises continuity in relationships and repeated work. In a practical project, continuity can help experience, trust, and useful output accumulate. It should not mean ignoring evidence of failure or giving an experiment an unlimited budget. A durable effort still needs criteria for improvement and a reason the next step is valuable.
Use the compound growth experiment as a mathematical analogy for repeated accumulation, not as proof that every relationship or skill grows at a fixed percentage. Real learning can plateau, outputs can become obsolete, and cooperation can break down. Define what is accumulating in your situation and what would interrupt it. A metaphor becomes more useful when its limits are clear.
Do not confuse more reach with better judgment
Reusable output can distribute a mistake as efficiently as a good idea. That makes verification and context important. The circle of competence game encourages inspecting the range of outcomes you can justify before buying or passing an offer. Its reliable ranges are invented, but the habit of marking what you understand and what you are assuming transfers to a business decision.
Consider the cost of being wrong for the person using the output, not only for its creator. A helpful design makes uncertainty, limitations, and support needs visible. Scaling an unclear explanation or unreliable tool can increase confusion rather than value. Accountability can be practised through honest claims, a way to receive corrections, and a willingness to fix what your work gets wrong.
A practical two-week learning project
Pick a problem small enough to investigate in two weeks. The objective is not to establish that you have discovered your lifelong source of wealth. It is to complete a learning loop: understand a need, make an output, observe its use, and compare the result with your original expectation. Choose an effort limit that leaves essential responsibilities intact.
Finish with a short decision note. Describe what worked, what did not, what was actually reusable, and what you still assumed about demand. Decide whether the next small step earns its time. This gives you evidence that slogans cannot provide. Repeatable learning can be a useful outcome even when the first project does not become a business.
- One concrete user and task, rather than a broad audience promise.
- A small output demonstrating the relevant capability.
- A record of actual use, support needs, and feedback.
- An explicit time and spending limit.
- A next-step decision based on what changed, not on how inspiring the framework sounded.
Try the ideas for yourself.
These are teaching models. Follow the assumptions in each experiment; the results are not real-world forecasts.
Sources & further reading
Current-event context was checked on October 14, 2026. Follow the original source for newer updates. Worked scenarios are illustrative unless explicitly identified as reported data.
- Naval Ravikant: How to Get Rich ↗
Primary conversations; the studio equations and examples here are Modic's independent teaching design.
- Naval Ravikant: Play long-term games with long-term people ↗
Primary discussion of continuity and long-term thinking, not a promise of fixed compounding rates.