Building a TTRPG Website using 1% of My Power
Website Philosophy
When you first become an engineer, you may have the same perception of software engineering most people have, which is that "software engineering is about typing in code". This misconception has made many people miserable, because there are robots that write code now.1
Even before the robots, engineering was always about solving practical problems. An electrical engineer solves electrical problems by drafting designs and instructions for electricians to implement. Before you write a line of code, solving problems involves talking to people to find out what the problems are, something mediocre engineers hate to do. Many people drop out of the profession or stay in their rank for years once they hit a mid-level rank after a couple of years because in order to advance upward, they're now required to talk to people and be good at it. It's called "stakeholder alignment". I'm better than "mediocre", and I love talking to people, so I decided to get a team together to solve this problem I had for a while.
RPGStuck is a fan-made Homestuck TTRPG I have spent 11 years engaging with in some fashion, from player to game-master to community manager. In that time, I went from angsty middle-schooler to less angsty software engineer. In case you forgot, Homestuck is an online comic about four kids who play a world-ending video game. The setting lends itself nicely to a tabletop game because of its broad-spanning goal-oriented plot, just enough lore to spark the imagination while remaining sparse enough on the details to allow game-masters to make up information on the fly, and themes of "growing up" that lend great to self-insertion if you're a teenager, or writing a fantasy Bildungsroman if you're past that. Homestuck itself was experiencing a revival from the top-down after years of silence, including a brand new website with a shop, and a revival of the old community forum built on custom software. There haven't been many good non-bloated forum packages, so they chose to make their own.
Seeing this as an engineer, of course I wanted in on the website action for RPGStuck itself. We host our rulebooks on Google Docs because that's the quickest way to draft and share text, and it kind of sucked after a while. If you make a document too large, it doesn't load the entire thing and will crash your computer, so the rulebook was split up into 10 different documents and the character sheet. Searching across all of these at once was impossible, some sections were duplicated for convenience of the reader but would then have to be updated and reconciled later, and any formatting beyond the basics was a non-starter. I'm trying to move away from SaaS platforms to host information. For example, you're reading this blog post on a static site hosted by a VPS. It's a collection of Markdown files with some HTML templates to glue them together. If this particular VPS goes down, I just upload the files elsewhere and change the DNS accordingly so the domain name takes you there instead.
I am very lucky to have friends who are as great and as skilled as I am. There's Reynard, or Reyn, who has product management experience in the real world and agreed to use 1% of her power to product-manage a tabletop game website. In engineering tradition, I just kind of rolled with it without sticking 100% to her plan, but it was helpful to have design criteria as we went along. On the design front, we have Bell, who made a banner for our Discord server a while back, and Kitty, a packaging designer who contributed some SVGs. I tried to drag in Spencer as well for his prior contributions including a whole trailer from 2019, but he was too busy playing his fiddle in the forest.
Once you gather the stakeholders, you communicate. We started off with the requirements.
- The RPGStuck site should be quick to load, quick to deploy, and nothing should ever go wrong. This is why we used a static site builder, Hugo, with a custom theme that has lightweight HTML/CSS and minimal JavaScript.
- I should never have to worry about deployment or security. Updates should roll out as quickly and easily as possible, and we should never store sensitive information on the website. This is why I picked Netlify to deploy the static site. Because it's a static site, there's no backend, which means no security, and I assume that I'm completely fine with anything in the repository being public for the world to see.
- The site should be easy to edit for nontechnical people. Content is stored primarily in Markdown, and rendered using extensible static site page templates that don't need to be edited often.
- The site should be art-forward, not tech-forward. It's a cool demo, but the coolness of the demo is in the minimalism, because the website is a space for our community's art and our system. No AI, including LLMs and diffusion image models, should be used for any of the art or writing on the website.
Again, software engineering isn't about typing in code. I use LLMs2 at my job to build production software, of course I'm going to use LLMs to write HTML and CSS. Don't look at me with a straight face and tell me you love CSS. Because results render in real time and the site's so easy to build, development was a real-time, collaborative, fun process for non-technical people. I sometimes popped into voice chats and shared my screen just to show people what I was doing, or asked an LLM for HTML template edits and sent screenshots as people asked me questions and gave me feedback. This was way more fun and productive than going into a hole for months and coming out with some crazy blob and getting frustrated when other people didn't like it just the way it is. It's called "Agile development"; companies pretend they do it, but I was doing it for real.
Building the Thing
As far as I knew, none of us knew how to use Figma. I tried it and it scared me. I wanted to use it to look professional and develop "professional skills" for the team, but that was a non-starter. We used FigJam, Figma's adorable little cousin, instead to design the front page. I had a basic idea of what I wanted, so I just made some boxes and typed up some copy and put it on the board.
That was back in August 2025. That was our front page for a while; just a front page with a link to our Discord and Google Docs rules page with a carousel at the bottom to showcase art from the community. The carousel was hardest part to code, since it had to be done entirely with HTML and CSS and made into a Hugo component, but it was easier than expected, because once you have the requirements and designs, you put them together into a coherent system and AI does the implementation. Trust me, I looked and couldn't find one that matched what I wanted, even though everyone posts Hugo components.
We launched the website on the same day as the Homestuck pilot premiere, and I made sure to give a shoutout to the team because this was a group effort. The secret, hidden, occult purpose of announcements like these is to also inspire other people to make their own projects with the aspiration of their own 15 minutes of celebration. This releases more art into the world, which is a net good. Then I remembered I have to stop philosophizing and follow through on some of the promises I made in the announcement, so I set up a weekly meeting with the team to discuss what to do next.
The obvious next step was rules. The problem is nobody made a good TTRPG rules website yet. Everything was either ad-infested or straight out of 1997. There were a couple good exceptions Kitty and Reyn found, so I hunted through those and tried to pick out what I liked. The better options used static site builders, confirming we took the right direction. They often used formatting that was very simple and searchable, with sidebars and search bars for ease of use. Some used a wiki format, but that would introduce a backend, which would introduce potential security surfaces I didn't want to deal with. What if a vandal somehow hacks into the site and gets admin rights? Unlikely, but I didn't want to update the software. You don't have to update HTML until the browser itself breaks it, and if you stick to the standards, you'll probably be fine.
Another source of inspiration was tech documentation. Tech people had this figured out for decades already, because before AI they were staring at docs all day and had to make them look pretty in order to tolerate their own lives and each other. Now they're staring at AI and docs. Looking at what other sites already had, we knew we wanted a sidebar with a search function. I didn't know how to make a search bar for a static site, so I deferred it. We had to decide what the rules would actually look like, so we drew out what an example rules page would look like in FigJam next to our front page.
We soon realized we had little idea how to organize the primer, and that the more we divide the primer, the more pages a user would have to click through to find what they're looking for, or scroll through on the sidebar. This means we need to implement back-and-forth nav between pages, which again, requires a proper schema. We wrote out some drafts, but nothing felt inspiring to me, and I knew I would have to hunt through the Markdown files and implement it myself.
We dragged our head developer, Merc, into a voice call, and didn't come up with any actionable conclusions. It was left up to me, and I didn't feel up to it at the time. We were all busy, so the project was left in this half-finished state at the end of October 2025. I was fine with the front page for now; at least we staked our independence.
Sprint to the Finish
One day in March 2026, Reyn posts a .zip file of the primer divided into formatted Markdown sections with some links between them, along with a Figma document of a formatted example RPGStuck rules page.
It didn't match our initial sketches exactly, but it matched the product requirements doc. It turned out Reyn knew how to use Figma this whole time and I never asked. Since we were back on the road, I copied and pasted the divvied-up primer into the contents section, and had an LLM write a script that generates frontmatter so the new pages would all render properly. This script alone saved me about 25 minutes of copying and pasting that would probably throw me off the project again.
I then realized could download Google Docs as Markdown files. Platform lock-in was solved if I could teach our lead dev how to edit markdown files without getting scared. It turns out asking non-technical people to submit PRs to a Github repo to edit text isn't very user-friendly. There was still a lot of reformatting because each specibus, psionic, and pillar had to be given its own page, but again, there were bespoke Python scripts generated by LLMs for this, so it wasn't manual, nor was an AI reading or rewriting the ruleset. I wanted this done as cleanly and deterministically as possible, and it made sense to craft bespoke tools for the job, which saved me another couple hours of Ctrl+X Ctrl+C Ctrl+V.
I asked my AI agent how to implement breadcrumbs and a sidebar, and once again, Hugo's static site functionality made this really easy. According to the chatlogs from when I did it, it was done in 8 minutes, between me "calling it a night" and saying "nevermind, we have breadcrumbs and a sidebar". That would have been a good few hours to figure out otherwise.
We had to handle rendering entire sections of the rules as one page as an alternate option to the current heavily-divided schema. For example, if people wanted to print out all of the weapons for later, they'd have to click on each individual page. I would later find out that Hugo's templating engine also makes this very easy, but I put it off until later. We did a soft launch of the Rules section on April Fools' Day as per tradition, even though we were still missing major components, just to get people used to clicking around a website to read tabletop game rules, and to collect very early feedback.
I made a list of todos in April for next steps on the site, and didn't get to any of them until July because I was too busy doing literally anything else. I was busy with my job in real life that actually pays me, and I wanted to put my side-project energy into something else, such as the Paradox Engine. I had other ideas I needed to solidify into reality. Then, I needed a break. After the latest Paradox Engine blogposts were written, I wanted a mental reset where I check off every side-project I was putting off until "later". Now is later. It was time.
Everything that remained, including reorganizing the file structure and porting over the Bestiary, a list of every monster designed for the game with their stats and descriptions, was done in two more nights. The bestiary wasn't like the other files, which were Google Docs that were fundamentally convertible into Markdown; the canonical copy of the Bestiary is a Google Sheet, arcanely formatted even by spreadsheet standards for decorative purposes. My best option was to export them as CSV files. I looked up some bash commands to organize the files at first, just to get back in the website-building mindset. How do I delete the first N characters of all filenames starting with this letter? Ooh. How do I remove parentheses and commas from the filenames? Ahh. With a little mv prefix-*.csv folder magic, I was back on track.
I then had a local AI model on a mini-computer on my desk churn through the CSV files, because Sam Altman can't get his hands on these numbers and I wanted the bragging rights. If the AI bubble spontaneously combusts and every company simultaneously decides it isn't worth it to give you tokens in the cloud, what am I left with that I can run for the same cost of electricity that it'd take to play Fortnite on the same computer, privately on my desk? Left to its own devices, a lot, apparently. It wrote an 800-line Python script that took these CSV files, detected each monster within each file along with the general format of the spreadsheet, and spat out structured Markdown files with proper frontmatter for every single monster in the book. This is something that would have taken me multiple hours to write manually, and multiple days to do manually. Again, this is another example of something that simply would not have been done without an LLM.
It was time to implement search. I was so scared of this at first, I typed "how to make a static site searchbar" into Google and then my AI agent because I had no idea what to do next. It turns out this is a solved problem. Pagefind exists for this purpose. I set it up with a short build script, and after some back-and-forth with the CSS, we had a search bar that thematically fit with the site; not too fancy, but still very reactive and usable.
I don't like scheduling launch dates. The only date I like scheduling launches for is April Fools' Day, because it's ironic to launch anything real on the one day whre everyone is joking. I launched this website the minute I could, pinged everyone in a 2,000 member Discord server in the middle of a fake public conversation in the announcements channel, and set up a suggestion thread so people can tell me feedback and I can improve this as quickly as possible.
That was a lot of fun. There's more stuff left to do. Remember when I said the purpose of the first announcement was to inspire people reading? That's also the purpose of this blogpost. You should build a website too. It's fun, it can be easy, and you will learn a lot. The web deserves more independent art away from spaces controlled by big tech. You can play a part in this. Go make a website!
Appendix: Inspiration
Appendix: Technology
We tried telling the robots to make art, and it turns out that was a dumb idea. They're great at writing code though.
Opencode, if you're curious.