Skip to content

Choosing Technology For Your Web App

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 :)

Written by Tom

Are you looking for web development or just someone who will work with your business needs and not against them? Get in touch with me here, or take a look at my consultancy’s website: Moo Unlimited. I’m confident I can help you.

Published inTweetingMachineWeb Apps


  1. speg speg

    “It. Doesn’t. Matter.”

    So true. I forget which book I was reading a while back, but basically they said the same thing. The only thing that matters? Results. Who cares how it’s done, as long as it’s done. Spending to much time worrying about trying to do it ‘the right way’ might stall your development before it even gets of the ground.

  2. Congratulations on your wedding, Tom! And thank you for writing these articles. It’s been really helpful reading about how you got this application off the ground.

  3. Just do it – I had the same feeling than I approached launch of my first app. That was hard times, long nites with coding.. understanding VPS configuration of IIS, deployments etc, bugs.. web design & content.. I undrestood I’m not able first launch with everything I want.

    Launching itselft gives new energy to go on. Nothing should stop you from launch :)

    Now I’m thinking about payments.. I’m going to introduce payments as soon as I go to 1.1 version (new desing, more features.. mvp+ I would say). I’m resident of Ukraine and payment even more painful than Poland. Basically have no idea how to “grab” customer money and “move” it to Ukraine. It is difficult.

    It would be great, Tom if you dedicate one post on payments. It would be really interesting to me :)

    And again, that for yours postings :)

  4. Milo Lennot Milo Lennot

    Yes, thank you again for sharing your experience !!
    And of course have a fabulous wedding !! :)

  5. thanks a bunch for writing this! my take-away today is “Do it Now”. So I am gonna stop worryng abt using python on GAE and getting some free bandwidth and space. Now I am gonna use PHP and CodeIgniter, I love that framework but sadly hate PHP

Leave a Reply

Your email address will not be published. Required fields are marked *