links

I am contacting you because I would like to build and release an SaaS app, and host it with you, but there are a number of things required that I don't know how to do. Basically I'm trying to figure out if web hosting support (yours being a possible example) offers assistance with that kind of question, or only with, lets say, bugs in the (your) customer's experience?

I kind of figure it has to be the former and I just need to figure out how to ask politely.

I do have a massive plan to help hundreds of millions of people achieve their goals using computers and the Internet, but at the moment the reason I want to build an SaaS app is to learn to build SaaS apps. There are many things I want my app to do, but, at the moment, I would just like it to do something ... really, anything at all.

Now, at this time, I am actually able to build things - on the Internet, even - that do things. This is not a question about just building something that does things, any things. This is a question about building SaaS apps. And, yes, I want my SaaS apps to do things (as opposed to not doing things), but, if they're SaaS apps, there are certain things they need to do to qualify as being such apps. So, while it's true that I am almost qualified to make things do things on the Internet, I am completely unqualified, as things stand, to do make things do SaaS app things on the Internet.

This raises the following question: what does an app need to do to qualify as an SaaS app? I like what this very very long article says about it. I don't know what kind of person could read this entire article, but I think this idea put forward in it that an SaaS app produces revenue sounds quite correct. I hereby rank that my first concern.

If we analyze this at its most fundamental level, it is true that this works in the following way: users give us revenue units, and our app, in exchange, provides them with a service, i.e., it does something for them. My number one concern, then, is integrally connected to another concern, which I don't want to call "number 2", but it's the other, that is, what the app does for users.

I am calling revenue generation my number 1 concern so that no one will accidentally call it the number 2 concern.

Now, it's all well and good to say "produces revenue", but what I want to shine a light on is the mechanics of that. Well, in a way the little system I just described is the mechanics of that, but it has two components. One sends the user a service, and the other collects from the user some revenue. As I say, I have some idea what to say about the service my app will deliver ... and, actually, I suppose, some idea what to say about how my app will collect revenue from users.

Uh oh. Trouble.

What I'm talking about in the last P above is the mechanics of, well, one or another thing. The problem is, when I think about the mechanics of getting users to send revenue my way, it starts to get really complicated pretty fast. Which, maybe, is just the way it is, but there's something ironic about it which rises to the level of being silliness on my part. I actually think I know how to generate revenue without all those complications. In fact, when I think about it, I don't even need to ask you how to do this, at all. Nor, in a sense, could I do so. Doing so falls into the class of things that one ought not even think about.

I must figure out how to get people to look at my Amazon links.