You’ve had your great idea, completed market research, have your marketing plan in place… and now you need to build it. But what technology should you use?

Here I’ll briefly discuss the choices I made for TweetingMachine.

Note: This is a lightening-quick post, and my last for a few weeks; I get married on Saturday, and will be out of contact on my honeymoon after that until hallway through June.

If you can program, this will be by far the easiest part of creating your web app. But before we get coding, there are a few details we need to take care of first.

Naming Your App and Choosing a Domain

I guarantee that in the first few minutes of brainstorming, you’ll come up with many fantastic names for your web app. There’s only one problem: can you find an unregistered domain for any of your possible names? Sadly, the most likely answer is no. Still, you have a few options: keep trying ever more obscure names until you hit on one that’s available and that you like; or try adding prefixes or suffices, e.g. TheFacebook, or FacebookApp.

When it comes to choosing domain names, there is one rule I always stick to: you must be able to read the domain name out over the phone without resorting to saying “Yup, Face hyphen Book app with two P’s as in Papa, not Bravo, ninety-nine in digits dot net, yes, N-E-T.” Whilst this should be for the reason that it makes it easier for your users to tell their friends about your app, it’s also laziness on my part 😉

As for registering domains, as much as I hate their advertising, you can’t argue about GoDaddy’s pricing: $7.49. Ignore the $9.99 claim on the homepage; as soon as you get the checkout, the discounted value will appear.

Choosing a Design

I have previously discussed design fun. In short: cheat, buy a theme for $20 (I use ThemeForest) and be done with it. You can hire a real designer once you’re making money.

Hosting and Operating System

Again, cheap is the name of the game here. There’s no point in spending megabucks on a server when you don’t have the traffic to justify it. At the same time, you want to have the flexibility to handle spikes of traffic. So for the time being go with a VPS. I chose a 1 GB VPS from prgmr. I wanted to host several sites, and thought that there’s a chance I would be doing some fairly heavy lifting via cron jobs, so more memory was a good choice for me.

For the operating system, I went with Linux. I have well over a decade’s experience of hosting with Linux, versus only a few years with Windows, and Windows hosting always involves additional costs to cover licensing. So, going with cheap, and going with what is easy.

Do Not Use Apache

Ok, the heading is slightly unfair; Apache is a perfectly valid choice if you know what you are doing with it. By that, I mean that you know more than setting up PHP and adding a few virtual hosts.

Otherwise, go with nginx. You won’t have to worry about optimization, and if you suddenly get thousands of visitors turning up every hour, your VPS won’t run out of memory and crash.

Language, Framework and Database

I chose PHP for several reasons: I know the language well; it’s pretty easy to build apps very quickly with it; and there are many talented PHP developers out there.

When it comes to choosing a framework, you should first go with what you know. If you like a particular framework, don’t spend hours looking for a better one; use that time to develop your app instead. The only requirement I have is that the framework must be under current development; you don’t want to develop an app which will be a pain to update and support two or three years from now.

I wrote TweetingMachine using the Kohana framework. I had toyed with a few frameworks beforehand, and was starting to get a good feel for CodeIgniter, but had a friend point out Kohana to be shortly before I began development (Kohana is a fork of CodeIngniter). If that hadn’t happened I would have gone with CodeIgniter. They’re both pretty lightweight frameworks, but with enough of the heavy lifting (MVC, ORM, Authentication etc.) taken care of for you.

For the database, I went with MySQL. Again, you should go with what you know best here, as you’re the one that’s going to have to fix it if it all goes wrong at 2 o’clock in the morning 😉

Taking Payments

Whilst I maintain a UK bank account, I’m primarily based in Poland, which limits my international payment processing options. Sadly, there are plenty of PayPal horror stories out there, and I do think that one needs to be cautious. That said, if you just want to see if your idea is viable, sign up for an account and investigate Instant Payment Notifications. This is where PayPal make a POST to your server for every payment transaction you receive. You can verify the POST with PayPal, meaning that they can’t be spoofed by people trying to steal your service. From my experience, it works very well.

I have to make one confession: when I first launched TweetingMachine, I chose to implement IPN “later.” Meaning that I had some rough code there, but it didn’t really work. I received my first payments, manually updated the database records, and then sat down and properly coded support for payments.

Do it, do it now, and stop worrying

Ultimately, I have made some poor design choices with TweetingMachine; I don’t like the way the majority of its back-end is run via cron jobs, or that the code that calls Twitter isn’t as neatly separated from the rest of the code as it could be. But you know what?

It. Doesn’t. Matter.

The important thing is to get up and running in the first place. Once you’ve done that, got a few paying customers and so on, then you can worry about the rest. But don’t waste your time before you even know if your web app is a viable product