The PARA method sorts everything you own digitally into four buckets — projects, areas, resources, archives — and it sorts by how actionable a thing is rather than by what subject it belongs to. That single choice is why it survives contact with real life: actionability takes a second to judge, while "which topic is this really about" is an argument you can have with yourself for twenty minutes.
Most explanations of PARA assume a notes app or a folder tree underneath. This one assumes the opposite, because live commitments already sit in a task app for most people and it is the material that got orphaned.
The four buckets, and where each lands in a task app
Tiago Forte's definitions are short: projects are short-term efforts with a goal, areas are responsibilities without an end date, resources are interests and curiosities, archives hold anything from the first three gone inactive. Here is what each becomes inside an app built for to-dos.
| PARA bucket | what it holds | where it goes in a task app | what breaks if it is missing |
|---|---|---|---|
| Projects | efforts with a finish line — apartment move, tax return, the kitchen | a project object holding both to-dos and material | multi-step work turns into loose tasks nobody reviews |
| Areas | standing responsibilities — home, money, health, a job | the tier above projects, holding projects only | every project sits in one undifferentiated pile |
| Resources | things you may want later — recipes, a supplier list, holiday ideas | projects that never finish, or a tagged shelf | reference material leaks into a notes app and is lost |
| Archives | finished or abandoned items from the other three | a logbook plus archived projects | you delete things you will want, or keep everything visible |
The third row decides whether PARA works or stays theoretical. Projects and areas map cleanly onto almost any app. Resources do not, because an app that only stores tasks has nowhere to put a PDF, and the standard workaround is a second app — which is how a tidy four-bucket system becomes two systems and a reconciliation habit.
Areas are the bucket people get wrong
An area is a responsibility with no finish line. Home. Money. Health. The job. You do not complete "money", you maintain it — a bad project and a good container.
The common mistake is writing areas that are secretly projects. "Get fit" has a finish line hiding inside it and will go stale. "Health" does not. The test: if you can imagine ticking it off, it is a project. Four to six areas is normal for one person, and more than eight usually means some are projects wearing a costume.
The second mistake is nesting areas inside areas. Depth feels free and is not. Every extra tier is another decision at filing time and another place to look at retrieval time, and the second cost kills systems.
Resources are the bucket task apps forget
Forte's own recent argument for PARA is that organised material has become more valuable, not less, now that an assistant can read it: because a model works from whatever context you hand it, the value of an existing repository of data is rising and a project folder is a ready-made chunk of context. That only holds if the material is actually in the project.
So the practical question for resources is whether your app can hold a link, an image and a file next to a to-do. If it cannot, there are three options and all of them cost something: keep resources in a second app and pay a reconciliation tax at every review, paste URLs into task notes and lose everything that is not text, or move to a task app that stores material alongside the work — the argument personal knowledge management app works through app by app.
One older system is worth knowing here, because it attacks the same retrieval problem from a different direction. Johnny.Decimal gives every category and item a fixed number, so anything has one address you can say out loud. Stricter than PARA, and it pays off in long-lived archives. PARA is looser and cheaper to maintain alone.
How to lay PARA over a task app in an hour
This assumes a task app with projects in it and a mess of notes somewhere else.
- Write your areas first, on paper, before touching the app. Four to six, named as responsibilities rather than goals.
- Create those areas in the app. If there is no area tier, use top-level projects with a prefix and accept that counts will not roll up.
- Move every existing project under exactly one area. Anything fitting two areas is usually two projects.
- Sweep your notes app for anything attached to a live project — the quote, the link, the scan — and move it into that project. Twenty minutes, no reading.
- Everything left is a resource. Give it one home and stop splitting it. A single "resources" area with a few standing projects inside beats a taxonomy you will not maintain.
- Archive aggressively. Anything untouched for three months and not on a shelf you deliberately keep goes to the archive rather than the bin. Having an archive is what makes that easy to do.
- Book fifteen minutes a fortnight to repeat steps 3 and 6. PARA drifts, which is cheap to correct as long as the correction is scheduled.
Expect fewer projects at the end than you started with. Half of what people call projects turn out to be single actions with an inflated title.
Where PARA rubs against a task app
Two honest frictions. First, PARA's resources bucket assumes a place for material with no due date, and plenty of good task apps do not have one. If yours does not, PARA stays half-implemented there and no amount of tagging fixes it.
Second, PARA and GTD disagree about what "project" means — GTD calls anything needing more than one action a project, a much lower bar than PARA's short-term effort with a goal. Run both at once and you get either forty PARA projects or four GTD ones. GTD vs PARA settles that argument properly; the short version is to pick one definition and let the other system bend.
Where init.Tasks fits
init.Tasks gives PARA's first two buckets real structure rather than a naming convention: an area is a container the app knows about, a project is an object inside it, and neither is a tag you have to remember to apply. It is a terminal-styled task and second-brain app on iOS, macOS and web.
Resources are the bucket that decides whether any of this holds, and links, notes, images and files are filed into a project alongside its to-dos — the somewhere-real that the third row of the table above was asking for. Quick add takes plain language, so book the fitter 17 nov #kitchen-reno lands in the right project with the date attached.
The AI connection is coming in september, and a connected assistant can read a project and file into it — mostly useful for the boring half of a PARA migration. GTD's own five lists and its one-sitting setup live in the app for GTD piece rather than here, and what is a second brain covers why the material matters at all.
The beta waitlist is open, invites go out in september, and everything is free while in beta.
FAQ
What is the PARA method?
PARA organises digital information into four buckets — projects, areas, resources and archives — ranked by how actionable each item is right now. Projects are efforts with an end. Areas are responsibilities without one. Resources are material you might want later. Archives hold whatever has gone inactive. Tiago Forte created it as the organising layer of Building a Second Brain.
What is the difference between an area and a project?
A project finishes; an area does not. "Renew the passport" finishes. "Paperwork" never does. In practice the area is the container and the project is the thing inside it, so if you can picture ticking something off, it belongs one tier down. Areas that feel completable are projects that have been promoted by mistake.
Where do resources go if my app only stores tasks?
Somewhere unsatisfying, honestly. The usual answers are a note attached to a task, a project that never completes, or a second app kept in sync by hand. Each loses something — attachments, findability, or your patience. If reference material is a real part of your work, an app that stores files and links beside tasks removes the problem rather than managing it.
Do I need a separate notes app to use PARA?
Only if your task app cannot hold non-task material. PARA does not care which app it runs in; it cares that the four buckets exist and that an item lives in exactly one. Two apps means an item can live in two places, and that ambiguity erodes the system within months.