There's still a lot of low hanging fruit yet to be exploited by deverlopers in the Steemiverse. One potential product has always stood out to me due to just how little work would be required: an e-mail application that could effectively end spam e-mails forever.
Spam is the STD of the internet
Spam e-mails are one of those persistent problems many have discussed over the years, but still lingers like herpes. Instead of boring you with the details of this problem, let's just dive into the application which could be built in very little time on Steem that would totally solve the problem. I think this approach will have the added benefit of giving you a good understanding of the nature of the problem too. The truth is that people have understood the problem for a long time and have understood the solution too, the technology just didn't exist to implement a decent solution. Check out this article from 2003 to see what I'm talking about: https://www.geek.com/news/charging-for-e-mail-will-stop-spam-551697/.
Leveraging Steem primitives to reduce engineering costs
This application would solely rely on existing primitives and features. It's basically just a UI for the Steem blockchain. From a developer's perspective, that's a good thing. You want to build an application with either the most disruptive potential or the most profit potential (depending on your priorities) while consuming as little engineering bandwidth as possible. This is the essence of Lean Startup methodology and minimum viable products. Get something up and running ASAP and then iterate toward product-market fit.
The key primitive that this entire concept would be built around is the ability to send encrypted messages on Steem which I wasn't even aware of until I read this great article by 
You can already send messages on Steem!
In this context it pays to think about it in reverse: Steem already enables you to send anyone an encrypted electronic message (e-mail) for a fee! The minimum fee is the max divisibility of Steem which is, I believe, .001 STEEM.
To see how this would work, once again I would like to avoid digging into the nature of the problem and instead proceed immediately to the solution which lies entirely in the UI. When you sign into this application you should be faced with a very familiar e-mail user interface. The more familiar the better. Too often people overcomplicate blockchain apps in an attempt to show off the novel tech beneath it. People can only tolerate so much change. Give them novel tech or a novel interface, not both otherwise they'll just be confused.
Enter Steem Connect
Of course, when the user signs in they will have to be signing into a Steem blockchain account. The best way to implement this would be to leverage Steem Connect. Once signed in they would be able to a compose an e-mail just like in any other application. There would have to be a recipient, subject, and body. The recipient is the more complicated part. The app could be designed to appeal solely to Steem users in which case the implementation would be easy as the user would need only insert the recipient's Steem username, exploiting another of Steem's unique advantages of having usernames that are also account addresses. This feature set would be good for a minimum viable product. Later versions could add e-mail address support.
After inputting the username, subject, and body the only thing left for the user would be to hit "Send." So far we've got a pretty solid user experience, but as there is going to be a charge we're going to have to introduce a little friction. After hitting "Send" the user will at least have to confirm that they are willing to be charged the minimum .001 STEEM fee. In addition, at some point they will have to give the application authority to trigger this transfer and again the preferred method would be by leveraging Steem Connect.
If the user hasn't given Steem Connect their active key, then at this point they will have to as this is necessary to trigger the transfer. IMPORTANT: NEVER GIVE APPLICATIONS YOUR PRIVATE KEY. The only exceptions to that rule are open source applications whose code demonstrates that they are handling private keys properly which means having them encrypted on your local machine before touching them. In other words apps should never have direct access to your private keys, just an encrypted version they cannot decrypt. The beauty of Steem Connect is that they already do this and anyone can integrate Steem Connect.
Almost done!
Once the application has the necessary authority it should also notify you if it is going to make a transfer. So the worst the user experience should get within the app is A. requiring you to input your active key into Steem Connect and B. notifying you of the transfer which at a minimum will be .001 STEEM. After those things happen the deed is done!
The message has been sent and all that remains is for the recipient to sign into the app and view the message. The app would simply pull all the encrypted memos from the recipient's wallet and use Steem Connect to decrypt them for the user. Again, the app would not be decrypting the message. The developers of the app would never be able to view the unencrypted message because the decryption is happening locally on your machine and only being displayed through the user interface.
Problem solved?
There you go, we basically just made an app that makes it impossible to send spam, at least without spending .001 STEEM (.006 cents USD) per message. One could argue that we already have a major improvement with just these features. Even if the UI simply required everybody send .001 STEEM with every message, this would be a huge improvement. First of all, .001 STEEM is basically free. I don't think many would view this as a serious barrier to using the application as it is a tiny fraction of penny and no one cares about pennies :). At the same time, if you send enough messages (i.e. "spam") those fees will add up to something significant.
One valid issue would be what happens if/when the price of STEEM goes up enough to make .001 a barrier to entry. At that point the divisibility of STEEM would have to be increased, presumably through hard fork, but this would likely be an easy upgrade to reach consensus over and is already being discussed within the community. This would be important for a lot of apps, not just this one.
But wait, there's more!
While we already have an app that solves a problem many have given up even trying to solve (which should be seen as serious proof of the disruptive potential of this protocol) we can actually make it a lot better with additional options that would require minimal engineering work.
I think the additional features with the highest potential would be enabling users to specify how much they want to charge to receive messages. For example, someone whose time is extremely valuable might want to charge .1 STEEM, 1 STEEM, or more. This is also important because the more successful the user is the more valuable spamming them becomes in which case the .001 STEEM might not be enough to prevent spam.
Adjustable fees
To give one example, you can imagine how little .001 STEEM would do to prevent people from sending Elon Musk messages. It would definitely decrease the amount of spam he would receive by orders of magnitude, but it would likely still be too many messages to serve the purpose. Therefore people should have the ability to adjust the fee.
Multiple fees, multiple inboxes
Another option would be to give people multiple inboxes which sort their messages by the fee paid by the sender. The user could then basically have a tiered system. They could have one inbox for users who pay the minimum fee and another for users who opted to pay a higher fee (say .1 STEEM). This would also enable users to experiment with their fees without excluding anyone. Giving someone the option to pay 1 STEEM to send you a message that gets them into the inbox to which you give preferential treatment doesn't prevent them from sending you a message, but it will give you the opportunity to see how much people are willing to pay to send you messages.
Dynamic fees
A more complicated, but potentially more pleasant implementation of this would be to have automatic and dynamic implementations of this. For example, you could have fees and inbox tiers that are predetermined algorithmically based on things like the number of messages you receive daily or your Steem Power, but features like this don't belong in a minimum viable product.
Return fee feature
A more appropriate feature for an MVP would be to make it very simple for the recipient of a message to return the fee to the sender. I actually think this feature would be potentially massive and is only really possible because of Steem's underappreciated fee-less transfers. The purpose of the fee is not to generate revenue, it's to prevent spam--though it is interesting to consider additional features (perhaps premium features which the developers charge for) that turn the app into more of a revenue generating orientation.
But as the primary function is to prevent spam adding the ability for recipients of a message to return the fee to the sender after reading the message and assessing it as non-spam would improve the user experience by lowering the effective cost of using the application. Since transfers are fee-less neither senders nor recipients nor the developers of the app are getting nickel-and-dimed by transfer fees.
A reputation system too?!
Not only would this feature improve the user experience and make the app feel less like a money-making scheme, which could turn off successful people who really just want to reduce spam, but it would enable the developers to implement a reputation metric as well! For example, imagine you saw that it was 100 STEEM to message Elon Musk, but that he returned that fee to the sender 90% of the time. Then you would know that he is predisposed to returning that fee and so you need only not totally waste his time with your message and in all likelihood you will get your fee back.
Monetization
I don't want to go too deep into monetization as I've already covered quite a bit already. One potential method would be to charge users a percentage of the fee they select. If the user selects 1 Steem then the developer may specify that 10% of that fee would go to the developer. It might be best to only charge this fee if the recipient elects not to return the fee to the sender to ensure a good UX.
Alright, I think I've covered quite a bit in this post. If anyone has any questions, including any developers who are looking for an app to build, feel free to comment on this post or message me on steemit.chat.
Thanks for reading!
