Popular posts

Your question is a little hard to answer because it leaves so much to the imagination, so allow me to state it as I understand it:

"I'm starting a new project with lots of growth potential. I don't know exactly what we'r building yet so I need to make flexible choices. What do you recommend?"

This is an extremely common problem. The simple answer is "It depends on what you'r building", but thats often an unknown until after you get started. This makes it really important to ask the question you'r asking, but the actual answer is surprisingly simple.

Chose what you know.

Any tech stack you know today will have support for the tools you need for growth, when the time comes.

PHP scales, Ruby scales, Python scales, .NET scales. Its not about the stack you chose, its knowing how to architect for the scale you need.

Really big platforms run on multiple data stores, multiple stacks, multiple services and multiple projects. But you'r not writing a Big platform. And you don't have Big Data ™ yet. You have an idea, and you need to get it running. You need speed of development and nothing else. The only thing that gives you that is what you are already comfortable in.

Someone wrote a really smart thing about how to write apps that have the flexibility you'r looking for : http://12factor.net . Open that link, bookmark it, then come back.

That link is awesome but here are a couple of off the cuff pointers, to get you off the ground:

• Consider using a PaaS from the beginning. This forces you into some good architecture patterns from the start.

• STAY AWAY FROM WRITING TO DISK. Writing to disk ties your app to the local system's filesystem. You want to be able to run many instances of your app behind a load balancer.

  • keep sessions in a service (memcached, redis, even you'r database is a better choice than direct to disk)
  • keep any artefacts (like uploaded files) in a service (NFS, FTP, ceph, S3, anything that is not direct to disk)

• Use a CRUD framework. Ideally one that makes it easy to model your data and start playing with it very quickly. ( Django (python) , Ruby on Rails (ruby), Laravel (php), .NET MVC (.net) Play Framework (java), Nodal (javascript), Meteor (javascript) ).

• The database you chose doesn't matter, until it starts to become a problem. This will never happen before you have actual users generating actual traffic and ... hopefully, actual revenue.

• Its not essential, but keep an eye out for ease of building a REST api. Your framework of choice should have your back on this too. (Django Rest Framework is a pretty good example). All the frameworks listed will help you in some way or another. You will need this when you realise your stakeholders want a mobile app.

• Get acquainted with offline processing solutions. You will need this sooner that you expect, and not due to scale, but due to sanity. This forces you to think about what tasks need to be done outside of the user's flow ( Celery, RabbitMQ, NSQ, Redis, even Gearman is better than nothing ). Your framework might have some abstraction for this. Find it. Use it. At some point, you should start thinking about your workers as services ;)

• AVOID BUILDING NATIVE APPS ENTIRELY IF YOU CAN. Cross platform solutions are a real thing. Unless you'r building a game, and even then there's Unity. (Unity, phonegap, cordova, Xamarin, electron, node-webkit)

You may be thinking "Thats not exactly sticking to what I know, you just gave me a laundry list of stuff to go learn!". You'r right. I did. Thats because you'll need to learn each of these to grow your platform, no matter what language / stack you are coming from.

Knowing these classes of tools, even just how they work and the problems they solve, is what will get you through all the stages of growth of your company.

I sincerely hope that is helpful, and I hope you have a great time with your new startup :)

Best of Luck!

PS: I chose to ignore your point about costs, because nobody can have any type of idea what those will be until you yourself know more about what you'r building and storing. Its a non issue until you can actually articulate the use case to yourself, and at that point you'll know how to do the math yourself.