How this whole site got built, step by step. Steal the approach, apply it to your own ideas.
The loop that built this site is simple. I brainstormed an idea with Claude in chat. I asked it to build me a concept. Then I spoke with it, fine-tuning the product and the way I wanted it to feel. You phrase things like an engineer talking to another engineer: "I want the user to experience X, Y, and Z." That changes the output more than any clever prompt.
You can see the result of that loop all over this site. At one point I told Claude I didn't want this to feel like a corporate training portal and asked what we could add. I mentioned I mess around with Suno for music. Claude suggested a music player to tie it together. That is how ContractingFM ended up on the homepage. I was engineering a site and thinking about what an outsider shows up for. It is genuinely addicting.
Talk through the idea with the model. Let it poke holes. Let it suggest stuff you didn't ask for.
Tell it to actually build a working version. Crude is fine. You want something to react to.
Use the prototype. Tell the model what feels off. Repeat until it clicks.
Once you've got a landing page or a tool, you have to ship it so other humans can actually use it. Claude will lay out your options (GitHub Pages, Vercel, Netlify, and a few others) and walk you through picking one. I landed on GitHub. I went to github.com, got completely lost, and then leaned on Claude's browser feature that can drive Google Chrome for you.
I watched it upload my pages into GitHub the first couple of times. Now I do it without AI's help, because the browser takeover is what taught me the process. If you don't want a model driving your browser, feed it screenshots instead. Use your computer's snipping tool, grab a few shots, paste them in, and Claude will walk you through each click.
Once the landing page was live, the question became features. First thought: training. I put a bunch of empty placeholders on a training page and filled them in over time. Claude generated the code. I provided the text and the edits. That pattern, skeleton first and content-second, has held up well as the site has grown.
With training in place, the question shifted. What else could I build? Tools. What had I actually wanted over 14 years of contracting that nobody ever gave me? I used to try to build the perfect combined synopsis/solicitation, but it always went stale within a year of FAR changes. So I built one here, walked down the FAR to find the compliance touchpoints, and dumbed it down for a brand-new CO so it would line up with the training on this same site. Maintaining that becomes part of the fun instead of a chore.
Then I asked Claude how to buy a domain and transfer the site over. I bought KTHQ, followed the instructions step by step, and that is why the URL you're reading this on is kthq.org. Beyond the Claude subscription and seven dollars for the domain, this didn't really cost anything.
I could drop a step-by-step guide here. The better move is to get into it yourself. Look at the small inconveniences in your day and ask whether AI can help fix them. It does not have to be work. A digital cookbook. A calorie-counter that actually matches how you eat. Whatever you keep wishing existed. You learn faster building three weird little things than reading about building one good one.
A lot of public sites and services expose what's called an API, which is basically a pipe your site can pull from. Point Claude at one of those pipes and the data maintains itself. You build the frame once and the content updates on its own. No cron jobs, no overnight scripts, no "I forgot to update the spreadsheet" moments. The page just shows you whatever is true right now.
In fact, I'm going to try one while writing this. One prompt. Here's what I handed Claude:
I'll time it, and I'll let you know how it goes, dear reader.
Claude wrote the whole page in one shot. It pulls live from the USAspending.gov public API on every page load. No backend, no database, no cron job. Just a static HTML file and two fetch calls. It shows current-FY contract obligations, the same window from last FY for comparison, a monthly trend chart, and a top-10 awarding agencies table.
Go poke it. Refresh it in a week and you'll see new numbers.
That is the whole point of pairing Claude with an API. You spent one session and got a page that will keep working past the day you built it. The underlying data changes, the page updates, you did nothing extra.
Eight minutes. Eight minutes to build a somewhat useful tool that you could dig down into much deeper if you wanted. I could narrow it down to the Air Force in particular, add product and service code breakdowns, layer in obligation burn rates, or pull in prime-contractor concentration. SAM.gov also has a public API. I guarantee some people in industry are already using it to develop leads for work. If you are from industry and you're reading this, you're welcome for the advice. Buy me a coffee. My Air Force enlistment ends in 2032 if you're hiring.
This is surface-level coding, too. My knowledge is limited to presenting information I already know. That's it. Imagine handing a problem like this to actual software developers who know how to stand up servers, networks, and real databases. You very well could be the person who delivers something that changes the industry. Go try.