Designing for Pirate Borg (Part 3/3)
#022 - How we could have saved 100s of hours (Part II: Process, Time & Tools)
We thought we had time. When we started working on Ravaged by Storms, time felt abundant. Not infinite, but generous. The manuscript existed, the core ideas were clear. We weren’t rushing toward a hard external deadline yet. Compared to later phases, everything still felt flexible. That early sense of breathing room shaped a lot of our decisions, for better and worse.
In Part I: Visual Design & Layout, we focused on what ended up on the page: how Pirate Borg’s constraints shaped our layout, why restraint mattered more than loudness, and why readability always had to win. What we didn’t address there is why so many of those decisions became harder than they needed to be.
Reality, of course, didn’t care about our internal schedule. Life happened. People got sick. An apartment burned down (for real). Energy fluctuated. Tasks took longer than expected—especially the ones we had mentally filed under “almost done.” The project didn’t lose time in dramatic crashes, but in small, almost invisible increments. A day here, a week there. Enough to turn early confidence into late pressure.
You rarely read honest process reports about this phase because it’s uncomfortable. But if this article is meant to be useful, it has to start here. Most of the mistakes we made later didn’t begin with bad decisions. They began with the assumption that we still had time to fix them later.
The Cover: Six Versions, One Lesson
The cover of Ravaged by Storms went through six full iterations. Not minor tweaks. Six fundamentally different versions. Each one explored a different idea of what the book should signal at first glance.
The first two versions never made it beyond rough paper scribbles. They showed the Blight Revenant fighting the Coatl. But the Coatl wasn’t just another powerful entity, it was the central figure everything revolved around. If anything belonged on the cover, it had to be the Coatl itself.
Version three leaned into that realization. The Coatl was placed inside the Lifeless City. SabrinaSeNina had already started constructing the image with the intention of roughing it up later. But partway through, another problem became obvious: the image was too complex. Too much architecture. A cover isn’t a spread. It doesn’t get time. It has to work immediately.
That insight led to version four. The focus shifted to the storms themselves. A pirate ship caught in violent weather felt like a strong, readable symbol. Sabrina pushed this version fairly far before we felt it was too generic. It could have belonged to almost any pirate-themed product. Attempts to integrate the Coatl into this version didn’t solve the problem.
Instead of showing the Coatl in full again, Sabrina zoomed in on a single detail: one eye, reflecting the storm. Version five started with the idea of turning the serpent’s body into an ornamental frame across front and back cover. But once the illustration was placed into the layout file, it became obvious that the oversized eye was far more powerful than the original plan. So it stayed.
The final cover didn’t emerge from executing the concept as intended, but from recognizing that the accidental focal point did the job better. The storm in the eye communicates threat, scale, and myth instantly, without explanation. By the way: the ship reflected in the eye is based on the illustration from version four. Drawing that generic pirate ship wasn’t a waste of time, after all.
Invisible Work Is Still Work
One of the biggest time sinks in Ravaged by Storms was that we spent a lot of time in intermediate states that felt like progress, but weren’t stable enough to survive later changes. This wasn’t just about illustration. In fact, for long stretches, illustration wasn’t even the main driver.
After an initial phase with a few strong illustrations, a large portion of the work shifted into layout. Many spreads received a basic structure early on. Text was placed, columns aligned, etc.. From the outside, this created a strong sense of forward motion.
The problem was that much of this work happened before the underlying content was actually stable. Playtests hadn’t happened yet. Text was still changing. New material was added. Some sections expanded, others were rewritten. And because layout work is highly sensitive to text length, hierarchy, and emphasis, many of those seemingly finished spreads had to be reopened — sometimes multiple times.
In practice, a work-in-progress spread does not need perfect typography. It only needs enough structure to show where text, images, and tables will eventually sit. Headlines should be clear, hierarchy visible, and basic spacing readable, but it does not need to be beautiful yet. Time spent perfecting individual spreads before the red thread of the whole book was fully locked in.
LEARNINGS
Lock structure before refining spreads.
Headlines, purpose, and the red thread of each spread need to be clear early. Perfecting individual pages before that leads to rework.Make illustration scribbles early and concrete.
Rough but clear art scribbles help catch misunderstandings early, allow text changes sooner, and make playtests possible before anything is polished.Playtest before polish.
Early, rough versions are cheaper to change than clean layouts. Waiting too long to playtest turns layout work into invisible waste.
Why Illustrations Are Psychologically Deceptive
Illustrations added another layer to this problem. Early in the project, Sabrina did produce a handful of strong, defining visuals. Those pieces helped set tone and direction and felt like real progress. But after that initial phase, illustration largely paused. For a long stretch, most of the work shifted into layout.
This is where the illusion deepened. Because many spreads received a basic layout early on, the project continued to look as if it was moving forward. Those laid out paged created a stronger sense of progress than a single illustration would have. The result was that many illustrations were pushed further and further back in the schedule. They accumulated quietly until well after the Kickstarter phase. On the surface, illustration work was “still coming.” In reality, it created a massive, invisible workload waiting at the end of the process.
And illustration work is expensive in a way layout is not. Before a single finished image exists, hours disappear into thinking, sketching, testing compositions, and discarding approaches. Much of that effort never shows up in the final book. Depending on complexity, a single illustration took 20 to 40 hours, including thinking time, not just drawing. In hindsight, the problem was that layout progress masked how much illustration work was still outstanding.
What had felt like steady advancement was, in part, time being invested in intermediate states, while a large, unavoidable block of work silently grew in the background. Next time, we will distribute the work much more evenly over the entire project period.
LEARNINGS
Layout can fake progress, illustration can’t.
Layout produces fast, visible results. That makes it psychologically rewarding, but also dangerous: it creates the illusion of momentum while postponing the most time-intensive work.Illustrations are not “something you do later.”
High-quality illustrations are the single biggest time sink in the project. Treating them as a flexible end-phase task guarantees late pressure and hidden overload.Complex, iconic visuals belong at the front of the schedule.
The images that define tone, sell the project, and set quality expectations need to happen early, not “when I have more time,” but precisely to test whether the timeline is realistic.
Stretch Goals, Scope, and Lock-In Decisions
Another lesson only became visible once the project was already well underway: some decisions need to be locked earlier than you think. Stretch goals are a good example.
During the early phase of the Kickstarter campaign, the focus was naturally on the core book. Stretch goals felt like something flexible — bonuses that could be figured out once the campaign gained momentum. That mindset can quietly create structural problems for production.
Every stretch goal is a new piece of scope. Therefore, we chose stretch goals that wouldn’t affect the timline: mostly product quality upgrades or digital bonus content that could be produced after the main products. So far, so good.
Nevertheless, we didn’t know just how much work and pressure we would face after the Kickstarter. We had expected to be able to produce the additional stretch goals at our leisure, but in the end, they were just added on top of many other things. We could (and should) have, for example, involved external contributors for the additional material. But those possibilities depend on something simple: knowing early what you are committing to.
One related issue sat even deeper in the project structure: how the text itself evolved during writing. We did start with a page plan and a rough idea of what the entire book would contain. But that plan was intentionally loose. Major elements of the adventure were added gradually during the middle and later writing phases. That approach felt natural at the time.
Creatively, that flexibility was productive. From a production perspective, however, it created friction. Because many structural elements were still evolving, entire spreads had to be rewritten. In some cases even the page plan itself had to shift halfway through the project.
For larger books, a more structured writing process helps stabilize the foundation before layout begins. One useful approach is to separate ideation, outlining, and writing into distinct phases as taught by Luke Gearing.
Instead of starting with a blank document, the first step is to generate a large number of rough ideas at a very high level — often in a spreadsheet. Each entry might contain only the core components: a central concept and a one-line pitch.
In the next phase, these rough ideas are expanded into sketches. Each concept is turned into a structured outline where the important elements are worked out: locations, conflicts, NPCs, and the core situation the players will encounter. The point is not to produce polished prose, but to clarify the idea itself.
Only after this structural groundwork exists does the actual writing begin. Because the ideas are already defined, the writing phase can focus entirely on expression instead of discovery. Finally, revision happens as a separate step once all sections exist.
Not every detail needs to be finalized at that stage. But the structural skeleton of the project should already exist: what belongs where, what each section is meant to do, and how the different parts of the book reinforce each other. Locking key structural decisions early keeps the rest of the production pipeline stable. Leaving them open for too long means that every new decision arrives when the project has already become harder to move.
LEARNINGS
Lock the core structural elements of the book early.
Define the key components of your project first. Once those elements are mapped and connected, the writing of individual sections becomes much easier to place within the whole.Lock scope earlier than feels comfortable.
Stretch goals and structural additions become dramatically more expensive once layout and illustration work has begun.Creative freedom works best inside a stable structure.
Leaving everything open may feel productive early on, but it often multiplies rework later.
The Trailer: 100 Hours for (Too) Little Return
One of the most time-consuming side projects around Ravaged by Storms wasn’t part of the book at all. It was the trailer.
At the time, producing a short animated trailer for the Kickstarter campaign felt like a good idea. Video is a powerful format for social media, it communicates atmosphere quickly, and it can help a project stand out during a crowdfunding campaign. In theory, it made sense.
In practice, it consumed far more time than expected. The core idea behind the trailer was a parallax animation. Different layers of the illustration would move at different speeds to create depth and motion. The concept looked simple enough on paper. But it required something the original illustrations were never designed for: clear separation between foreground, midground, and background elements.
Of course, the illustrations were created in different layers from the outset, separated by color, for example. However, this did not meet the requirements of the animation, which requires separation according to moving elements. To make the animation work, elements had to be cut out, redrawn, extended, and rebuilt so they could move independently. By the time the trailer was finished, roughly 100 hours had gone into producing a relatively short video.
In hindsight, the time investment simply wasn’t proportional to the benefit. Looking back, this is one of the clearest areas where we would make a different decision next time: either outsource the work, plan it from the start, or not do it at all.
LEARNINGS
Side projects can quietly become major time sinks.
If something is not part of the core product, its time investment must be justified carefully.Animation requires assets prepared for animation.
Illustrations created for print are rarely structured in a way that supports motion.Know when to outsource specialized work.
Trying to learn a new production discipline in the middle of a project is rarely efficient.
Tools Matter More Than You Think
Another lesson we learned the hard way had to do with tools. At the beginning of the project, the choice seemed straightforward. Sabrina had been working with Affinity Publisher and was comfortable with it. The software was affordable, capable, and a viable alternative to Adobe InDesign.
The early layout phases went smoothly. Nothing suggested that the tool would become a problem later. The issues only became visible when the project approached the production stage.
Certain PDF exports created unexpected results. In some cases, text elements that should have remained vector-based were rasterized during export. That might not sound dramatic at first, but rasterized text can become blurry or inconsistent when printed, especially in professional printing workflows. And a book intended for physical printing cannot tolerate uncertainty about how the final file behaves.
Trying to troubleshoot the issue consumed time and energy we did not really have. And the most uncomfortable realization was this: by the time the problem became obvious, the entire book was already built in the software.
Switching tools that late meant reopening every file, rebuilding parts of the layout, and adapting the workflow to a new environment. In the end, the project moved to InDesign. Looking back, the mistake wasn’t choosing Affinity. The mistake was not stress-testing the entire production pipeline early enough.
LEARNINGS
DON’T gamble with production tools.
Switching software late in a project multiplies work across the entire book.DO test your full pipeline early.
Export realistic files, check how printers handle them, and make sure nothing breaks before the project grows large.
Your Project
Projects like this are messy. They rarely fail because of one catastrophic mistake. More often, they slow down because of dozens of small decisions that seemed harmless at the time. Some of those decisions we would make differently today.
If you’ve designed a module, run a crowdfunding campaign, or wrestled with layout, art, and deadlines yourself, you’ve probably run into similar problems.
Which part of the process surprised you the most?
Where did you lose the most time?
And what mistakes would you warn other designers about?
We’d genuinely love to hear your experiences.
“From pebble to monolith - your journey matters. The Golems have spoken.”
Alexander and Sabrina from Golem Productions





Something that I've been learning about project management is the final phase that many people gloss over - the review of the project. This was a great, informative and honest look at an ambitious project. The pdfs are excellent and I'm looking forward to seeing the revamped previous adventures (which were also excellent as is but with added pages and more art it's only gonna get better).
I've seen a lot of the Stretch goals in projects becoming more of a burden then creators ever thought they would be. I think most people go into them with the idea of "oh this would be cool to do but not needed" mindset. That is why I think most creators get caught off guard with the scope and time consumption they become.
While I have never attempted a project the size of this one, I have noticed Affinity has given me some weird/funky export results. It's unfortunate you guys had to change mid project, I'm sure that must have been a kick in the gut. Again, everything looks wonderful and I can't wait to have the print version on my shelf. Congrats on a successful kickstarter. It seems like you guys are jumping back into the fire with another one. Let me know if you need play testers, I've become the Pirate Borg GM for the OSR group I'm in and will be running a lot of games in several up-coming local cons this year, so happy to help.
I'm reading a fascinating book called "How Big Projects Get Done." So many examples of projects that go off the rails. And a couple that didn't. I'm trying to figure out how to appy the "think slow, act fast" principles to my job. It does seem like the issues you're writing about would map well.