Guide to application development
In this post I will describe my application-development preferences, specifically:
I will recommend real services, software and techniques for each of these items. The costs for developing an application using my recommended services is free and the costs can scale as you grow.
The only methodology you need: The Lean Startup.
 Business model has to evolve during development,
so: Until model proven your product is tool for learning
so: Only focus on learning, absolutely nothing else
Don't trust yourself, you are suffering from reality distortion
so: Measure what users do, behavioural data is key to learning
so: Only talk with users for hypothesis or ideas, their thoughts are not measurements.
so: Just like plane pilots; look at your instruments
Your first users are early-adopters
so: your product won't grow if their needs are not met
so: it's harmful to develop product for mainstream audience
There is much more about The Lean Startup, so I recommend watching a video by Eric Ries, the original promoter of this methodology. To get from vague idea to concrete actions you can study each item on the image below.
All my preferences are based on this methodology. By simply using the services and tools I recommend, you will automatically have implemented most of the "Build" techniques, which enable you to not only build, but also measure and learn faster than before.
When having learned the Lean Startup Methodology you will be able to manage effectively. The tool I recommend to actually manage a team is Trello.
I recommend writing your client-side app for the web.
Automatic updates for all users of your application, which is critical for continuous integration.
Takes least amount of time to change or broaden customer segment (because you never need to rewrite all your application logic and the web is available from every device, even ancient ones like windows 95!)
When your team wants to create software which does not require hardware web browsers don't support, the web is the most logical answer. To see if your application can be written for the web and what browser compatibility you will be able to offer to your users, take a look at CanIUse.com.
I recommend writing your server-side app in the cloud, on the NodeJS platform.
NodeJS synergizes well with the web, all your programming is done in Javascript
NodeJS is by far the easiest to install on any platform, which allows everyone to have their own Developer Sandbox
NodeJS is installed alongside it's package manager NPM, I can't even begin to describe what an improvement NPM has been in comparison to other package managers, so I wont.
The cloud is the cheapest, most reliable and fastest way to distribute your application and connect to your global storage (database)
The cloud is easiest and cheapest to scale
For a NodeJS Platform as a Service (PaaS) I recommend using Heroku. To learn more about this service, I can read their How it works page.
Costs nothing to run on just one Dyno (slow, but perfect for development)
Pay as you grow, each additional Dyno costs 34.50 USD / month
Can be hooked up to Git-based source control (Github!)
And remember, unlike Google App Engine, you are not bound to Heroku. All NodeJS PaaS providers will be able to run your app without changing a single line of code. This creates a healthy competition among PaaS providers, benefiting the market.
If you're on your own, and you don't have experience using Github, I would go for a simple Dropbox setup and NodeJitsu as your PaaS provider.
But when you want to work in the open, or when working on a project with more than one developer I prefer using Github. And since Heroku uses Git you might as well push versions to your Github repo.
Github offers both web-based and native apps to help you collaborate on software development. It costs nothing to work in the open, and for a small monthly fee you can create private repos.
However Github is more than just a valuable tool, it's a community of developers. It can help you establish an open source developer community yourself, which can benefit your product in the long run.
For storage I want a scalable and fast solution. For a database to scale you will need to eventually be able to divide it into shards, therefore I prefer using a NoSQL database. There are multiple NoSQL database solutions, and generally it's best to find out what your application needs before choosing one of them. However, for a general purpose NoSQL database, I prefer MongoDB.
And the company I use to host it is MongoHQ, their support is instant and helpful, their databases are cheap and they offer a solid monitor tool.
To connect to this database inside your NodeJS application you will need a driver. I strongly prefer Mongoskin, because of it's overall simplicity.
Mongoskin is an easy to use driver of mongodb for nodejs, it is similar with mongo shell, powerful like node-mongodb-native, and support additional javascript method binding, which make it can act as a Model(in document way).Â
After using Mongoose for a couple of weeks, I switched over to Mongoskin and it has proven to be a major improvement. To get a better insight into the differences between it and other solutions, I suggest reading this driver comparison.
Last post I have gone into some CSS pre-processor tools:
 CSS pre-processors are required for any decent web-app. It's simply impossible to keep CSS organized, tiny and clean in a on-demand work environment. A good tool not only allows you to use SASS / LESS or Stylus. It can also minify and prefix attributes where needed. For this I am using SimpLESS; a well-designed and clean product. Slick notifying when my LESS code is invalid. It can also watch and auto-compile files. I often forget it's running.
I much prefer using a tool over implementing an automatic LESS > CSS conversion on the server. Servers are often slower than dedicated tools and for production code you want to serve raw CSS as fast as you can. Some developers solve this by letting their code know if it's running in dev or production. Which can create major issues if you're in a tiny team, with a pressing deadline and feature requests spam mailed to you. You can't test if your code will work in the other "mode" or environment. And therefore there shouldn't be another one.
First of all, I haven't tested Mixpanel in a real project yet. The reason why I'm putting it in here, is because of the innovative "custom event" measuring.
 Next post I will go into my Fledged project, where all these tools and services are implemented.
