is it possible to monetize alfred workflows?

[abbood]

I just released my first workflow and have a lot of ideas down the line.  The code is all open source. However I would like to eventually do this full time and monetize it. Is this possible with alfred workflows? I know on packal it puts a pre requisite that a workflow must be freely available. I'm obviously not constrained to distributing my workflow via packal (i can just post a binary on my own website for $$), but i'm just wondering if there is a precedent to this? 

 

I can do what gitlab is doing, ie an open source freemium model where their code is open sourced, but then they add special features and services on top and slap a price tag on it. I asked their VP of Product about the decision criteria with regards to adding a new feature to the open source or paid version? he said whenever a feature makes sense to an org with 100+ employees.. it goes in the paid/enterprise version, everything else goes in the open-source/community version. 

 

I'm thinking i should probably do the same thing, although alfred (almost) by definition is a personal assistant kinda thing.. it's not really meant for enterprise or meant to make sense for 100+ orgs.. or does it?

[vitor]

5 hours ago, abbood said:

i'm just wondering if there is a precedent to this?

 

I remember a user a good while ago (maybe two years) trying it. I never heard of it again and I doubt they sold a single copy.

 

5 hours ago, abbood said:

it's not really meant for enterprise or meant to make sense for 100+ orgs.. or does it?

 

No, it is not. There are no features in Alfred that are specifically geared for organisational use. That wouldn’t really make much sense. I’d say it’s definitely personal.

 

I’ve thought about this before, have a good number of Workflows and users, and even held the top spot for most contributions on Packal for a good while. All that in mind, I still doubt I’d be able to do any meaningful amount of money. Expectations are important, and for the most part Alfred workflows are expected by the vast majority of users to be free. I doubt there are enough users to counter that trend and make the Workflows even ramen profitable. Especially when you can come on the forums and ask for help building it yourself. I also don’t think it’d sit well with many users if you sold the Workflows on these forums. But the forums are also very community-driven and I doubt there’s a better place to gain traction.

 

Some users do offer to pay for the time of whoever helps them, but as you can guess those are the (tiny) minority. I have received very few and modest donations from users (and I do appreciate them greatly!), but never asked for them.

 

I also don’t think Alfred Workflows lend themselves to being sold, from the way they’re built. The interactions you can do with Alfred are simple enough and well documented, so the only complexity you can add is via code. That means most you can do is build a good tool (likely CLI) that your Workflow will use, and at that point you’re not really selling the workflow, you’re selling the tool, and quite frankly narrowing your market.

 

If there is a way, I’m betting the most you can do is something like Dash, where you’re selling a tool and have the Workflow as a companion that promotes the tool itself.

 

All that said, if you can indeed do it, I’d be interesting in reading your use case. After all, it’d mean I was wrong, and I’d like to learn what I missed.

[dbpiv]

Another option might be contract development for custom workflows.  IE creating a custom workflow around an agreed upon set of requirements. 

 

dp

[vitor]

11 minutes ago, dbpiv said:

Another option might be contract development for custom workflows.  IE creating a custom workflow around an agreed upon set of requirements.

 

Like I said:

 

2 hours ago, vitor said:

Some users do offer to pay for the time of whoever helps them, but as you can guess those are the (tiny) minority.

 

That also won’t get you far, money-wise. Certainly not to be done full-time.

Edited February 20, 2017 by vitor

[dbpiv]

I certainly agree with the full-time aspect.  I was just trying to illustrate a difference between potential donations and agreed upon compensation.  

[deanishe]

1 hour ago, dbpiv said:

I certainly agree with the full-time aspect.  I was just trying to illustrate a difference between potential donations and agreed upon compensation.  

 

All the same, you'll struggle to find someone willing to pay even minimum wage for time you spend on a workflow, let alone anything like a developer's hourly wage.

 

There might be some money to be made selling workflows at $1-$3, but probably not very much. And I don't see how that would work with open source code.

 

On top of that, unless your workflow is complex (to implement), it's quite likely that someone else will release a workflow that does the same thing as yours, but for free.

 

[vitor]

24 minutes ago, deanishe said:

On top of that, unless your workflow is complex (to implement), it's quite likely that someone else will release a workflow that does the same thing as yours, but for free.

 

Not to mention the more complex it is to implement, likely the more complex it’ll be to use or the more case-specific it will be. Either way, it reduces the audience more.

 

Also, the more broadly-appealing the thing your workflow does is, the likelier it’ll be done by someone for free, even if it is complex.

[abbood]

thanks for all the responses guys. There are a couple of things I wanted to point out

- some said above that alfred by definition is a personal assistant and is not likely to be used at an enterprise level. 

My response is just b/c it isn't historically associated with enterprise, that doesn't mean it cannot be tailored to fit enterprise. For example Slack was born out of IRC chat (something that was documented quite nicely by Scott Berkun in A Year without Pants). 

 

- there is a point that people won't appreciate/like selling alfred workflows on the forum/packal etc.

Alfred (and the forum and packal etc) need not even be the distribution point. As a matter of fact the product itself need not be restricted to alfred users (for example the business logic can be wrapped by an api, which get accessed by alfred and wox for windows for example). In that case the sales channel could be a stand-alone website (of course that would entail kind of reinventing the sales channel from scratch, as opposed to getting on known market places like app store etc.. but that just makes it a bit harder, not impossible). 

 

Anyways let me explain where I'm coming from a bit more: I've worked as an engineer for many start-ups, and then I somehow started running my own (lobolabshq.com) and started specializing in setting up processes at start-ups so that they can be "remote ready", after that I scale their team by hiring remote engineers (you can see a detailed description of one such experience here with vibereel.com).

 

So when we talk about "remote ready" processes, there are processes/protocols that I have setup in many start-ups that just proved to work again and again, but obviously there is always a lot of room for improvement. So for example I created a protocol for creating an issue on jira/github/gitlab etc, protocols for slack communication (ie users have to put their usual availability hours on their slack profile, slack channel prefix where each prefix covers a project or group of projects and usually have a development channel, a schedule channel (people check in/out) and a commitments channel (people put what they're committing to accomplishing that day using ticket numbers etc etc). 

 

As we all know slack isn't the place to document such protocols, so I documented these processes in Google docs (effectively making google docs a wiki). The thing is that google docs isn't meant to be a wiki, it just stores documents and you can improvise the structuring of your documents as you want. You can set google docs that explains that structure all you want, but you'll still have people who are confused about this labyrinth of documentation. 

 

Anyways long story short: I envisioned alfred and alfred like quick launcher apps (for other platforms like wox) to be the command line tool for the average Joe in start-ups where they can access all these docs and actually work with them. So me logging my own hours using an alfred workflow is a very simple "action" of a laundry list of common actions that are performed in these remote start-ups. I can probably release a couple of them free on alfred, but then sell a big collection of them as a package to enterprise. Probably part of the package would be "scaffolding" a whole google drive/slack structure for a remote start-up. Providing such a service not only would make people more productive, it would also give them a time-tested process wrapped in a command line that will just make them more effective in what they do. 

This is my vision, and I honestly think people would be happy to pay for it. Obviously the key here is scale: I'm not interested to be hired by someone to do their custom workflow and get a McDonald's salary, I want something I can package and sell at scale to make some "full time"-able coin. 

 

Bonus: I gotta admit this idea has pivoted a lot.. Initially I was thinking of simply creating a chrome add on that wrapped google docs with a wiki interface (see this fake press release) But then I liked the simplicity and power of alfred. So now I'm in Alfred land

 

 

 

[vitor]

No one claimed Alfred couldn’t be used in an enterprise context, just that it has no features geared for it. Similarly, no one claimed you had to sell on the forum or Packal, just that the forum is likely the best place for discovery.

In the end, you did ask for our opinion, not our confirmation.

In me and @deanishe you have the two most frequently present Workflow developers on these forums — it’s likely every new post gets a response from at least one of us. What we can give you best is our view of Alfred’s community.

You’re conflating people/average joe with company/startup. Those are pretty different.

If you’re talking about selling it to your startup clients (as a consultant?), I’d argue you’re not actually selling a Workflow, you’re selling a tool that just happens to be packaged as a Workflow. You can sell anything to clients you’re already servicing as long as you make it valuable to them — technology is irrelevant.

So either the conclusion is our opinion doesn’t matter anyway, because you’re selling to your clients and you know their needs better than we do; or that no, we don’t think selling Workflows full-time to random people will be very profitable.

From your answer, it seems you would still try either way, so best of luck! And don’t forget the write-up if it ends up working out for you.

Edited February 21, 2017 by vitor

[abbood]

hey Vitor thanks for your feedback. 

 

I'll keep you guys posted with what comes out of this.. i may pivot 100 times still.. as I'm still struggling to have a detailed vision of how the final product will look like. That said, I'm brain storming a lot. I've created this spreadsheet to list basically all sorts of "commands" that would be nice to exist, that would speed up the workflow of certain people (personas). I may find a pattern or something. 

 

Cheers!

[abbood]

sorry this is this spreadsheet i created: https://docs.google.com/spreadsheets/d/1bKzipmyBair6QR3wxXfacwiTWyGShzfm5j-2XuemvzM/edit#gid=0