You know what a VPS is and what it costs you in upkeep. Now the discipline that saves beginners the most money and grief: never choose the home before naming the work. Classify first, rent second.

The workload card: seven adjectives that decide everything

Every job your product does can be described with the same small card. Fill it honestly and the hosting choice often makes itself:

A workload is just the answers to those seven questions, plus what triggers it and what happens if it fails. "The backend" is not a workload. "Nightly SEC ingestion that takes twelve minutes and writes to Postgres" is.

Four cases, classified live

Watch the card do its work on four jobs you will meet constantly:

1. Portfolio site. Static pages, updated rarely. Trigger: visitor request. Duration: milliseconds. Frequency: occasional reads. Data: files, no database writes. Failure impact: page fails to load. Always-on process? No. There is almost no compute here — files served to browsers need no idle server burning money all day.

2. Scheduled SEC-filing ingestion. Trigger: clock (nightly, after the expected release window). Duration: minutes. Frequency: once a day, not once a second. Data: reads source API, writes Postgres. Failure impact: stale research data until the next run. Always-on process? No — not necessarily. A cron-triggered function or a short-lived worker that wakes, does the fetch, writes results, and exits fits better than a computer idling twenty-three hours for a twelve-minute job.

3. Long-lived bot (Discord/Slack-style). Trigger: persistent connection plus incoming messages at any moment. Duration: effectively continuous — it holds a session open for days. Frequency: unpredictable. Data: reads conversation state, calls model or database per message. Failure impact: the bot goes silent; the community notices immediately. Always-on process? Yes — maybe. A persistent connection genuinely wants something awake holding it. That is the VPS-shaped workload (or a managed long-running host).

4. Image-processing job. Trigger: user upload. Duration: seconds to minutes per image, heavy CPU. Frequency: bursty — quiet, then fifty uploads at once. Data: reads object storage, writes thumbnails and metadata. Failure impact: slow or timed-out requests; retried uploads. Always-on process? No — but a request handler alone is wrong too. The right shape is a fast request that enqueues the job plus a queue and worker that grind through images with retries — the subject of Class 26.

Notice what just happened: four jobs, four different homes. "VPS by default" would have overpaid for the portfolio site, idled pointlessly for the nightly fetch, worked for the bot, and timed out for the image burst.

"Runs all the time" vs. "available all the time"

The costliest confusion in infrastructure, stated plainly:

• "Runs all the time" means a process is executing continuously — burning CPU around the clock. Bots holding connections, game servers, streaming relays. Rare and expensive.
• "Available all the time" means a visitor *can* get an answer at any hour — usually because something wakes in milliseconds when asked, does the job, and sleeps again. Most web products, APIs, and scheduled collectors only need this.

A portfolio site must be *available* at 3 a.m.; nothing must be *running* at 3 a.m. to achieve it. A nightly collector must *run* for twelve minutes; it must not occupy a computer the other twenty-three hours and forty-eight minutes unless nothing cheaper fits. Ask which claim you are really making before you pay for either.

Choice preview: four homes, no rules yet

Class 25 turns this into a full decision framework. For now, hold the four homes side by side without detailed selection rules:

Detailed rules — control, operating burden, cost shape, reliability — belong to Class 25. Today's job is humbler and more valuable: describe the work truthfully so those rules have something to grip.

Visual: one card, four stamps

Picture a single blank workload card (trigger, duration, frequency, data, failure, always-on?) stamped four times: PORTFOLIO → "no compute," SEC INGESTION → "clock, not computer," BOT → "maybe always-on," IMAGE JOB → "queue + worker." The visual teaches the lesson in one glance: same card, different verdicts.

Practical exercise: four workload cards

Create four workload cards for your project. If your project is small, invent the missing ones from this lesson's cases — the practice is the classification, not the project size. For each card, write one line per field:

• Trigger: what starts it (request / clock / event / upload)?
• Duration: milliseconds, seconds, minutes, or continuous?
• Frequency: constant, scheduled, bursty, rare?
• Data accessed: what does it read and write?
• Failure impact: stale data? silent bot? timed-out user? What notices first?
• Always-on? Yes, no, or "no — but needs ___ instead." Decide and defend it in one sentence.

Finish line: four cards, each ending in an explicit always-on verdict with a one-sentence reason.

Verify: for each card, ask: "If I replaced 'runs all the time' with 'available all the time,' would the answer change?" If yes, you just saved yourself a server.

Common failure mode: writing "the app" as one workload. Split it. The web page, the nightly fetch, the upload processor, and the bot are four workloads wearing one product's clothes — and they want different homes.

Check your understanding

1. What seven adjectives belong on a workload card? 2. Why does a static portfolio site need almost no always-on compute? 3. Why might a scheduled collector fit a cron-triggered function better than an idle VPS? 4. What kind of workload genuinely argues for an always-on process? 5. Why does a bursty image job want a queue plus a worker rather than a bigger request handler? 6. In your own words, what is the difference between "runs all the time" and "available all the time"?