Want to get rich by creating a killer app?

Well, you most likely won't.
There aren't many companies making direct money from selling app in either iOS or android devices.

Let's do the math.
Suppose your app costs a buck per user.
Now suppose your app has a million paid downloads.
This means 1000000$ in revenues.
An average app would cost you 100000$ to make. (Most cost more, some less)
Now take out Apple's 30%, your of making the app and taxes, and all that's left is ~300000$.

While no small change, this isn't exactly retirement money.

However, if you could sell your app to 1 million users, you're probably doing something right - and get the attention of some big companies, or easily fund your next app.

Still not convinced? Let's do some simple math then.
Apple has given app developers (Up to now), ~4 billion dollars in revenue share. Divide that by 4 years since the store exists, and assuming that the cost of a developer is 100K$ per year, this means that in average, 10000 people (A year) are making their living from this revenue.

The others are losing their (Or other people's) money.

But now let's think of a different strategy:
Make it free, and earn from... well... um...

Not everyone could make lots of money from apps. Actually, except for high end games or the occasional hit, no one does. Most companies have app driven services and value, which generate revenue - That's a more probable model.

So the next time you've got a brilliant idea for an app and want to consult the techie that would invest 6 months of work for 50% shares, think what you're really offering him, and don't be offended if he politely says 'no'.

;-)

The importance of hackathons

Hackathons have become common practice of many companies.
15 years ago while working for verint, we were three programmers from different disciplines that convinced our managers to let us take 3 days each quater to tackle a bug/ system problem/ feature which needed a boost. We would then dedicate these days (And nights) to come up with a working solution or prototype, which sometimes changed the way the company works, solved a major problem for one of our customers, or just accelerated a process (Like performance analysis or enhancements) which could not be done in the normal lifecycle.

Such practices are even more important in large companies. Developers in companies which have a slow, long waterfall type (Even if daily work is agile) processes tend to become more 'typewriters' than 'code warriors' (Or ninjas :)).

A hackathon brings back the joy of coding and creation to such people.

A successful hackathon not only does that, but also shows the rest of the organization what you can accomplish in short bursts and by cutting red tape. Projects that were estimated as months were finished in days. This shakes up your organization, and sometimes makes a good reality check for the way organizations work.

I'd like to finish with some basic recommendations for hackathons:
- Set the goal before beginning. Make sure it is presentable later. (Working demo would be best, even if all you're doing is performance enhancements)
- Remove all of the mondain tasks from the team - This is crucial.
- No processes. If someone is managing the hackathon, the only meetings allowed are brainstorming.
- If applicable, add a product/ UX member to the team. For example, a GUI person can provide you with insights which would give your result much more impact.
- Make the team diverse as possible, but make sure the team is composed of people who can work together. This is not about bonding.
- Start coding as fast as you can.
- Make sure your result is shown to as many people as you can.
- Don't promise anything in advance, but try to reward the team after a successful demo.

Don't bury your best coders in documentation and meetings. Good coders love to code. Let them.

Reading time #2!

It's time for some more links to inspirational stuff...

This 2009 article at wired is one of my favorites. It talks about how 'good enough' easily beats 'great' in so many aspects. Whenever approaching a big design or architectural task, I tend to go back to this article a little bit. People tend to over design stuff, and try to come out with a Lamborghini (That costs like one to develop, sell and maintain), when all their customers want is a Mazda...

If you're always looking for 'the next thing' in dev technology and new stacks, you have to visit the changelog regularly. Lots of emerging technologies, useful libraries and code - All the goodies us geeks need.

For all you non-coders out there, here's a great article on starting a tech company without coding knowledge, and, this great article by @martingryner shows the other side of entrepreneurs recruiting a tech co-founder.

The new iPad paves the way for laptops, PCs and tablets with astronomical resolutions. As resolution gets higher, sites with dynamic adaptation to screen resolution need to scale differently. A simple reflow is not enough - Reflow your site, and your font size will be too small to read. Scale your site, and graphics quality degrades. This article gives some pointers about redesigning your website for retina displays.

And, finally, here's an article comparing between the two leading cross platform mobile development SDKs - Phonegap vs. Titanium. If you're considering cross platform app development, you should read this one.

Hacking your product...

During every company's life cycle, there comes a time where you have to think about strategy.
Where do you want to see your company a year from now? Five years?

The same applies to your product. Though product vision inherits deeply from the company's vision and strategy, sometimes the best ideas could come from the product itself. An accelerator for these ideas could come by approaching your own product like a kid approaches a box filled with Lego pieces.
Try tearing apart your product into its essential components. Find a feature piece, and see what you can do with it.

This is how Amazon kicked off their AWS product...

Simple Gallery - The next phase

Been thinking a lot about my Simple Gallery Management Project.
So far, it's been downloaded ~200 times (130 for version 2.0), and after implementing ~6 projects with it, I'm thinking about taking it to the next step, and making it an even simpler, more generic CMS.
This means generalizing the database, redoing the management portal into a cool, hierarchy-like content portal.

I'll still be using HTML/ JS/ PHP (For json API)/ MySQL as a platform, simply because the cheapest hosting services are under that platform. I could implement it with node.js and mongodb, but that would be overkill. Only when I implement a simple social network, then I might use these platforms - There are few services (Like dotcloud) which do node.js and mongodb hosting, and they are not meant for the SOHO customer requiring our services (myartichoke).

This also got me thinking - What about social networks? Does anyone really need to implement a social network anymore? The 2 major risers in the social network battlefield these days (instagram and pinterest) are less about social, and more about sharing and following, rather than full fledged social networks. This means that these social networks have the 'core' social features (contacts, feed, responses and likes) built into them, but not much more - Facebook and Google+ have a whole envelope of features which try to integrate the web into their sites.

Of course, all these networks also have RESTful web services, allowing for third party developers to integrate into their network as well. This has also become a common practice.

I've also considered multi tag support, but came to realize that I'm using this feature as a 'category' (news/ objects/ shows etc.) when implementing sites - That is why I'll probably change 'tags' to 'categories', and maybe add multi tag support later.

In scope as well is making the GUI a little more '2d' and consistent. Adding an integrated toolbar per item (Like twitter's), maybe convince my wife to design some buttons for me :))

I'll update soon, once the new version begins to show signs of life.

Big data, small code

Building a big data driven web application used to be a big thing. Relational databases, links tables, complicated queries and stored procedures...
Java containers, cache management, state - Big architecture, costing a lot of money, setup and development time.
Scaling also used to be a big thing. Databases needed to scale. Web servers needed to be synchronized. Whenever state or caching was applied, data integrity was a big, big issue.

With new servers like node.js and databases like mongodb, the web stack just got a whole lot simpler.
No need for complicated tables, queries.
IO is faster, without the need for object translations from tables to xmls to jsons or whatever.
And - More important - Indexing, multiple indexing and complex queries are supported as well.

Programming is also much, much simpler. Using dynamic language like javascript is much simpler than using Java. The whole setup is simple - Actually, these servers are extending javascript to be a native language, rather than living inside the browser sandbox. That way, your whole web application is written in one language.

Connectivity modules with other services (amazon, azure, mysql etc.) are available, and expanding rapidly.

My suggestion - Give it a shot in your next web application. If you like javascript like I do, this might be the smartest move you've done.

Edit: (Thanks to @lightpriest for pointing that out): Like all software solutions, you also need to make sure that this solution serves your problem better than 'old' web stack solutions. Read the other side here.

Reading time!

Part of my work week is dedicated to reading and learning.
Most of my reading these days is actually UI/ GUI related stuff, as we're closing a large project at work, and are going through some final GUI iterations.

The 'Little Big Details' blog is dedicated to small but neat and significant UI features found over the web/ mobile world.

This blog, of presentation expert Jan Schultink (Idea Transplant) contains all sorts of tips and notes about presentations, presentation design etc.

Wired's webmonkey has some neat notes in their UI/ UX section.

Here's a neat book by Google about web design.

Terry Martin's great blog got some great insights about design, tech and startups.

And, finally, some management stuff:
My company's COO is a big believer in Theory Of Constraints, and has started to implement this project management methodology in our company (Time To Know).

Basically, TOC works by identifying the project chain and building blocks, trying to deal with each building block as fast as you can (Which also means using as many resources in parallel on each building block to speed up the task), and daily reviews to find the critical (Longest) chain, and speed it up.

This method, though counter intuitive sometimes, has been implemented in the project I'm leading, with wonderful result. My team (~20 UI/ GUI/ Developers/ Testers) have sped up our project delivery times, management overhead is lower, and we're actually enjoying the process...

If you're managing a medium to large size project, my suggestion would be to give it a try. Though it takes some commitment, it seems to be working well for me... As well as reduce original cost in ~30%.

A link to our TOC consultancy company would be added to this post soon.