Creating a New Product? Look Here For How I Do It

As an active member in Dallas’ startup community, I have the opportunity to talk to a lot of very creative individuals, all with terrific ideas for great software services. One of the first questions they ask me, though, since the overwhelming majority of Dallas entrepreneurs are non-technical, is how in the world to actually build their application, host it, and scale it.
I’ve had so many of these conversations, and seen so many similarities in their needs, I’ve developed what I’ve started calling my Golden Template. This architecture lets me, and anyone else really, quickly and cheaply build a very complex infrastructure from scratch, develop their product rapidly, and host as cheaply as possible, as well as develop for web or mobile or both. There are some options, and I’ll discuss what makes me pick one over the other, but for now let’s get into our language choice.

Language – Ruby on Sinatra

Ruby wins for one reason alone: it’s the fastest language on the market for building things. Because the community is very open-source-friendly, there is tons of code to do everything from talk to any kind of database to tie in to useful services, to sending emails and authenticating your users.
Many Ruby enthusiasts only think about one framework when they are working in Ruby: Rails. Hell, half of non-technical people thing Ruby on Rails is the language. And it makes sense since Ruby on Rails gives you lots of boilerplate code, enforces nice architecture and code organization, and has tons of useful gems for it. I find issue with the fact that it is a very hefty framework. And when you’re working towards a minimum viable product, that can become a hinderance as doing small upgrades starts requiring modifying several files to get things tied togeter. Scaling can also be an issue as you will need to scale sooner than with my way of doing things with Sinatra.
Sinatra accomplishes what we want our hosted servers to be: an API. With a JSON-feeding API, we can build either a mobile app or a web app (and I mean web app as in no page loading on each request). It’s very light weight, and the syntax can be picked up in an hour and have you writing your app. It’s a little more risky if you’re a terrible architect of your code and you start putting everything in one file, but if you break it up into multiple files I find it very easy to work with defining my REST API.

Hosting – Heroku or Appfog

Hosting Ruby code should be like the rest of Ruby: minimal effort. I want to deploy as easy as I start up my testing server locally. I want to scale with a command and I want that scaling done without me needing to add servers to load balancers or make sure my build scripts worked correctly.
Heroku is the hosting platform for Ruby projects currently. They were the first PaaS for Ruby on Rails, and they now host any kind of Ruby web app you could think up. Their first dyno is free, which lets you host your app for nothing while you finish it and get your first few hundred users (protip: use Unicorn for multiple threads in the same dyno!).
Heroku, however, is very expensive when you scale it up. Appfog is trying to disrupt that market by giving you control over not only your dynos(CPU) but also your memory for each dyno. You get 2GB RAM free (which I might add is insane!), and you can distribute that to as many dynos as you want, with a minimum of 128MB per dyno. They also allow unlimited applications with this setup, so you can also segregate and separately scale different parts of your app if you need to do that. This is useful because if you look at a Heroku dyno, it’s one thread and 512MB RAM and one app. Most apps I’ve written top out at 100MB per thread depending on what they are doing, so there’s no point in throwing that much RAM that it will never use. Appfog lets you have a little more control in how that works.
Appfog also has the advantage of multi-cloud tenancy. Heroku is currently only hosted on Amazon Web Services, so when Amazon goes down, so does Heroku (they are currently adding Rackspace to their hosting platform, but if I remember correctly that’s still a beta product). Appfog supports AWS in multiple regions (US, EU, and Asia), as well as Rackspace, Azure, and HP’s new Openstack cloud in Las Vegas with one click replication to another cloud(NOTE: for Ruby on Sinatra you can only use AWS and Rackspace. PHP is supported on all cloud hosts).
The downside to Appfog is that it is still in a beta stage right now. Their PHP hosting was very disappointing, but Ruby has worked out fine for me. Their site seems to be going through some growing pains, and for good reason as from what I hear people are very excited about the 2GB free RAM (another note: the next stage up is 4GB for $100 a month.)

Database – MongoDB on MongoLab

I’ve been a huge MongoDB fan for a while. Yes, I know it has some scaling problems, but they are working on them, and recent versions have gotten much better, with fixes for the global write lock and some other issues already fixed in the current stable version. MongoDB is by far the easiest database to work with, since it lets you organize your data in documents of JSON data, then query that data. This is extremely easy with the Mongoid gem, which I highly recommend as your MongoDB ORM of choice on Ruby. It takes some getting used to, but it’s very easy once you are familiar with it.
Since Heroku only offers PostgreSQL on their platform and Appfog is fairly ambiguous on what exactly their database offering is, MongoLab is my choice for MongoDB provider because they have add-on ties for Appfog and Heroku, so you can get unified billing, and they also give a larger, 240MB free database (and you can fit a LOT of data in 240MB, trust me). I haven’t had any issues with them at all, and have been a happy customer with all of my projects. They also have a very nice admin interface that makes it easy to do things like verify your data is being stored correctly.

Frontend (Web) – jQuery + (KnockoutJS or Backbone) + Twitter Bootstrap

You will most likely need jQuery. If you don’t, don’t use it. I use it a lot, if only for their network functions, so I usually always include it in any project.
Most frontend developers prefer Backbone since it takes care of model syncing for you if you implement the correct REST API. I like Knockout since it has a slightly looser set of requirements and doesn’t require you to reimplement some of their code if you need say offline storage in your application.
DO NOT USE JQUERY MOBILE. I will say it again. DON’T DO IT. Any time someone looks at doing a mobile version of a site jQuery Mobile comes up. jQuery Mobile seems nice since it’s very accessible, but it is a massive, slow piece of junk that still can’t even do animations well on any mobile platform. I’ve used it extensively and I’m done with it. The tradeoff of a rapid development time using their UI isn’t worth it in my book.
Twitter Bootstrap is the current favorite for weekend projects. It comes with a nice UI out of the box that is pure CSS (some add-ons use JS), so it’s far faster than jQuery Mobile. Plus because it’s a responsive design, you get a full desktop, tablet, and mobile app all in one UI. There are also a TON of themes for it that can get you halfway to your app if you don’t have a designer on your team (a massive problem in Dallas along with lacking tech talent).

Frontend (Mobile) – Native, Appcelerator, or Rhodes

As a member of Sogeti’s Mobile practice, we look at a ton of tools to try to make building cross-platform apps as easy as possible. We’re tool-agnostic, so we use whatever fits the bill. We do a lot of HTML5 apps wrapped up in PhoneGap, since that leverages existing skills in HTML5 and is very, very fast to do, which makes it perfect for proof of concepts or pilot programs.
However, the apps tend to be slow unless you spend a lot of time optimizing them, and even them they will never perform as well as a native app because the Webview just doesn’t do things as fast as native. Just ask Facebook and Linkedin, both of who tried it, and Facebook is trying to go full-native after they couldn’t get it to work well.
Native of course gives you the best performance, but it’s hella slow to develop in and you will need to write your app multiple times in multiple languages. Not something you want to do unless you have to, but if you care about performance, this is your likely option.
Appcelerator takes javascript-y code and cross-compiles it down to native code for iOS and Android, then runs it with native UI widgets. It’s a very nice offering that has been getting some serious attention from a lot of big names for their applications. It uses its own syntax and doing UIs is a little like Java Swing or Sencha in that you delcare everything and attach it all together in code. There is no way to do a layout similar to native code for iOS or Android where you have a GUI to design in(at least not that I know of). As such you may have some trial and error to get everything set, but it performs surprisingly well.
Rhodes is a fairly new find on my part, althrough it’s been under the rader for a few years. Rhodes is an open source part of Motorola’s Rhomobile offering. They allow you to write a Ruby on Rails-esque code that creates a Webview based UI similar to PhoneGap. The advantage is that, with PhoneGap, if you need some native component that isn’t in a plugin or part of their standard library, you need to go back to writing native code to get that functionality. Rhodes has most of the native functionality already built in, and a lot of functionality can be added in Ruby code, that compiles down to be run on an interpreter that is C-based (even on Android, it uses their NDK). It supports every platform under the sun, including legacy platforms like Symbian and Windows Mobile. It’s not for everyone (for one thing, if you hate writing C code, that’s what you write native plugins in), but if you need the broadest support across platforms with the least work, and you are already using Ruby, give it a shot and see what you think.

Backend Processing – IronWorker

One of the ways I keep down costs of operations is utilizing deffered processing as much as possible. For those who don’t know, many tasks, such as sending emails and running analytics can be done after a request is submitted, i.e. they are not time-sensitive. If it takes another few seconds to send an email that’s not a problem. For that, we have IronWorker. IronWorker bills you by the second (as opposed to dynos or instances which are per hour) for operation, so in most cases of say email sending each email costs you a second of billing time. And because IronWorker gives our 5 hours a month free, you can do the math on how many emails you can send without paying a cent. They are also very easy to work with, and you can be up and using them in about an hour. You can also run the things you upload locally to test them up before running them in production (note: I highly recommend doing this because if an operation takes an infinite amount of time to run it’ll take them a while to turn it off and you’ll be billed for the time).
Note that Heroku’s worker dynos work and are billed in the same way, but I find IronWorker to be a little easier to manipulate, and I also don’t like keeping the entire infrastructure on one platform.

Queues – IronMQ

This is by the same people who make IronWorker, and they give very cheap queue hosting with a dead-simple API for messaging passing. This makes great sense if say you need a randomized list of entries and only want to generate that list once then pop off of the list as a page is loaded. It’s unneccessary if you need to pass info to an IronWorker, as they have a method for parameter passing, but for other uses it’s very easy.

Payment Processing – Paypal or Stripe

Let’s be honest here: you do NOT want to do your own payment processing. Don’t even think about trying it. You’ll go crazy trying to be PCI compliant alone. Offset that to someone else. Just do it.
With that out of the way, for generic single transactions and subscriptions, Stripe is dead simple to integrate with. I had it up and running in less than an hour. Very nice offering if you want something dead simple to use.
Paypal is a little more complicated, since you have to set up a bank account and get that all working, but past that it gives you a lot more flexibility in how you do payments. For instance, if you need to make payments, Paypal can do that very easily, while Stripe will leave you high and dry since it only takes in money, and cannot distribute it.
Plus, many people feel more comfortable using Paypal than an unknown third party, because Stripe hides themselves so you’ll never know if you’re using them or not.
Lots of people will mention BrainTree for their cheap transaction fees, but I’ve found them to be a total nightmare to work with in PHP. Ruby may be different but I haven’t used them in Ruby yet. Not really MVP material in my book, but probably something to switch to down the line when you are losing hundreds of dollars a day to transaction fees.

Image Management – Cloudinary

I love Cloudinary. Probably because when I found them, I was building a similar offering because I had a few people asking me about image management solutions and best approaches. Cloudinary works by giving you 5GB of image hosting for free. By itself, it isn’t remarkable. What is is that they also will manipulate those pictures on demand, which includes not only scaling them to any size you want, but applying features, doing rotations, and even creating nicely rounded images, then exporting into any format you could think of to be hosted on a CDN, guaranteeing a fast load of the heaviest part of any data transfer. A very cool offering and one I recommend if you are going to deal with pictures.

File storage – Amazon S3

I’ve searched high and low, but there is nothing around that can compare to Amazon on price and speed for storage. It can be a little more complicated to use than say Cloudinary for images, but for files it’s the easiest thing to use. They also have a gem that obfuscates most of the complexity for you. Plus it’s dirt cheap and infinitely scalable!

Performance Testing – Blitz

Blitz is a fairly new addition to my toolbox. It lets you do load and stress testing on your site with thousands of simulated users if you need to. This is useful for cost forcasting as you are getting your financials in order to go to investors. They let you do 250 users for free, which in my experience was not enough to adequately test on Heroku or Appfog, so go ahead and pay (it’s pay per test, so it’s actually nothing to run a test).
There are a few other services I’ve used, most of which can be found on Heroku’s add-ons page, but there are the ones I’ve used and know work well when I’m laying out an infrastructure for someone. Using this, a competent programmer familiar with most of this stuff can be expected to write their backend in a week or two (40-80 hours), then however long the frontend will take (it depends a lot on your app). The important thing is that all of these have very generous free tiers so your infrastructure can be set up and run for free. No users? No problems with infrastructure spend.