It’s a common pitfall for developers that are working on new projects to start with an application that resembles in structure what it might look like in production. The issue with approaching a project this way is that you are already making assumptions about how it will be structured before knowing anything specific about how that project will take shape.

The most common initial setup for a web application is a foundation of:

  1. A server
  2. A database
  3. Website backend/UI

Over the years I have come to appreciate the art of a prototype more and more. Using a prototype (or proof-of-concept as it may be called) as the first step in the birth of an application falls in line with the iterative approach the software development procedure usually takes. It’s a very natural extension of our well-known dev cycles.

Starting with a prototype your goal should be to outline the project in a UI that has no real backend and does not use a data store (read: hardcoded). This allows you to prove a theoretical idea works using a concrete result before you build any actual code to support it. Naturally as you explore this new interface you will make potentially radical changes to your original idea. Allow yourself the freedom to explore without spending effort refactoring from the get-go.

As your interface takes shape, and you are confident it will work in it’s current form, start thinking about the following questions:

  1. How will the data be structured in storage?
  2. What storage system will I use to store that data?
  3. Will I be using APIs, MVC or something else?
  4. Will I need an admin?
  5. What kind of metrics and logging might I require?

These questions are crucial to answer and now that you have a picture of the entire site running through your mind you can use actual concrete references to make a better decision.

Just think what would have happened if you started with assumptions about those questions first?