How to decide which property gets your next hour
A solo operator running several small properties makes almost no decisions that resemble capital allocation in the textbook sense. What gets allocated, every single day, is hours, and hours behave nothing like money: they cannot be pooled, borrowed, or carried forward, and they are spent by default whether or not you choose. This is a framework for choosing.
The hour is the only capital you actually allocate
A solo operator makes very few decisions that resemble capital allocation in the textbook sense. There is rarely a large sum to deploy, and the infrastructure costs of a small internet business are low enough that money is seldom the binding constraint. What gets allocated, relentlessly and every day, is hours.
That makes the problem harder rather than easier, because hours cannot be pooled, borrowed, or carried forward. An hour not spent is not saved; it is gone. And unlike money, hours are spent by default. If you do not choose, the day chooses for you, and it usually chooses in favor of whatever produced a pleasant feeling most recently.
So the practical question is never which property matters most in some abstract ranking. It is a scheduling question asked over and over: given this specific next hour, and the state everything is in right now, where does it go.
Why the obvious rankings fail
The first instinct is to rank by size and give the hour to the property that is furthest along. This rewards the past. A property that already works often needs the least marginal input, and hours poured into it can be the least productive hours of the week while feeling like the most responsible ones.
The second instinct is to rank by potential, which is worse, because potential is a story and stories are free to write. Every unlaunched idea outperforms every live property on potential, and it will keep doing so right up until the moment it meets a stranger.
The third instinct is to follow interest. Interest is not worthless, since a solo operator running on their own motivation cannot ignore it entirely, but interest tracks novelty and novelty tracks whatever you touched least recently. Following it produces a schedule that looks like a random walk and feels like productivity, which is the most expensive combination available.
Ask what the hour buys, not which property deserves it
The fix is to stop ranking properties and start classifying work. Properties do not deserve hours. Hours produce outcomes, and those outcomes fall into a small number of kinds. Once you name the kind, the priority is usually obvious without relitigating your whole strategy.
This reframing matters because it survives contact with a bad mood. Ranking properties invites an argument with yourself every morning, and the argument is unwinnable because both sides have the same information. Classifying the work in front of you is a mechanical question you can answer in ten seconds while tired, which is the condition most scheduling decisions are actually made in.
Three things an hour can buy
Nearly every genuinely useful hour buys one of three things. Anything that buys none of them is a candidate for deletion rather than scheduling, and the sooner that is said out loud the better.
- Removal of a blocker — something currently at zero that can become nonzero, such as a property that cannot take a payment at all, or a page nobody can reach
- Information — a test that changes what you believe, such as putting a real offer in front of a stranger and finding out whether the silence is polite or total
- Compounding — an asset that keeps working after the hour ends, such as a published page, a piece of reusable infrastructure, or a name added to a list you own
- Maintenance — which buys none of the three but prevents loss, and which is treated separately because it does not compete with them, it precedes them
The reason to keep this list short is that a long taxonomy is a decision you have to make twice. Four categories can be held in the head at the end of a long day. That is the entire design requirement.
Unblock before you optimize
When work of different kinds competes, blockers win, and the reason is arithmetic rather than urgency. A blocked property is at zero on some dimension, and zero does not respond to improvement anywhere else. A better landing page on a property that cannot accept money changes nothing at all about the money.
Optimization is a slope; a blocker is a switch. Slopes can be improved later at roughly the same cost, and they only compound after the switch is on. This one rule settles most of the hard-looking allocation questions a portfolio produces, because at any given moment one or two properties are broken in some binary way and everything else is merely imperfect.
The discipline is in admitting what actually counts as a blocker. It is not a feature you want, however badly. It is a specific place where the chain from a stranger to a completed outcome is severed, and where nothing downstream can matter until it is joined.
Maintenance is not progress, and it is not optional
A portfolio accumulates upkeep whether or not it accumulates revenue. Certificates expire, integrations change shape, a form starts failing quietly, a mailbox fills up. None of it is progress and all of it is compulsory, because the cost of neglect is not zero. It is the slow death of a property nobody noticed had stopped working.
The mistake is letting maintenance compete with the productive kinds of work for the same hours. It always loses that competition, right up until the day it wins everything at once and takes a week with it. Give it a fixed slot, let it be boring, and let the boredom be the point.
Batch by mode, not by property
Switching between properties is expensive, but the expense is usually misattributed. What costs you is not the property. It is the mode, because writing, building, fixing, and selling each demand a different state of mind, and moving between those states is what leaves an operator tired with nothing shipped.
So batch by mode wherever the work allows it. An afternoon of writing across three properties tends to produce more than an afternoon that touches one property in four different ways. A portfolio makes this easier rather than harder, because it supplies enough work of each kind to fill a block without inventing tasks.
The weekly question
All of it reduces to one question, asked once a week, in writing. For each property: is anything at zero, and what would the next hour buy. That is the whole framework, and it fits on an index card, which is the only format that gets used after the first enthusiastic month.
Write the answers down, because the written version is what protects you from your own recall. Memory reports which property felt most alive this week. The written answer reports which property is blocked, which one is waiting on a stranger, and which one is quietly compounding without you. Those are three different facts, and only the written ones can still be trusted on Friday.
Common questions
How do you prioritize work across multiple side projects?
Stop ranking the projects and start classifying the available work. Hours buy one of three things: removal of a blocker, information that changes what you believe, or an asset that keeps working after the hour ends. Naming the kind usually settles the priority without any argument about which business you like more.
Should you work on one project at a time or rotate between them?
Rotate by mode rather than by project. The expensive switch is between kinds of work, since writing, building, fixing, and selling each demand a different state of mind. An afternoon of writing across three properties usually produces more than an afternoon that touches one property in four different ways.
How much time should go to maintenance versus new work?
Enough that maintenance never has to compete with new work for the same hour, because it loses that competition until the day it wins everything at once. Give upkeep a fixed, boring slot on the calendar. A predictable small tax is far cheaper than an unpredictable large one.
Every property in the Don Gastón portfolio is independently live — built, deployed, and operated by one person.
See what's live in the portfolio