How To Kick Google's Ass In 3 Steps

Venture Capitalist and Computer Scientist, Paul Graham, did make an interesting statement a while ago: “Some company should replace Google search engine”

Mobile search is really broken.

Maybe that is the first place to start.

I live in a third world country - Morocco. I think many of my ideas are either biased either by my own culture, or rather unbiased by the noise in California.

This draft idea as detailed in this article is designed to be executed in less than three months (pivot or proceed), or you can even work on it over a series of weekends, your choice. I don’t claim it is fully mature, it is just a draft.

1. Start With A Pain

There are many problems with mobile search and here are two at the top of my mind:

1. The App Search Problem: Apps aren’t given democratic ranking, it's hard to find really cool apps.

2. Device Context Problem: When I started with this draft in 2014, for example, when you searched for "funny" on Google, it would give you a bunch of websites, most of them were irrelevant for mobile experience.

Mobile experience is contextual, social and Local, don’t say solomo, solomo is a creepy word.

Most websites ranked using page rank and SEO are not well suited for mobile exploration.

Mobile experience is contextual, Social and Local.

Don't say SOLOMO (SOcial-LOcal-MObile), it's a creepy word. Ok, I dare you, I double dare you!

iAfrikan SOLOMO Samuel L Jack Pulp Fiction GIF

(Heuristic: Mobile friendly websites think mobile first, most of them either have apps or responsive design.)

If I’m searching for “funny”, it should give me websites that have responsive design only, and at the same time, think of “mobile first”.

If I’m looking for a website in search. It should search the apps first, then go and look for the websites based on the keywords found in apps, go through a google search then find their websites, then display them in order of priority, based on the app store results.

This can be used as a ranking system to make things easy for users.

You can then just jump-start this by crawling App stores (or App Annie). It will take the time to write a crawling daemon.

2. Build Unique Capacity

This is to help improve the ranking system.

You can contact tech bloggers and writers and ask them to review the latest apps. Build a community of tech bloggers and writers because their opinions are likely to matter more than just algorithms.

During the early stages, developers or startups should pay to have their app reviewed by those trusted tech bloggers and writers. Then you have a marketplace of trusted tech writers and app reviewers.

3. Being Truly Searchable

When I want to search on mobile, I’m looking for a pharmacy, it should show me pharmacies around me, if I want to search for profiles, it should show me friends around me, and so on.

If I’m looking for restaurants, it should be able to do this. But we end up having a constellation of apps, each one having reviews not in the other, confusing, and scattered.

Not like the real web.

Solution: Having a Peer-2-Peer network (something between BitTorrent and Bitcoin architecture) that has this user experience.

Peer 2 Peer Distributed Network

But the network should have organic growth, to hit critical mass at a certain point, so it can go viral later on.

Yes, the classical “go viral dream”.

Let's say you are a store or a person who wants to be discover-able through this special search. If I want to start a restaurant tomorrow, I don’t have to create a website, I would just add my restaurant node, and people can discover my restaurant through the search, if they are searching within 100 meters proximity for restaurants that sell pasta and cheese dishes, they can just discover them.

1. I download the App.

2. Create a Unique Identity (either by coupling phone number with Password, or phone number with fingerprint).

3. If I want to disable myself from being discovered, I can do that, and it automatically puts me off the grid.

4. Create “discover-able nodes” such as: restaurant, coffee shop, freelancer profiles etc.

Each User who has an identity can create Nodes. The Nodes have the following properties:

| A: Trust/Ranking
| B: Types/Keywords
| C: Content greps

The Types/Keywords associated to my identity and Content greps are kept on the device to be crawled and changed whenever the device owner wants to change the information about his content.

The Trust Ranking is then kept in central servers instead of the P2P network:

  • It can be updated through the Apps who access the API (each app gives a ranking , and it's coupled with the ranking of the App itself, if you have an App that is really well ranked and it's ranking is high, it means that the rank is trust-worthy, else it would be neglected).

  • The ranking can have a sub ranking, that is custom created by the Apps, and is either public or private. (for example food taste can be a sub ranking, for sort by).

So the information is discover-able, when I search for things around me, I can search for real things around me.

Mobile experience is contextual, social and local, don’t say solomo, solomo is a creepy word. Tweet

The objective is to make this as an API for developers so they can start using it for discovery.
You can jump-start by avoiding the chicken and egg problem by mashing up Yelp, and using Foursquare API, and aggregating content. Then adding some PageRank sauce to it.

Foundation

The thinking paradigm is “nodes”, I can add a node to the network whenever I want.

The Node is "API-able". When developers want to create Apps, they should no more think about “how do I get the jump-start of user information, aggregation, etc.”, they just add the login using your API.

Then she can use the user’s Node to add stuff that can be index-able, and she makes her App in the process improving the user experience of the indexed content.

Lets say I want to make a dating App like Tinder. I would just add some anonymity stuff, then the content can be indexed by others.

If I want to make a classified Advertising site, I can add “an announcement” and give it a timeout and attributes, then the users can find it.

Thus the developers can truly focus on the User Experience and community building rather than the Data Work, then pay for service fees per API/Call.

The developer of Apps should no more care about the back-end, and not even care about Backend-as-a-Service, he should just care about a Magical API that enables him to have these kind of services out of the box and pay calls fees as if he would pay hosting fees.

You won’t have to monetize through ads like other’s do.

Both these can be worked at as part-time, once a week, especially for the back-end it takes a lot of time to build good crawlers and data-aggregators, you will find yourself waiting for a week for some operations to end. So it does not stop you if you are already working on something else at the meantime.

The same goes for user experience and building fake prototypes and discovering the right users, and finding “THAT ONE USE CASE” that you should start with.

This can be easily started by two Co-founders,

  • One taking care of developing the App, the user experience, the customer discovery, the product iterations.

  • One taking care of the back end magic and data analysis and mashups.

Cover Image, Muhammad Ali - Body & Soul | Televandalist

Comments