What I would like to sell is the code base that interfaces with 6 APIs. The code base downloads and keeps refreshed a copy of the movie database, and it cross references each movie with Amazon Instant Video, iTunes and Netflix (no public API access anymore, but access could probably be obtained)
It also checks each movies IMDB rating and populates the DB with that.
The DB is searchable with elasticsearch.
Its a small code base in Python, with Flask for the search frontend and MongoDB for the data.
Its a streaming movie search engine, it tells you where you can find any movie online.
The links are affiliate links and you will earn whenever anyone that clicks through to Amazon buys anything on Amazon in the next 24 hours.
The sales I have gotten from Amazon were not even for movie purchases, but just other purchases people made. With traffic this would be a good revenue stream.
I am currently immersed in another project and hence haven't had time to continue with streamjoy, but my idea for the next pivot was to create Tinder for streaming movies.
I envision a Tinder like swipe interface for choosing a movie to watch. You would swipe right or left. This would let one quickly filter movies down to ones one is interested in.
The swipe rights would go into a maybe queue, and the swipe lefts wouldn't be seen again.
Picking a streaming movie to watch is a frustrating thing experienced by millions.
I would love for someone to make money from streamjoy. Email me at will@willholloway.net if you are interested.
Note that parenthetical contradicts the "zero days to fix" definition. (No patch available is not zero days to fix "in other words".) That suggests the term as commonly understood is a bit fuzzy.
Personally, I've noticed more use of "zero-day" to mean "exploits are now public but no patch is yet available" than to mean literally "programmers just learned of the bug today".
1. Continued income from it (people aren't going to continue to buy it if the bad reviews keep coming in).
2. You keep/improve your reputation. If your software isn't working well for any reason at all, it can give a bad reputation to the person/company attached.
3. You increase the chances of a good buy-out in the future, over what it would currently bring now.
We all know it can be difficult to get traction on a project, not to mention paying users. You already have proved this one can get both.
Thanks for advice. The main issue is that I have better traction/reviews/revenue on another app, and the work required to get #2 and #3 on your list would seriously detract from the attention I could give to that other app.
There have been a few times where I've followed that exact logic to fix it up, spent a weekend or two on it, and gotten pulled away again. The software has reached a size where it's hard (mentally) to switch back and forth between it and my other app.
The other issue is that now that I have more experience doing Mac development, I'm starting to see that it's not a simple matter of bug-fixing. Some significant development would be needed to bring it up to the same level of polish as my other app, and in the meantime I'm concerned it's detracting from my App Store reputation.
I actually think high level questions like these are just conversation starters which can get into highly technical conversations quickly.
Sort of like the technologies themselves; GameCenter and CoreEverything are abstractions of lower level functionality.
Being able to discuss their purpose, how to use them, and how to glue them together is what a good developer is. The rest is just syntax.
Moreover, I never see these questions as just being a one-by-one trivia list for applicants. More of just a thing to look over, see the technologies that your app may use, and then use these questions as kinda a way to launch discussion with an applicant to see how well the know their stuff.
