Bayesian Decision Theory for Your Projects and Honestly, Life

30 Jan, 2026

Hey! We are going to go over a rough overview of bayesian decision theory, and how you can apply it to your life, places where you can identify key objects in decision theory so you can stay better informed when making decisions and updating your beliefs!

If you’re the key developer on a side project, you’re constantly doing a quiet kind of forecasting. You decide what to build next, what to ship, what to cut, when to refactor, when to market, and when to pause. And you do it with imperfect information. Bayesian decision theory is a clean way to describe what you’re already doing, except it gives names to the pieces and shows how they fit together mathematically.

Simply put, beliefs shape predictions, predictions shape decisions, and outcomes update beliefs. Once you can point to each object in that loop, you get less lost inside your own intuition.

The world you don’t fully see

There’s always something true about your project’s reality that you can’t directly observe. Call it the hidden state.

Let the hidden state be $θ$ .

In side-project terms, $θ$ might represent things like: how much users actually want this, which feature is the real hook, what onboarding friction is fatal, how reliable your infra will be under load, how hard growth will be, or even how much time and energy you’ll realistically have each week. It can be one number, a vector of unknowns, or “which of these stories about the project is true.”

Bayesian thinking starts by admitting: you don’t know $θ$ , but you can hold a distribution over it. That distribution is your belief distribution.

“Prior” in casual ML talk vs what it means in math

In ML / Bayes circles, people say “update your priors” to mean “update your assumptions” or “change your mind when evidence shows up.” That’s decent advice, but it blurs a technical distinction that matters when you’re trying to be precise.

Mathematically, a prior is always defined relative to a specific update step.

Before you incorporate a particular new piece of evidence $x$ , your prior is $p (θ)$ . After you incorporate $x$ , your posterior is:

p (θ ∣ x) \propto p (x ∣ θ) p (θ)

In sequential life, you rarely reset to some original $p (θ)$ . You carry a running distribution shaped by all evidence so far. That running distribution is often called your belief state:

b_{t} (θ) : = p (θ ∣ x_{1 : t})

Here’s the key identity that resolves the confusion: today’s posterior is tomorrow’s prior.

When new evidence $x_{t + 1}$ arrives,

p (θ ∣ x_{1 : t + 1}) \propto p (x_{t + 1} ∣ θ) p (θ ∣ x_{1 : t})

So in casual speech, “prior” often means “whatever I currently believe,” which is typically the belief state $b_{t} (θ)$ . In math, “prior” means “the distribution before this particular conditioning step,” which might be your original $p (θ)$ or, more commonly in an ongoing project, yesterday’s posterior $p (θ ∣ x_{1 : t})$ .

Evidence is what you actually learn

As you build, you collect evidence: a couple user conversations, retention from a tiny launch, error logs, how long tasks really take you, whether people share it, whether you personally keep coming back to it.

Call the evidence $x$ .

Evidence updates beliefs:

p (θ ∣ x) \propto p (x ∣ θ) p (θ)

The term $p (x ∣ θ)$ is the likelihood: “if the world were like $θ$ , how likely is it that I’d see evidence $x$ ?”

Side-project translation: if users truly crave the thing, would I see excited replies and repeat usage? If onboarding is the bottleneck, would I see drop-off at step 2? If my scope is too big, would I see endless refactors and no shipping?

After you update, you have a posterior $p (θ ∣ x)$ . In an ongoing project, that posterior becomes part of your belief state $b_{t} (θ)$ , the thing you carry forward.

Actions are choices you control

Now comes the part that feels like “decision time.”

Let your action be $a \in 𝒜$ .

For a key developer, actions look like: build feature A, fix onboarding, write docs, do a marketing push, refactor, add payments, recruit a collaborator, pause the project, or run a small experiment.

Decision theory says: you don’t just want to predict what happens. You want to choose actions that lead to good outcomes, given your current beliefs.

Outcomes are what the world gives back

After you act, something happens.

Call the outcome $y$ .

For a side project, $y$ could be: signups this week, retention after day 1, bug rate, revenue, performance metrics, how you feel after working on it, or even “did I ship something real?”

Outcomes depend on both the hidden state $θ$ and the action $a$ . The mathematical way to say that is:

p (y ∣ a, θ)

Same action, different underlying world, different outcome distribution.

The distribution you “materialize in your mind”

When you’re about to pick an action, you usually don’t think “what is $θ$ exactly?” You think “what will happen if I do this?”

That mental simulation is the posterior predictive distribution:

p (y ∣ x, a) = \int p (y ∣ a, θ) p (θ ∣ x) d θ

If you’re thinking sequentially (evidence accumulating over weeks), you can replace $p (θ ∣ x)$ with the belief state $b_{t} (θ) = p (θ ∣ x_{1 : t})$ . Same idea: you integrate out uncertainty about the true world and get a predictive distribution over what you’ll see next under a given action.

This is the “marginal in your mind”: you’re marginalizing over $θ$ .

Utility: what you actually care about

Not all outcomes are equal. Some are wins, some are acceptable, some are disasters.

Let utility be $u (a, y, θ)$ .

Utility is deliberately personal. For a side project, utility might combine: learning, joy, reputation, revenue, long-term optionality, risk, maintenance burden, and time cost. Sometimes it depends on $θ$ too: infrastructure work might only be worth it if growth is real.

Choosing actions by expected utility

Bayesian decision theory’s default move is: pick the action with the highest expected utility under your current beliefs.

a^{*} (x) = a r g {max}_{a \in 𝒜} 𝔼 [u (a, Y, Θ) ∣ x]

Expanding makes the two-layer uncertainty explicit:

𝔼 [u (a, Y, Θ) ∣ x] = \int (\int u (a, y, θ) p (y ∣ a, θ) d y) p (θ ∣ x) d θ

This is where “priors” sneak in even when nobody says the word. Your current belief state (a posterior from everything you’ve seen) shapes $p (θ ∣ x)$ , which shapes the predictive $p (y ∣ x, a)$ , which shapes the expected utility, which picks the action.

Learning from what happens after you act

After you take an action $a$ , you observe an outcome $y$ . That outcome is new evidence, and it updates your beliefs:

p (θ ∣ x, a, y) \propto p (y ∣ a, θ) p (θ ∣ x)

A subtle point: the action $a$ is not evidence by itself. The evidence is what you observe after acting. The action matters because it changes which likelihood applies and what data you get.

More specifically, “I posted a demo video” isn’t evidence. “I posted a demo video and got 30 inbound messages from the target user type” is evidence.

Actions that are valuable because they teach you

A lot of side-project choices are secretly experiments.

A small release, a pricing test, a landing page, a prototype, a targeted user interview script, a constrained A/B. The point isn’t only immediate payoff; it’s that the feedback will reduce uncertainty and improve your next move.

One way to express that is: choose actions that maximize not just immediate expected utility, but the expected value of being able to make a better decision after learning:

a r g {max}_{a} 𝔼_{y ~ p (y ∣ x, a)} [{max}_{a^{'}} 𝔼 [u (a^{'}, Y^{'}, Θ) ∣ x, a, y]]

Translation: pick the move that produces the most useful next belief state, not just the most comforting short-term result.

A simple way to hold the loop in your head

If you want a lightweight mental checklist you can use weekly as the key developer:

Belief state: $b_{t} (θ) = p (θ ∣ x_{1 : t})$ . What do I currently believe about the hidden reality of this project?

Action: $a$ . What choice am I about to make?

Predictive: $p (y ∣ x_{1 : t}, a)$ . What do I think will happen if I do it?

Utility: $u$ . What do I actually care about, including my time and energy?

Update: $b_{t + 1} (θ) = p (θ ∣ x_{1 : t + 1})$ . After I do it and see what happens, how should my beliefs change?

Once you can name these, you can notice what’s missing. Sometimes you’re stuck because utility is vague. Sometimes because you’re treating a single story as certain instead of holding a distribution of potential stories. Sometimes because you need an action that generates sharper feedback.

This framework turns “intuition” into objects you can inspect, adjust, and refine as you build.