34
11 Comments

Made $5000+ in Gross Revenue!

Another week has passed and yesterday https://rebase-book.com has reached the 5k mark in gross revenue.

Sales definitely have been going down since the official release two weeks ago, but that was expected.

I've also reached out to most of my customers to ask them how they like the book and what they are missing. Turns out the feedback has been overwhelmingly good! A lot of people enjoy the introduction chapters that explain the inner workings of Git.

As always here are some numbers:

Total number of sales: 162
All time conversion rate (rebase-book.com): 12.9%

I'm currently working on an article that describes the entire workflow/process on how I've authored and published this ebook in just two months.

Feel free to follow me on Twitter for updates very soon: https://twitter.com/PascalPrecht

  1. 2

    Great accomplishment!

  2. 2

    Thanks for sharing Pascal!

  3. 1

    What is your seo strategy? The link at uber suggest does not show a pretty picture?
    https://app.neilpatel.com/en/seo_analyzer/backlinks?domain=rebase-book.com&locId=2840&lang=en

    1. 1

      Hi!

      I haven't spent too much time on SEO related things. Most of my traffic is generated organically.

  4. 1

    Pascal, congrats to your figures but what I don't get at all: Why did you choose such a niche topic? I do not mean git but git rebase. I think also that using rebase has its trade-offs. If you are in teams where not everybody is rebase-wise on the same level as you are, rebase is risky. Then, it shows also that your workflow is brittle if you need rebase. Whatever, read https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1

    Imagine you spent your time and energy into something where you have a bigger audience, why rebase? Also consider, how many times you spread the word in forums etc. just assume some reach you created and compare this to 162 buyers. Just IH gets 500-800K visits per month, let's assume they have just 100K uniques which is very conservative. Those 100K must have seen your many posts with 100% odds.

    162/100K = 0.16% conversion and that's just IH (admitting that IH is not the right site for getting leads because of the high no code ratio)

    no offense just curious.

    1. 1

      Hey @Cass1

      Thanks for your thoughts and input, and no worries I don't take this offensive.
      I think those are great questions, so let me answer them for you.

      Why did you choose such a niche topic? I do not mean git but git rebase

      I've touched on that in a blog post here: https://pascalprecht.github.io/posts/i-am-writing-a-book

      Basically, it boils down to this:

      There are many people out there using git and most of them certainly get away with typical workflows like adding, committing, pushing and pulling changes. Some of them manage to survive merge conflicts without being scared to “mess things up”. However, the majority of software engineers (and any git user for that matter), feels rather uncomfortable when using the tools, especially when just knowing how to add and commit changes is not enough.

      I see many people struggling with having "control" over their commits and their actions inside of a git repository. That's why REBASE actually doesn't just discuss rebasing in git, but also explores the inner workings of a git repository and how git puts commit objects together etc.

      I'm getting a lot of feedback from my readers that they found those chapters extremely valuable, which kind of confirms my theory that there's a need for people to learn this stuff.

      I think also that using rebase has its trade-offs. If you are in teams where not everybody is rebase-wise on the same level as you are, rebase is risky.

      It absolutely has! Like everything in life :) You should be knowing what you're doing and that's exactly what this book tries to accomplish. Regarding the risk in general, luckily it's actually very hard to lose work in git, which is also something I keep touching on throughout the book.

      Regarding the article you've linked: I still need to read the whole thing, but I skimmed through it. So one thing he mentions, that commits might break the build and you aren't aware until you see it breaking with the last rebased commit... well, that's where it's part of our job as software engineers to ensure every commit in the repository compiles/builds. But that applies whether you're using rebase or not. As a matter of fact, the exact same can happen without using rebase at all.

      To address this issue there's actually several things you can do. For example, to ensure CI is green and stuff is compiling with every commit, you can run your CI task during a rebase for every commit. That's also covered in the book :)

      Imagine you spent your time and energy into something where you have a bigger audience, why rebase?

      I don't think I understand the question. Can you elaborate?

      162/100K = 0.16% conversion and that's just IH (admitting that IH is not the right site for getting leads because of the high no code ratio)

      Also not sure I get your point here... Are you wondering how my conversion rate is higher than the number you've came up with (given those variables)?

      Thanks for your input and feedback! Good discussion :)

      1. 1

        why rebase?
        I don't think I understand the question. Can you elaborate?

        The point where coders google about rebase and want to learn about rebase takes time (I rarely to never use rebase) and I'd say that the urge/pain/target demo to learn rebase is smaller than eg understanding git from scratch (you mentioned that readers found the inner workings valuable). maybe it's just the title and/or CTA which puts yourself in some niche.

        not sure I get your point here...

        Apologies for being not clear: Your content marketing efforts were good, means you and your book were quite visible. I think I read at least half a dozen time about your book (but never thought a second to order it despite being a coder). And when you just take look at IH and its reach, the outcome is a bit underwhelming. Imagine you would have a topic with broader interest ('git for no-coders' as a non-sense example) you would have exploited IH's user base better.

        1. 1

          You make a very interesting point with the topic being a niche interest.

          My thoughts on this are two-fold. One is regarding picking niches, the other one is concerned with the production of knowledge.

          If I look at Pascal's product from an entrepreneurial point of view, he had a choice between two general audiences: a large general audience in which a minority is interested in rebasing (let's say "Audience 1: all current and future users of git") and a smaller niche audience where a majority is interested in rebasing (let's say "Audience 2: all intermediate git users who work on projects complicated enough to eventually warrant deeper knowledge of git").

          Audience 1 is a very aspirational audience. There are lots of people, and selling to them requires them not only to find your product, but they have to be made aware that they actually need to know something about rebasing in git. Marketing gets more complicated in two ways: you're fishing in a larger sea, so reaching your prospects will cost more, and you have to prime your prospects to become aware of their problem at the same time. People in this niche could be anything: complete novices, intermediate developers, or senior architects. Each group needs a different message and channel to be reached.

          Audience 2 is a smaller, but more realistic audience. There are fewer people, but they are uniquely aware of the need to understand git better to be able to deal with more complicated problems. This niche will consist of intermediate and expert users of git, already being aware of most core parts. Many of them will likely be employed by medium or large IT organizations, as problems with distributed version control that require more advanced concepts usually spring up when a lot of people are involved in the development process.

          Pascal does something really nice with his introductory chapter: it removes all the little differences in specific knowledge that an intermediate or even an expert may have skipped or forgotten. It levels the playing field by explaining foundational functionality to then teach an advanced concept with the core principles assumed to be understood.

          That brings me to an important point: the Indie Hacker crowd is not his (prime) target audience for the book. Many developers here have limited experience with larger projects, and if they run a solopreneur business, they might never need to. Pascal IS an Indie Hacker, and his book CAN be helpful for other Indie Hackers, but it WILL be helpful for engineers working in mid-to-large organizations.

          So while we're talking about SEO and finding customers: my recommendation would be going to the places that developers who work for Mailchimp, Buffer, Microsoft, Twitter, Facebook, and all other 15+ employee businesses' developers hang out: IRC, Discord, Coding Slacks, Forums, Meetups, Virtual and real conferences. That is where Pascal will find his budget-owning niche audience :)

          And by the way @Cass1, you are 100% right to assume that if he had written a more generic book about git, his audience HERE would have netted him more revenue, as it would have solved another more general problem.

          That brings me to my second point because a more general book would have been a wasted opportunity. In my experience, technical experts excel to transfer their experience at the margins of the production of knowledge. Phrased more pragmatically: experts should write about their deepest expertise.

          Pascal is a highly talented programmer, and I had the opportunity to be part of a workshop he gave a few years ago. He has a deep understanding of advanced concepts, and he is a great public speaker as well. With this in mind, I claim that I would rather have him apply his clarity and expertise to write a book about advanced concepts of using a system like git. Many people can write an introduction to git. Few people can write a clear explanation of rebasing with git. @PascalPrecht is one of them.

          Hope this gives you some insight into my perspective. I love the progress of the book and the transparency of the process. Very cool.

          1. 1

            thx for your elaboration. check Dan Abramovs (one of react cores and quite popular guy) upcoming book on JS. Old subject but he tries a new way to let newbies grok JS. Big audience, big competition but he found still a way to differentiate himself. You have to get deep into his tweets to get that he chose a new angle to teach JS.

            With this in mind [Pascals skills], I claim that I would rather have him apply his clarity and expertise to write a book about advanced concepts of using a system like git

            I heavily disagree and there is no correlation between your expert level and what you should write about. Again compare Dan Abramov as one of functional JS' godfathers and his newest JS book. If Pascal wants to push his personal market value with some deep niche book then git rebase might (!) be an option (which I'd still doubt) but commercially it doesn't make sense. It's like writing about a sub-sub ecosystem.

            Using git rebase is debatable, it shows that your overall versioning processes are subpar and the moment a senior engineer at Amazon has the time and an urge to order git rebase to get smarter is <0.1%. IDK if mastering rebase matters, but mastering standard git workflows, k8s, state management , Tensorflow, that's stuff that's matter and where you would order a book but not git rebase. I think it's even not the contents of the book but just the title. Maybe it should have been 'git advanced concepts for high productive teams'.

            still i am happy for the 162 pieces sold and congrat Pascal BUT I just wonder if this effort could have created some bigger ROI.

            1. 1

              These are all great points and I totally see where you're coming from. I'm certainly no Dan Abramov, but to be honest, I'm also not doing this to push my personal market value.

              It's not even my goal to make a lot of money with this book. See my older milestones. Reaching the first 1k was already more than I've imagined I'd make with this project.

              The reason I've created this product is because a) yes I do see a lot of people struggle with some things and this book can help, but also b) I just wanted to go through the process of creating something from scratch and giving it my personal signature.

              Of course, I wouldn't mind if REBASE generates even more revenue, and it most likely will. I sell ~10 copies weekly on average, that is 25*10 = 250 € per week * 4 = 1000€ per month, passive income.

              However, I'm well aware I won't get rich with it and that's perfectly fine. It's already been going much better than I thought. The feedback is outstanding, people seem to really like the book and learn a lot (I will update the landing page with testimonials).

              I also have some other things planned around the book, so at this point it's just making the best out of it that I can and ideally earning a little from it. :)

        2. 1

          Ahh, that makes sense yes.

          I still believe I actually haven't reached as many people though. Looking at some stats there were just about ~9000 page views in total for rebase-book.com since the pre-release of the book.

          So I would assume that, if there were indeed 100k ppl (just to stick with your example) checking out the site, sales would be much higher. Probably still with a conversion rate of ~10%.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 16 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments