# Build Your Own Stuff — the complete guide # Source: https://itsjustin.me/build/ | Author: Justin Willhite | Updated: 2026-07-14 # A plain-English field guide for non-engineers who want to build software by # directing AI agents. Free to read. Contains affiliate links, disclosed on the site. # This file is the entire guide as plain text, for LLMs and retrieval agents. --- # Build your own stuff. A field guide for people who are not engineers. Get your own server. Point an AI agent at it. Stop renting software you could host yourself. Keep the costs from running away while you learn. I am not a developer. I do not write the code. I run a business, and over the last year I built a stack of about thirty-five services I actually use every day — monitoring, a password vault, a task manager, client dashboards, a daily podcast pipeline, several client websites — by directing AI agents rather than by learning to type C++. Everything on this page is something I got wrong first and fixed second. It is not a computer science course. It is the set of moves that got me from "I have an idea and no idea how to build it" to "the thing is live and it cost me eleven dollars a month." **Figure: How the pieces fit together** > **Who this is for** > > You run something — a business, a team, a side project. You keep having ideas that die because you assume you'd need to hire someone. You have used ChatGPT or Claude and thought "there's more here than I'm getting." That's you. Start at chapter one and go in order; each one assumes the last. ## Six chapters Roughly a weekend end to end, if you actually do the steps rather than just read them. A computer on the internet that is yours, for about the price of two coffees a month. This is the thing that unlocks everything else, and it is the step most people never take. Claude Code is not a chatbot. It is an agent that lives on your server, reads your files, runs commands, and builds things. Installing it takes four minutes. The single highest-leverage file you will ever write. Tell the agent who you are, how you think, and which commands it may run without stopping to ask you. One account, every AI model, one bill. How to use cheap models for cheap work, separate your projects so you can see where the money goes, and set a hard ceiling. Most of the SaaS you pay for has a free, open-source version you can run yourself in ten minutes. How to find them, how to judge them, and which ones are actually worth it. The real bottleneck was never the code. It's that you don't yet believe the thing in your head is buildable. Here's how to fix that. ## Four things I wish someone had told me - **You are not learning to code. You are learning to direct.** The skill is describing what you want precisely, noticing when the result is wrong, and knowing enough to ask the right follow-up. That is a management skill, and you probably already have it. - **Owning the server changes what you're willing to try.** When a new tool costs you nothing but twenty minutes, you try ten things a month instead of one thing a year. That's the whole game — not any individual tool. - **The costs that hurt are the invisible ones.** Not the $6 server. The AI bill you didn't watch, and the eleven SaaS subscriptions you forgot you had. Chapter four and chapter five, respectively. - **Break it. It's yours.** Everything I know, I learned by taking something down at 11pm and putting it back up by midnight. A server you're afraid to break is a server that teaches you nothing. ## Frequently asked questions ### Do I need to know how to code to follow this guide? No. I don't write code and I built about thirty-five services this way. The skill you need is describing what you want clearly, noticing when the result is wrong, and asking a good follow-up. That's a management skill, not a programming one, and you probably already have it. ### What does all this actually cost per month? About $7 for the server, plus roughly $20 to $30 in AI usage if you build automations that call a model. The tools in chapter five are free and open source. For most small businesses that total is less than the SaaS subscriptions it replaces. ### What is a VPS? A VPS is a virtual private server: one slice of a large machine in a data center, rented to you. It has its own operating system, storage, and internet address, and nobody else can see inside it. It costs about six dollars a month and it is the foundation for everything else here. ### How is Claude Code different from ChatGPT or a normal chatbot? A chatbot writes code in a window and you copy it out, run it yourself, and paste the error back. Claude Code is an agent that runs on your server: it opens the real files, runs the real command, sees the real error, and fixes it. It closes its own loop, so you stop being the courier. ### How do I stop my AI costs from running away? Three rules. Use a cheap model for routine work and only step up to an expensive one when the cheap one fails twice. Create a separate API key for every project so you can see which one is spending. Put a hard spending cap on each key, so a runaway loop stops itself instead of draining your balance. ### Is self-hosting safe, and what's the catch? The catch is real: you become the person responsible for updates and backups, because nobody else is doing it for you. Mitigate it by setting up automatic backups the same day you install anything, and by only running projects that are actively maintained. If something is truly irreplaceable and you know you won't maintain it, paying someone else is a legitimate choice. ### Which VPS plan should I buy? The smallest one that comfortably runs several tools, which is about two cores and 8GB of memory. Buying a big plan up front is the most common first mistake. You can upgrade later with one click and no reinstall. ## Disclosure Some links on this site are affiliate links, which means I may earn a commission if you sign up through them, at no extra cost to you. I only link things I actually run. Where a free option is better than a paid one — which is most of chapter five — I say so and I make nothing. Nobody paid me to write any of this. If a recommendation here ever stops being what I'd tell a friend, it comes off the page. --- # Get your own server. A computer on the internet that belongs to you, running all the time, for roughly six dollars a month. Nothing else in this guide works until you have one. ## What a server actually is A server is just a computer that stays on and is reachable from the internet. That's it. There's no magic in it. The one you rent is called a **VPS** — a virtual private server — which means a big machine in a data center somewhere has been sliced into pieces and you're renting one of the slices. You get your own operating system, your own storage, your own address. What you do inside it is nobody's business but yours. **Figure: What a VPS is** Here's the part that matters, and it took me an embarrassingly long time to understand: **renting a server is not a technical decision, it's a permission slip.** The moment you have one, the cost of trying something drops to nearly zero. Want a password manager? Install one, twenty minutes. Want a private analytics tool? Same. Want to see if that weird idea works? Build it, and if it's garbage, delete it. You stop asking "can I afford to try this" and start asking "is this worth twenty minutes." Before I had one, every idea ended at the same wall: I'd need to hire someone, or pay a monthly fee, or learn to code. After, the wall was gone. That's the whole chapter, honestly. The rest is logistics. ## What to buy I use **Hostinger** for this and recommend it for your first one — the pricing is honest, the control panel doesn't require a pilot's license, and you can be running in about five minutes. Their VPS plans start around five or six dollars a month. > **Start here** > > Get the smallest VPS they sell. Seriously. You do not need the big one. Two CPU cores and 8 gigabytes of memory will run a dozen tools comfortably, and you can upgrade later with a single click and no reinstall — I've done it. Buying big up front is the most common first mistake and it's pure waste. ### Which plan | Plan | Good for | | |---|---|---| | **KVM 1** 1 core | Kicking the tires. Fine for one or two small things; you'll outgrow it. | [Get KVM 1](https://www.hostinger.com/vps-hosting) | | **KVM 2** 2 cores / 8GB | **Start here.** Runs a dozen tools comfortably. This is the one chapter five assumes. | [Get KVM 2](https://www.hostinger.com/vps-hosting) | | **KVM 4 / 8** | Only once something you run actually needs it. Upgrading later is one click and no reinstall. | [KVM 4](https://www.hostinger.com/vps-hosting) · [KVM 8](https://www.hostinger.com/vps-hosting) | ### The two choices you'll be asked to make - **Operating system:** pick **Ubuntu** (the most recent LTS version they offer). Every guide on the internet, and every instruction an AI gives you, assumes Ubuntu. Do not get clever here. - **Location:** pick the data center closest to you or your customers. It changes almost nothing at this scale, so don't agonize. ### You'll also want a domain name Not strictly required, but everything is nicer when your tools live at `notes.yourname.com` instead of a raw string of numbers. Domains cost about $12/year. Buy it wherever — Hostinger sells them, so does [Namecheap](https://www.namecheap.com/). Then point it at your server's IP address. If that sentence means nothing to you, don't worry: this is the exact kind of thing you will hand to the AI agent in chapter two and it will walk you through it. ## The first twenty minutes Once it's provisioned, Hostinger gives you an IP address (a string of numbers like `203.0.113.42`) and a root password. You connect to it with a thing called **SSH** — a text connection to the server. On Windows, Mac, or Linux, open a terminal and type: ``` # replace with your actual IP address ssh root@203.0.113.42 ``` It'll ask for the password. Paste it. You're in. You are now looking at your own computer, in a data center, and it will do whatever you tell it. > **Do these three things before anything else** > > Your server is on the public internet, which means bots start knocking on the door within minutes. This is normal and nothing to panic about, but do the basics: - **Update everything.** Run `apt update && apt upgrade -y`. This pulls in security patches. Do it now, and do it every few weeks. - **Turn on the firewall.** A firewall closes every door except the ones you deliberately open. `ufw allow OpenSSH`, then `ufw allow 80`, then `ufw allow 443`, then `ufw enable`. Those three are: your text connection, web traffic, and secure web traffic. - **Set up SSH keys and turn off password login.** A key is a long cryptographic file on your laptop that replaces the password. It's dramatically safer, because a bot can guess a password and cannot guess a key. This is the one step people skip, and it's the one that gets them. If any of that sounds like a lot: it is exactly the sort of thing you will paste into an AI agent verbatim and have it done in five minutes. Which brings us to the next chapter. ## What this actually costs | Thing | Cost | Note | |---|---|---| | **VPS** | ~$6/mo | The whole foundation. Runs a dozen tools. | | **Domain name** | ~$12/yr | Optional but you'll want one. | | **HTTPS certificate** | $0 | Free forever, via Let's Encrypt. Automatic. | | **Every tool in chapter 5** | $0 | Open source. This is the part that saves real money. | Call it **$7 a month** to have a place where you can build anything you want. I pay more than that for a single SaaS subscription I barely use. --- # Put an AI agent on it. A chatbot writes you code and you copy-paste it somewhere. An agent lives on the server, opens the files itself, runs the commands itself, sees the error itself, and fixes it. That difference is the entire ballgame. ## Why this is different from what you've used If your AI experience so far is a chat window, you have been playing with one arm tied behind your back. The chat window can't see your files. It can't run anything. It guesses at what your setup looks like, hands you a block of code, and you paste it in and it doesn't work because it guessed wrong, and you paste the error back in, and around you go. An agent closes that loop. **Claude Code** runs in the terminal on your server. It reads your actual files. It runs the actual command. It sees the actual error message and fixes it, and then runs it again to check. You describe the outcome you want in plain English and it does the loop until the thing works. **Figure: A chatbot loop versus an agent loop** I want to be blunt about what this makes possible, because it sounds like hype and it isn't: I do not write code. Not a line. Everything I run — the monitoring, the client sites, the daily podcast pipeline that publishes at four in the morning without me — was built by describing what I wanted, checking the result, and asking for changes. The skill is not programming. The skill is knowing what you want and being able to tell when you didn't get it. ## Install it SSH into your server (chapter one), then run this: ``` # install it curl -fsSL https://claude.ai/install.sh | bash # start it claude ``` The first time it starts, it'll ask you to log in. You have two options, and the choice matters: | Option | How it bills | Best for | |---|---|---| | **Claude subscription** (Pro or Max) | Flat monthly fee. Generous usage limits, and when you hit them you wait rather than pay more. | **Almost everyone.** Predictable, and you never get a surprise bill. This is what I use for building. | | **API key** (pay as you go) | Per million words in and out. No ceiling unless you set one. | Automated things that run without you watching. Covered properly in chapter four. | Start with the subscription. Log in, and you're talking to an agent that is standing inside your server. ## Your first hour Don't build anything yet. Spend an hour letting it show you around. Type these, literally, one at a time: - *"Walk me through what's on this server right now. I'm not a developer — explain it like I'm smart but new."* - *"Set up SSH keys for me and disable password login, then explain what you just did and why it's safer."* - *"Install and configure a firewall. Tell me what's open and what isn't."* - *"I own the domain example.com. Point it at this server and set up free HTTPS so it shows the padlock."* Those four prompts do the entire chapter-one security checklist, and you learn what each thing is while it happens. That's the pattern for everything from here on: **describe the outcome, ask it to explain as it goes.** > **Add this sentence to everything** > > "Explain what you're doing in plain English as you go, and tell me what could break." It costs you nothing and it converts every task from a black box into a lesson. Six months of this and you will understand your own infrastructure better than you expect. ## Three habits that make it dramatically better ### 1. Use git, even for junk Git is a time machine for your files. Every time the agent changes something, git remembers the version before. When you break something at midnight — and you will — git is the difference between "roll it back, thirty seconds" and "the whole evening is gone." You don't need to learn git. You need to say *"commit this before you start"* and *"undo the last change"* and let the agent drive. But have it on from day one. ### 2. Run it inside `tmux` Normally, if your SSH connection drops, whatever was running dies with it. `tmux` keeps the session alive on the server, so you can close your laptop mid-task, walk away, reconnect later, and it's still going. Install it (`apt install tmux`), start a session with `tmux new -s work`, and reconnect with `tmux attach -t work`. Small thing, enormous quality-of-life gain. ### 3. Ask for the boring stuff too The agent is just as happy to write your backup script, your monitoring alert, and your documentation as it is to build the exciting feature. The boring stuff is what keeps the exciting stuff alive. I learned this the hard way, which is the only way anyone learns it. ## The one thing that will annoy you By default, the agent stops and asks permission before running commands. This is correct and good — you do not want an AI running `delete everything` because it misunderstood you. But after the fortieth time it asks whether it may please be allowed to *list the files in a folder*, you will start clicking "yes" without reading, and that is the exact moment safety turns into theater. The fix is not to turn permissions off. The fix is to tell it precisely which commands are safe to run without asking — read a file, list a directory, check status — while still stopping for anything that deletes, sends, or spends money. That's the next chapter, and it's the most valuable one in this guide. --- # Teach it how you work. Two things go in this chapter. A file that tells the agent who you are, and a rule that tells it which commands it may run without stopping to ask. Together they're worth more than any technical skill in this guide. ## The file that changed everything for me Claude Code reads a file called `CLAUDE.md` in whatever folder you're working in, every single session, automatically. Whatever you put in it becomes standing instructions. Most people leave it empty or fill it with technical notes. That's a waste. The most useful thing I ever put in mine had nothing to do with code: ``` I have ADHD and I am not a developer. Adjust how you talk to me: - Lead with the answer. First sentence is what happened or what you recommend. Detail after. - Plain English. If a technical term is unavoidable, define it in the same sentence. - No walls of text. No arrow-chains. No jargon I'd have to look up. - Be the organized one. I context-switch constantly. Track the loose ends and surface them to me. - Give me a recommendation, not a menu of five options. - One thing at a time. If a task grows tentacles, name the tentacles and propose an order. ``` The difference was immediate and it was not subtle. The agent stopped handing me dense technical dumps I'd skim and misunderstand, and started handing me answers I could act on. If you have ADHD, or you're dyslexic, or English is your second language, or you just hate being talked down to — **say so, in the file.** It will listen. Every session. Forever. > **This is the actual unlock** > > Everyone spends their energy trying to write better prompts. Almost nobody spends an hour telling the model who they are and how they need to be spoken to. The second one compounds across every conversation you will ever have. Do that one first. ## A starter file you can steal Create `CLAUDE.md` in your project folder and adapt this. Everything in it is something I use. ``` # Working with me — read this first ## Who I am I run a business. I am not an engineer and I do not write the code. Explain what a thing *does* and *why it matters* before you name the tool or the file. ## How to talk to me - Lead with the answer, detail after. - Plain English. Define any term you have to use. - Short paragraphs, not walls. - Recommend, don't present a menu. Note the real trade-off. - Ask a sharp question if the request is ambiguous — but don't ask me things you could just go check yourself. - Track my loose ends and surface them. I forget. ## How I want you to work - Commit to git before you start anything nontrivial. - Never delete or overwrite something you didn't create without showing me first. - After you change something, actually run it and confirm it works. Don't tell me it's done because it should be. - If tests fail, say so and show me the output. Don't hedge. - Prefer boring, proven tools over clever new ones. ## What this project is [One paragraph. What it does, who uses it, what would be a disaster if it broke. Update this as it grows.] ## Money - No paid APIs or paid SaaS without asking me first. - Default to the cheapest model that can do the job. - If a free, self-hostable option exists, tell me about it before recommending a subscription. ``` That last section is not a small thing. Left alone, an agent will happily recommend a $99/month service to solve a problem a free tool solves in ten minutes. Put the constraint in the file and it stops happening. ## The permission problem Out of the box, the agent asks before running commands. Good. But it asks about *everything*, including reading a file and listing a folder, and after the fortieth prompt you are clicking approve on autopilot without reading. Now the safety check is worse than useless — it's giving you a false sense that you're reviewing things you aren't. **Figure: Where to draw the permission line** The answer is not to disable permissions. It's to draw the line in the right place: | Let it run freely | Always stop and ask | |---|---| | Reading files. Listing folders. Searching text. Checking status. Viewing logs. Running tests. Anything that **looks** but doesn't **touch**. | Deleting anything. Sending an email or a message. Pushing to a live site. Spending money. Changing DNS. Restarting a service people depend on. Anything you can't undo. | The principle in one line: **if it's reversible and it doesn't leave the building, let it run.** If it's permanent, outward-facing, or expensive, it stops and asks you. That's the same rule you'd give a new hire on their first week. In Claude Code, you set this with the `/permissions` command, which lets you add specific commands to an allowlist. Add the safe read-only ones as you hit them. Within a week the prompts drop to almost nothing, and the ones that remain are the ones you should actually be reading. > **Don't take the shortcut** > > There's a flag that turns off permission checks entirely. It is tempting and you should not use it on a server that matters. The whole point is that the prompts you still get are the ones worth stopping for. Turn them all off and you've just handed a stranger your keys and gone to bed. ## The habit that makes this compound Every time you correct the agent — "no, I told you not to use jargon," "no, always commit first," "no, we don't pay for scrapers" — **don't just say it. Put it in the file.** A correction you make in conversation is gone the moment the session ends. A correction you write into `CLAUDE.md` is permanent. My file is now a couple of pages long, and every line in it is a mistake I only had to fix once. That's what makes this thing get better over months instead of resetting to zero every morning. --- # OpenRouter, and keeping your costs sane. Chapter two was about you talking to an AI. This chapter is about the things you build talking to an AI — automatically, thousands of times, while you sleep. That's where the money goes if you're not careful, and it's entirely avoidable. ## What OpenRouter is **OpenRouter** is one account and one API key that reaches every major AI model — Claude, Gemini, GPT, Llama, DeepSeek, dozens more — through a single bill. Instead of signing up with five vendors, wrangling five keys and five invoices, you top up one balance and pick whichever model you want, per request, by changing one word in your code. Two reasons this matters, and the second is the real one. - **You can use a cheap model for cheap work.** Most of what your automations do is boring: sort this into a category, pull the date out of this email, write a two-line summary. Paying a frontier model to do that is like hiring a surgeon to open your mail. A small fast model does it just as well for a fraction of the cost. - **You can have several models check each other.** This is the trick that took me longest to find. Have one model write the thing, then hand it to a *different* model and ask it to find the flaws. Different models fail differently, so one catches what the other missed. The quality gain is real, and it's larger than the gain from just buying the biggest model and trusting it. > **The one paid service I recommend** > > I have a standing rule for my own business: **no paid APIs, ever.** No paid scrapers, no data vendors, no $200/month enrichment tools. Build it in-house or don't build it. OpenRouter is the single exception I've carved out, because AI models are the one thing you genuinely cannot self-host at quality. Everything else in this guide is free. ## Getting started - Sign up at [openrouter.ai](https://openrouter.ai) and add ten dollars. Not a hundred. Ten. - Go to Keys and create a key. It looks like `sk-or-v1-...`. - Put it in a file called `.env` on your server — never inside the code itself, and never in git. - Ask your agent: *"wire this project up to OpenRouter using the key in .env, and default to a cheap model."* Ten dollars will last you a shockingly long time if you follow the next two sections, and if it doesn't, you've learned something important for ten dollars. ## Rule one: cascade. Cheap first, expensive only when earned. Don't pick "the best model" and use it everywhere. Match the model to the job. My standing rule, which lives in my `CLAUDE.md` so I never have to repeat it: - **Start with a cheap, fast model** for anything routine — classifying, extracting, summarizing, first drafts, tidying data. These handle the overwhelming majority of real work. - **Step up to a mid-tier model** when the cheap one gets it wrong twice in a row. That's your signal, not a hunch. - **Reserve the frontier model** for the hard reasoning: architecture decisions, gnarly debugging, anything where being wrong is expensive. To make that concrete, here's what the Claude family costs. Prices are per *million* tokens — a token is roughly three-quarters of a word — split into what you send in and what it writes back out. Output is where the money is, always. | Model | Input / 1M | Output / 1M | Use it for | |---|---|---|---| | **Haiku 4.5** | $1.00 | $5.00 | The workhorse. Classify, extract, summarize, sort. Most of your volume. | | **Sonnet 5** | $3.00 | $15.00 | The balanced middle. Real writing, real code, most agent work. | | **Opus 4.8** | $5.00 | $25.00 | Hard reasoning, long autonomous jobs, when being right matters. | | **Fable 5** | $10.00 | $50.00 | The absolute ceiling. Reach for it deliberately, not by default. | **Figure: What each model costs to write a million tokens** Look at the spread: the top model costs **ten times** the cheap one on output. If you run everything through the expensive one out of laziness, you are lighting money on fire for no measurable gain on the easy 80% of your work. OpenRouter also carries very inexpensive models from other vendors — check the live prices on their models page, because they change often — and those are frequently the right choice for high-volume grunt work. > **The rule I actually use** > > Cheap model first. If it fails twice, step up. Never default to the expensive one just because it's there. This one habit is the difference between a $15 month and a $400 month, and I have had both. ## Rule two: one key per project This is the single most useful cost-control move and almost nobody does it. **Create a separate OpenRouter API key for every project.** Not one key for everything. One per thing. Why it matters: with one shared key, your dashboard shows a single number going up and you have no idea which project is responsible. You feel vaguely anxious about the bill and do nothing, because you can't act on a number you can't attribute. With one key per project, the dashboard shows you exactly which thing is eating the money — and now you can fix it, because you know where to look. OpenRouter lets you set a **spending limit on each individual key**. This is the part that turns anxiety into a solved problem: - Name each key after the project. `podcast-pipeline`, `lead-scorer`, `website-chat`. - Give each one a monthly limit slightly above what you expect it to cost. - When a key hits its limit, **that project stops** and nothing else is affected. Now a runaway loop in one experiment burns twenty dollars and stops, instead of quietly draining your whole balance overnight. That is not a hypothetical. That is the thing that happens to everybody once, and the key limit is why it only happens once. ## Rule three: watch it for the first week, then stop worrying When you build something new that calls a model, check the OpenRouter dashboard once a day for the first week. You're looking for one thing: *is the shape of the spending what I expected?* A pipeline you thought would cost pennies a day and is costing four dollars a day has a bug in it — usually it's being called far more often than you think, or you're sending it enormous amounts of unnecessary text every single time. Two things that quietly cost more than people expect: - **Sending the whole conversation history on every call.** Costs grow with every turn. If a chat feature gets expensive fast, this is almost always why. - **Retry loops with no ceiling.** Something fails, it retries, it fails, it retries. Always cap the retries. Always. After that first week, if the shape is right, stop watching. The key limit is your safety net. That's what it's for. ## Where the real cost is, though Honestly? For most people reading this, your AI bill is going to be small — twenty or thirty dollars a month, less than one SaaS subscription. The money you're actually bleeding is somewhere else entirely, and that's the next chapter. --- # Stop paying for software. Nearly every tool you subscribe to has a free, open-source twin that you can run on the server from chapter one, in about ten minutes, forever, for nothing. This is where the money actually is. ## The thing nobody tells you about GitHub GitHub is where the world's software lives in the open. Not just fragments — **entire, finished, production-quality applications**, given away free, that thousands of businesses run every day. Password managers. Analytics. Chat. Project boards. Time tracking. Bookmark managers. Monitoring. Newsletters. Forms. Databases. Whole categories of SaaS have a mature free equivalent sitting right there. Most people never look, because it feels like it must be harder than it is, or like free software must be worse. Sometimes it is worse. Very often it's *better*, because it isn't optimizing for a pricing tier that nudges you toward the upgrade. Here's the swap that made it click for me. I was looking at password management for a client. The hosted product is a fine business at a few dollars per user per month. The same company also gives away the server software, and there is a community version — Vaultwarden — that runs on a small VPS and does everything, unlimited users, unlimited everything. I installed it in about fifteen minutes. Cost: zero, forever. Same apps, same browser extensions, same security. That single afternoon paid for the server for the next several years. ## How to actually find them Three approaches, in order of how much I use them: - **Just ask your agent.** Literally: *"I pay $X/month for [tool]. Is there a self-hostable open-source alternative that would run on this server? Give me your honest recommendation, and tell me if I'd be downgrading."* That last clause matters — you want the truth, not a yes. - **The awesome-selfhosted list.** A famous, well-maintained GitHub list of essentially every self-hostable app in existence, organized by category. Search it for your category and you will find three options you'd never heard of. - **Search GitHub for "[the tool you pay for] alternative."** Crude, and it works constantly. ## How to judge one in ninety seconds You are about to run a stranger's software on your server. That deserves ninety seconds of attention. Open the GitHub page and check four things: | Check | What you want | Why | |---|---|---| | **Last commit** | Within the last few months | Abandoned software stops getting security fixes. This is the single most important signal. | | **Stars** | A few thousand or more | Rough proxy for "many people rely on this and problems get found." | | **Open issues** | Some, being replied to | Zero issues means nobody uses it. Hundreds ignored means nobody maintains it. | | **A Docker install** | Yes, ideally one file | Means installing it is one command instead of an afternoon. See below. | If those four look right, install it. If they don't, walk away — there's almost always another option in the same category. > **One real caution** > > Self-hosting means you are now the person responsible for updates and backups. Nobody is doing it for you. This is genuinely the trade-off, and it's the honest reason not everything should be self-hosted. Two mitigations: have your agent set up automatic backups the same day you install anything (ask for it explicitly — it will not volunteer), and check for updates on a schedule you actually keep. If a tool holds something you truly cannot lose and you know you won't maintain it, paying someone else is a legitimate, adult decision. Just make it on purpose. ## Docker, in one paragraph Docker is the reason all this is easy now. It packages an application together with everything it needs to run into one sealed box. You don't install the app and its database and its right version of some language runtime and pray they get along. You run one command and the box appears, working, isolated from everything else on your server. If you hate it, you delete the box and it's like it was never there. Practically, most projects hand you a file called `docker-compose.yml`, and installing them looks like this: ``` # grab the project git clone https://github.com/some/project.git cd project # start it docker compose up -d ``` That's the whole install for a shocking number of real, serious applications. You do not need to understand Docker deeply. You need to know it exists, prefer projects that offer it, and let your agent handle the details. ## What's actually worth running These are categories where the free version genuinely competes, based on what I run day to day. I'm deliberately not naming a single winner in each — that changes, and you should ask your agent for the current best option and why. - **Password manager.** Unlimited users, unlimited vaults, real browser extensions and phone apps. Replaces a per-seat subscription outright. Start here — it's the highest value-to-effort ratio of anything on this list. - **Website analytics.** Lightweight, privacy-respecting, no cookie banner needed, and you own the data. Replaces the paid analytics tier most small sites don't need. - **Uptime monitoring.** Pings your sites every minute and messages you the moment one goes down. This is the tool that has saved me the most embarrassment, and it costs nothing. - **Team chat.** A full self-hosted chat platform with mobile push. This is where every alert from every tool I run lands, in one place, on my phone. Wiring your alerts into a chat channel instead of email is a small change with an outsized effect — email alerts get ignored within a week. - **Project boards and task tracking.** Kanban boards, task lists, the works. Free and good. - **Time tracking, bookmarks, read-it-later, notes.** All of it. All free. All fine. - **Automation glue.** Tools that connect A to B when C happens — the self-hosted equivalent of the automation SaaS everyone pays for. Add them one at a time. Get one working, use it for a week, then add the next. The failure mode here is installing nine things in a weekend, understanding none of them, and abandoning all of them. **Figure: Monthly SaaS subscriptions versus one self-hosted server** > **Do the math once** > > Add up what you currently pay, monthly, for tools that are on that list. For most small businesses it lands somewhere between $80 and $300 a month. Now compare that to the $6 server. That gap is the entire argument, and it's why this chapter exists. --- # Think like a builder. Everything up to here was mechanical. This chapter is the one that actually changes your output, and it has nothing to do with technology. ## The constraint was never the code Here's what I noticed after about six months of this. My ideas hadn't gotten better. My taste hadn't improved. What changed is that I stopped **pre-shrinking** them. You do this constantly and you don't notice. An idea shows up — "we should have a thing that watches all the local event calendars and tells our guests what's on this week" — and before it's even finished forming, some quiet part of your brain has already priced it, decided it's a six-month engineering project, and filed it under Someday. The idea never even reaches the page. You are not choosing not to build it. You are deciding it's unbuildable, silently, in about a second and a half, and moving on. That specific example is a thing I built. It scrapes 175-odd local sources, sorts what it finds, and feeds a hotel's staff and guests a daily readout of what's happening in the area. Old me would have priced it at three months and a developer. It was not that. **Figure: Pre-shrinking an idea versus pricing it** **The work now is noticing the moment you shrink an idea, and not doing it.** That's the skill. Everything else in this guide is logistics in service of that one habit. ## Ask "what would this take?" before "can I do this?" These sound similar and they are completely different questions. *Can I do this?* is a question about you, and you will answer it with your insecurities. *What would this take?* is a question about the work, and it has an actual answer — usually a much smaller one than you feared. So when the idea shows up, don't evaluate it. Describe it. Out loud, to the agent, in the messiest terms you like: > **The prompt I use constantly** > > *"I want to describe an idea. Don't build anything yet. Tell me what it would actually take: what pieces would need to exist, roughly how hard each one is, where the real risk is, and whether there's an existing free tool that does most of it already. Be honest if it's a bad idea."* Half the time the answer is "that's four hours." A quarter of the time it's "that already exists, here it is, install it." And the last quarter it's genuinely hard — in which case you've learned that in ten minutes instead of never. Every one of those outcomes is a win, and you got it for the cost of asking. ## Build the ugly version first, and use it The instinct is to plan. Resist it. Build the ugliest possible version of the thing this week, then use it yourself, immediately. Not because "ship fast" is a slogan, but because **the ugly version tells you what the idea actually was.** You will discover within three days of real use that half of what you planned is worthless and one thing you never thought of is the whole point. You cannot learn that in a planning document. Nobody can. It is only available on the other side of using the thing. Every tool I run that I actually care about started as something embarrassing that solved one narrow problem for exactly one person, me, and grew from there. Every ambitious thing I tried to design properly up front is dead. ## Follow the annoyance You want a reliable source of good ideas? Stop looking for ideas. Track your annoyances. Every time you do something manually for the second time — copying numbers between two places, checking whether the site's still up, retyping the same email, digging through a folder for the same file — **write it down.** Don't fix it yet. Just log it. Keep the list for two weeks. What you'll have at the end is a list of things that are, by definition, worth automating: they're real (you actually do them), they're recurring (you did them twice), and they annoy you (so you'll actually use the fix). That's a better product roadmap than anything you'd invent by brainstorming, and it costs you nothing but attention. Then work the list, one at a time, smallest first. The compounding is the point: every annoyance you kill is time back, permanently, forever, and it frees you to notice the next one. ## The thing that keeps people stuck I'll be direct, because I think this is the actual barrier and everything else is a proxy for it. Most people don't build because they've decided, somewhere below the level of conscious thought, that **building is for a category of person they aren't in.** Engineers build. Technical people build. You run the business, or you do the marketing, or you manage the shop, and building is something you buy from someone else. That was true. For decades it was completely true, and it is not true anymore, and most people haven't updated. The thing that has changed is not that AI writes code. It's that **the ability to describe what you want clearly is now sufficient** — and that ability is what you have been developing your entire working life, in every brief you've written and every job you've delegated and every time you've explained to somebody what "good" looks like. You already have the hard skill. You've been told, for twenty years, that it wasn't the one that counted. It's the one that counts now. ## Where to start, today - **Get the server.** Six dollars. Do it before you finish talking yourself out of it. [Chapter one.](/build/server/) - **Put the agent on it and let it teach you** for an hour. Ask it to explain everything. [Chapter two.](/build/claude-code/) - **Write your `CLAUDE.md`** — who you are, how you need to be talked to. [Chapter three.](/build/rules/) - **Kill one subscription** by self-hosting its free twin. Feel what that feels like. [Chapter five.](/build/self-hosting/) - **Start the annoyance list.** Two weeks. Then build the top one. That's it. That's the whole thing. I'm about a year into it and I still don't write code, and I've stopped noticing that I don't.