I Wrote 35 Production Engineering Resources in 18 Months. Here Is What Crossing 1,800 Sales Taught Me About What Senior Engineers Actually Buy.
Not theory. The actual catalog data. Which titles sold, which sat, what the highest-paying customers all had in common, and the pattern I refused to see for the first six months.
When I started writing production engineering guides on Gumroad in early 2025, I had three years of backend experience, a laptop, and a clear assumption.
The assumption was that engineers would pay for the technologies they were currently struggling with. Postgres struggles, buy a Postgres guide. Kubernetes struggles, buy a Kubernetes guide. Spring Boot struggles, buy a Spring Boot guide. I built the catalog on this assumption. Eleven “Under Pressure” guides. Each one focused, technical, priced cheaply.
I sold a lot of them. Linux Under Pressure, 44 sales. Docker Under Pressure, 52 sales. Kubernetes Under Pressure, 47 sales. Redis Under Pressure, 54 sales. Postgres Under Pressure, 60 sales. The volume was real. The revenue per resource was not. The average revenue across the eleven guides was under $30 per guide despite tens of customers per title. Most engineers had used the pay-what-you-want option, paid $0 to $3, downloaded the guide, and left.
I spent six months telling myself this was the price of broad distribution. It was not. It was the price of selling the wrong thing.
The pattern I had been refusing to see was in the data the whole time, and it took me eighteen months and roughly 1,800 sales across 35 resources to actually read it. This article is that pattern.
I am writing it because I think the assumption I made is the same assumption most engineers make about what to learn next, and the data I have collected is direct evidence about what actually moves the needle for senior backend engineers in 2026.
The setup
Thirty-five resources written between January 2025 and August 2026. Roughly 1,800 paid sales across the catalog. Revenue distributed extremely unevenly across the catalog. Average prices ranging from $10 single guides to $149 bundles, with a few products at $39 each.
The customer base, as far as I can reconstruct from the Gumroad analytics and the conversations that landed in my inbox, is roughly the following. About sixty percent are mid-to-senior backend engineers at small-to-mid companies, mostly working in Java, Spring Boot, or Python. About twenty percent are engineers actively interviewing for senior or staff roles. About fifteen percent are tech leads who buy bundles as team reference material. The remaining five percent is a mix of recent graduates and people who buy out of curiosity.
I tracked which products sold, which got refunded, which produced repeat purchases, and which titles produced the engineers who later messaged me to ask for mock interviews or one-on-one consults. The data adds up to something specific. It is not what I would have predicted in January 2025.
Pattern 1 — Single-technology guides sell by volume. Bundles sell by margin.
This is the most expensive lesson in the catalog and the one I refused to accept for the longest.
The eleven “Under Pressure” guides, each focused on a single technology, collectively sold over 600 copies. The revenue across all eleven was under $400. Almost every sale was at or near zero dollars because the pay-what-you-want option was active.
The five major bundles, in contrast, sold roughly 65 copies between them and produced over $2,700 in revenue. The Production Engineering OS bundle alone has 12 sales at $149 and is heading toward $1,800 in revenue at the launch price. The Production Incident OS bundle has 7 sales at $79 and has produced over $574.
The math is brutal. A bundle sale is worth roughly fifty to a hundred times a single-guide sale, and the bundle customer is by every metric I can measure a more engaged, higher-value, and lower-refund customer. They read more of what I write. They reply to my Substack posts more often. They are the engineers who later become repeat customers.
The lesson here is not that single guides are bad. They are useful as entry points. Engineers who buy a $10 Git Under Pressure guide are the engineers who later buy a $79 Spring Boot Production OS bundle and a $149 Production Engineering OS bundle. The single guide is the trust ladder rung. It is not the product the business is built on.
What I should have done in January 2025, knowing what I know now, is to have shipped the bundles first and used the single guides as the entry points to them. Instead I spent six months shipping single guides, which built brand but undercharged for the actual product.
If you are an engineer thinking about which kind of resource to invest in, this pattern means: the cheap single-technology guides are fine for filling a specific gap. The bundles are what you actually want to compress months of expensive learning. The bundles cost more upfront and pay back faster.
Pattern 2 — Production engineering buyers are NOT interview-prep buyers, mostly.
This was the insight that reshaped the entire catalog.
When I started, I thought every backend engineer was the same backend engineer. They wanted to debug production better and also pass interviews better. So I mixed the categories, named the bundles ambiguously, and let the catalog blur.
The data corrected me within four months. Engineers who buy production engineering guides are, with high probability, not in active interview mode. They are in operational mode. They are debugging real systems, on call, trying to get better at the work they are already doing. They want the Pre-Deploy OS, the Production Latency Playbook, the Application Incident OS. They are not searching for system design interview frameworks.
Engineers who buy interview-prep guides are, with equally high probability, not actively running production systems. They are between roles, or interviewing while employed, or recently laid off. They want the System Design Interview Bible, the Behavioral Interview OS, the Senior Engineer Interview OS. They are not searching for the @Transactional debugging guide.
The overlap exists but it is smaller than I assumed. Maybe twenty percent of customers buy from both categories. Eighty percent stay in their lane.
What this changed: I started writing in lanes. The Medium articles that promote production engineering content speak only to the production engineering audience and reference only production engineering products. The Medium articles that promote interview content speak only to the interview prep audience and reference only interview products. Cross-pollination is rare and explicit when it happens.
If you are an engineer trying to figure out which guides to invest in, the practical lesson is: do not buy across categories until you are in the matching mode. If you are running production today, do not buy interview prep right now. It will not be useful for six months and you will forget by then. If you are interviewing, do not buy production playbooks until after you land the role. The relevance window is when learning actually sticks.
Pattern 3 — The highest-paying customers all bought after reading something specific.
I tracked the customers who paid at or near full launch price across the bundles. Twelve at $149 for Production Engineering OS. Seven at $89 for Production Incident OS. Nine at $79 for Spring Boot Production OS. Twenty-three at $49 for the System Design Interview OS.
Across all of them, there was a pattern that took me months to see. The high-paying customers, almost without exception, had read a specific Medium article first. Not just any article. A particular kind.
The pattern was: the article they read had a specific number in the title and was structured as a log of failures or observations rather than as a tutorial.
I Did 11 Technical Interviews in 60 Days. Drove the System Design Interview OS bundle.
I Got Paged at 3 AM. Drove the 3AM Incident OS purchase.
I Force-Pushed Three Days of Work. Drove the Git Under Pressure entry-level purchase that often led to a later bundle.
I Won 4 Arguments in System Design Interviews. I Lost All 4 Offers. Drove SDI Bible and SDI OS purchases.
The articles that drove purchases were never the ones that explained technology generically. They were the ones that told a specific failure story with a specific number, that demonstrated I had been through something the reader was currently going through, and that closed with a bundle as the compressed version of the lesson.
The conversion mechanism is not what I would have guessed in January 2025. It is not “this guide will teach you X”. It is “I learned this the painful way over Y incidents, and the bundle is what I wish I had bought before incident 1”.
If you are an engineer evaluating whether to buy any of these resources, that framing is the honest one. Do not buy them because they promise to teach you something. Buy them because the alternative is learning the same lesson through six months of painful production incidents or three rejected interview loops. The bundle is the time compression. That is the actual product.
Pattern 4 — Engineers underprice their own time relative to the cost of learning the slow way.
The most consistent feedback I get from customers who have bought a bundle is some version of “I should have bought this sooner.”
The math behind that feedback is not subtle. A senior backend engineer at a mid-tier company is making, conservatively, $100,000 per year. That is roughly $50 per hour of working time. A $149 bundle that saves the engineer three hours of debugging on the next production incident has already paid for itself. A bundle that saves a single rejection from a senior interview loop has paid back many multiples of its price.
But engineers do not think about it this way. They think about it as “is $149 worth it for these PDFs?” The framing is wrong. The framing should be “is the time I would otherwise spend learning this material the slow way worth more than $149?”
The framing I had to learn to use, both as a writer and as a buyer of other engineers’ work, is: the cost of a resource is the price you pay for it minus the cost of learning the same content through your own painful experience. For most senior engineers, the second number is much larger than the first. The reason resources like this exist in the market at all is that engineers consistently underestimate the second number.
I myself underpriced the bundles for the first nine months because I had the same instinct in reverse. I assumed engineers would not pay more than $30 for a bundle, so I priced them at $30. The first time I raised a bundle to $79, I sold more of them than I had at $30. The pricing was reducing perceived value, not increasing accessibility.
If you are thinking about whether to invest in resources that compress years of learning, the question to ask is not “is the price worth the content.” The question is “what is the cost of learning this material the slow way through my own work.” That number is almost always larger than the price tag.
Pattern 5 — The bundle structure does the work the individual products cannot.
The single biggest catalog decision that improved revenue was reorganizing the catalog into a small number of focused bundles instead of leaving everything as individual products.
When I had 35 individual products on the catalog page, customers were paralyzed. “Which one do I need? Which one is foundational? What do I read first?” The choice paradox killed conversion. Engineers who would have happily paid $50 for a curated bundle were declining to spend $15 on an individual guide because they did not know which guide.
Reorganizing into five bundles changed this. Production Engineering OS for engineers running real systems. Production Incident OS for on-call engineers. Spring Boot Production OS for Java backend engineers. System Design Interview OS for engineers preparing for senior loops. Senior Engineer Interview OS for engineers struggling with communication in interviews.
The bundles do something individual products cannot, which is resolve the choice paradox. Engineers do not have to figure out which of 35 things they need. They identify the bundle that matches their current mode, buy it, and consume it in the order that makes sense to them.
What this means for engineers reading this is: when you are choosing what to invest in, the bundle decision is actually easier than the individual product decision. The bundle is forcing you to identify your current mode. Once you know your current mode — operational versus interviewing — the right bundle is mostly self-selecting.
The complete current catalog, broken down by mode:
For engineers running production systems and dealing with real incidents — the Production Engineering OS bundle is the most comprehensive, 35 resources for $149 at launch, and the Production Incident OS bundle is the focused incident-response version, 10 resources for $79.
For Java and Spring Boot engineers specifically — the Spring Boot Production OS bundle covers the operational layer of Spring Boot at $79.
For engineers in active interview preparation — the System Design Interview OS bundle covers structured thinking under design pressure at $49, and the Senior Engineer Interview OS bundle covers communication across every round of the senior loop at $39.
The decision between them is a function of which mode you are in this quarter, not which technology you are using.
What the 1,800 sales actually proved
The headline number is not what matters. What matters is the shape of the curve underneath it.
Eighteen months of writing, 35 resources, 1,800 sales, and the data converged on a small set of patterns I would not have predicted in January 2025. Engineers buy operational content when they are running operational work. They buy interview content when they are interviewing. They pay full price for content that arrived after they read a specific failure story they recognized. They underprice their own learning time by a factor of three to ten.
I built the catalog wrong for the first six months and adjusted as the data corrected me. The adjustment was not strategy. It was reading the data and accepting what it said over what I had assumed it would say.
For engineers thinking about which production engineering resources to invest in, the practical takeaway is: identify your mode this quarter, buy the bundle that matches it, and treat the resource as time compression rather than as content. The cost of the bundle is almost always less than the cost of learning the same material through your own production incidents or interview rejections. That math is what the 1,800 sales proved.
The Substack version
The Medium version is the catalog autopsy. The Substack version is the operational autopsy.
I am publishing the deeper companion piece on Substack this week. It includes the verbatim breakdown of revenue per resource across all 35 items, the exact pricing changes that worked and the ones that did not, the customer message archive that drove the catalog reorganization, the three resources I removed from the catalog because they were not working, and the framework I now use to decide what to write next.
It is the kind of post most creators in this space do not publish because the data is uncomfortable in places. It is also the post that is most useful if you are thinking about doing something similar in your own career.
You can subscribe at devrimozcay1 on Substack.
Devrim's Engineering Notes | Substack
If you are an engineer reading this and trying to figure out what to invest in next, the easiest move is to identify which mode you are in this quarter — operational or interviewing and pick the bundle that matches. The bundles compress what would otherwise be months of painful work on either side.
I would genuinely like to read your own learning ladder in the comments. The specific resource you bought that turned out to be worth twenty times its price. The category I am still missing from this catalog. The pattern you would want me to write next.
One bundle at a time.
Devrim Özcay is a backend engineer based in Istanbul. He writes about production systems, technical interviews, and the operational reality of Java and Spring Boot in real environments. The 1,800-sale catalog is the source material for most of his writing.
I Wrote 35 Production Engineering Resources in 18 Months. was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
