To build a web application, we need to create at least two major components: a hardware platform and a software platform. For small, simple applications, a hardware platform may comprise a single shared server running a web server and a database. At small scales, we don't need to think about hardware as a component of our applications, but as we start to scale out, it becomes a more and more important part of the overall design. We look extensively at both sides of Application Design and Engineering, how they affect each other, and how we can tie the two together to create an effective architecture.

Developers who have worked at the small scale might be asking themselves why we need to bother with "platform design" when we could just use some kind of out-of-the-box solution. For small-scale applications, this can be a great idea. We save time and money up-front and get a working and serviceable application. The problem comes at larger scales where there are no off-the-shelf kits that will allow you to build something like Amazon or Youtube or Friendster. While building similar functionality might be fairly trivial, making that functionality work for millions of products, millions of users, and without spending far too much on hardware requires us to build something highly customized and optimized for our exact needs. There's a good reason why the largest applications on the Internet are all bespoke creations: no other approach can create massively scalable applications within a reasonable budget.

At the core of web applications, we have some set of data that can be accessed and perhaps modified. Within the software element of an application, we need to decide how we store that data (a schema), how we access and modify it (business logic), and how we present it to our users (interaction logic). We look at these different components, how they interact, and what comprise them. A good application design works down from the very top, defining software and hardware architecture, the components that comprise your platform, and the functionality implemented by those layers.

Our architects and advisory aim to be a practical guide to designing and building large-scale applications. They constantly think on how to go about designing an application and its architecture, how to scale your systems, and how to go about implementing and executing those designs.

For larger teams, a Wiki is a good way to organize development specifications and notes, allowing all our developers to add and edit and allowing them to see the work of others.

With pens and Wiki in hand, we start to design your application architecture and then start implementing your world-changing application.