The onboarding funnel: Only a concern if you're trying to grow your user base and make sales.

Conversion: Only a concern if you're charging money.

Adwords: Only a concern if, in his words, you're trying to "trounce my competitors".

Support: If you're selling your software, you kind of have to support it. Minor concern for free and open source.

Piracy: Commercial software concern only.

Analytics and Per-user behavior: Again, only commercial software seems to feel the need to spy on users and use them as A/B testing guinea pigs.

The only point I can agree with him that makes web development better is the shorter development cycles. But I would argue that this is only a "developer convenience" and doesn't really matter to users (in fact, shorter development cycles can be worse for users as their software changes rapidly like quicksand out from under them.) To me, in my open source projects, my "development cycle" ends when I push to git, and that can be done as often as I want.

1-4. Google, find, read... this is the same for web apps. 2. Click download and wait a few seconds. Not enough time to give up because native apps are small. Heavy JS web apps might load for longer than that. 3. Click on the executable that the browser pops up in front of you. No closing the browser or looking for your downloads folder. It's right there! 3.5. You probably don't need an installer and it definitely doesn't need a multi-step wizard. Maybe a big "install" button with a smaller "advanced options". 3.6. Your installer (if you even have it) autostarts the program after finishing 4. The user uses it and is happy. 5. Some time later, the program prompts the user to pay, potentially taking them directly onto the payment form either in-app or by opening it in a browser. 6. They enter their details and pay.

That's one step more than a web app, but also a much bigger chance the user will come back to pay (you can literally send them a popup, you're a native app!).

I wonder whether Google, in its Don't Be Evil era, ever considered what they should do about software piracy, and what they decided.

I'd guess they would've decided to either discourage piracy, or at least not encourage it.

In the screenshot, the Google search query doesn't say anything about wanting to pirate, yet Google is suggesting piracy, a la entrapment.

(Though other history about that user may suggest a software piracy tendency, but still, Google knows what piracy seeking looks like, and they special-case all sorts of other topics.)

Is the ethics practice to wait to be sued or told by a regulator to stop doing something?

Or maybe they anticipate costs and competition for how they operate, and lobby for the regulation they want, so all they have to do is be compliant with it, and be let off the hook for lawsuits?

Nowadays, it seems to be that mobile apps have the "best metrics" for b2c software. I'd be interested to read a contemporary version of this article.

That's a job for a web page. It doesn't need to be installed.

If your product targets a segment that expects a desktop app, do that. Web app, do that. Phone app, do that.

Something like this would have worked if it was still back in the Walmart bargain software shelf where people could impulse buy a CD, put it into their computer and have it automatically start and install, then show up on the desktop. Despite that being less common now, it was more streamlined in a way for many users.

Many of those people probably aren't logged into Steam or Windows Store either, so you have to do your own thing. It makes sense that web is the least friction for those people.

Just. Don't. Subscribe.

Simple!

ok, now do this analysis for mobile apps...

To save you a click: It's harder to monetize desktop apps than webapps.

Lol. LMAO, even.

People who focus this much on "conversion" et al are dinosaurs who deserve extinction.

There's an interview with him on the subject that is sadly behind a paywall now: https://www.indiehackers.com/post/how-i-grew-my-appointment-...

The world has changed a lot since then. The days where 37 Signals could build an empire out of simple web form apps and individuals could build and sell a SaaS that sends reminder texts are long gone. Most of the low hanging fruit was mined out long ago and most simple services have seen 100 different startups try to serve them already.

As much as Appointment Reminder was my prime example of a successful indie SaaS, the author's second startup has (with all due respect) become one of my prime examples of not validating product-market fit before building your product. They went on to build Starfighter, a company that was supposed to be a candidate vetting platform where people could do complex coding challenges and then get matched up with companies wanting to hire people. It was built partially in the open through their newsletter and in Hacker News posts.

If you thought doing LeetCode problems to get interviews was annoying, imagine having to spend hours or days going through a CTF where you hack multi-core CPUs to do something complex with a simulated stock market. I can't even remember the entire premise, but every time I read something about the company it was getting more and more complex. At the same time I was on other forums where candidates were going the opposite direction: becoming frustrated with the proliferation of coding interviews and refusing to do interview challenges that would take hours of their time.

I remember through the entire process thinking that it seemed like a questionable business plan that wouldn't really appeal to companies or to candidates. Even the Hacker News comments were full of (surprisingly polite) feedback saying that investing a lot of hours into solving programming puzzles to maybe get some recruiter interest wasn't appealing - https://news.ycombinator.com/item?id=10480390

Some amazing foreshadowing in that thread from one of the co-founders (not Patrick McKenzie):

> I literally lack the ability to form coherent sentences about our business that don't somehow involve how to render a graph of AVR basic blocks in a React web app, is how little we're thinking about how the game interacts with recruiting right now.

> We are going to get the CTF right, and then work from there to a sustainable recruiting business. We should have done it the other way around, but we didn't. :)

As you might have guessed, it didn't work out at all. It was weird for me to follow one of my indie startup heroes on their journey into their second business that skipped all of the normal startup advice and then reached the exact conclusion that advice was warning against.

It was enlightening to follow along and I'm glad they tried something different and shared it along the way, but watching it happen was a turning point for me in how I approach advice from any one individual author, blogger, writer, or influencer.

"Over roughly the same period my day job has changed and transitioned me from writing thick clients in Swing to big freaking enterprise web apps."

I mean, the web kind of won. We just don't have a simple and useful way to design for the web AND the desktop at the same time. I also use the www of course, with a gazillion of useful CSS and JavaScript where I have to. I have not entirely given up on the desktop world, but I abandoned ruby-gtk and switched to ... jruby-swing. I know, I know, nobody uses swing anymore. The point is not so much about using swing per se, but simply to have a GUI that is functional on windows, with the same code base (I ultimately use the same code base for everything on the backend anyway). I guess I would fully transition into the world wide web too, but how can you access files on the filesystem, create directories etc... without using node? JavaScript is deliberately restricted, node is pretty awful, ruby-wasm has no real documentation.