Having been around a lot of website & app development for the past 15 years, I see two major ways to pursue a web or app solution.
You can either approach it from the front or the back. This just means that either the project starts with design (the front) or it starts with code and database development (the back).
Let’s just say the front-end design approach is more suited to success these days in creating a web or mobile app. It has more of an agile (not the method, but really agile) way about it. If you are going to develop a software app, showing customers what you are going to first develop, then develop it, makes total sense. This is all my opinion though. When I hear that a company is going to develop all the back-end tech first and then figure out how the app will be approached from a customer perspective, I get a little nervous. The front-end generally dictates the back-end. But, once again, there are a lot of perspectives on this. If we were developing 50 years ago, and were using a mainframe, we would have to build the back-end first, because there was virtually no front-end.
However, in todays environment, the largest of applications require some sort of front-end design sooner than later (preferably upfront). I will give some great examples of success at the end of this article.
In modern web dev apps I generally see a front-side approach. That does not mean that the back-side is not a way to develop. It would really depend on the type of project. It can turn to a situation where the front and back meet in the middle. That Middle approach may be a happy medium. The Middle approach to me is just the second stage of the Front-End.
Back-End Approach
If the project is completely not dependent on customer user interface design or known business model constraints then back-end makes sense. A good example would be developing an API. An API (Application Programming Interface) is a way computers connection and pass information around. So without any serious user interface, an API generally has no front-end. But even with an API, I prefer a front-end approach, because sometimes it take a front-end to understand how the API needs to work. Another example would be a database solution that has no user interface. Let’s face it, if there is a User Interface somewhere involved, even an administration screen, the front-end approach makes total sense.
Front-End Approach
The Front-End approach is relatively straight forward. One tech team I work with typically will design as many screens as possible in advance, so they have identified all the necessary back-end programming needed. Once the company or client has agreed to all these designs, they move on to an HTML/CSS version. At the same time, they typically will start to do some of the heavy lifting back-end parts of the project. This depends on the sophistication and complexity of the application. So the Front-End approach ends up meeting the app code in the middle. It’s a necessity.
The Iterative Approach
During project development, software development companies find stuff that needs to be added or fixed. I always refer to this as the plumber who needs to open up the wall to find out what needs to be done. No project is exactly the same as the design. There are always slight changes, typically made by the product owner/manager. These are the fixes you could not think of initially or bugs that come into the process by mistake or because of an unexpected sequence of events (stuff you could not foretell).
After the first version of a live software project, also called a Beta or an MVP (Minimum Viable Product), there is the next version. Typically these next versions and changes don’t always start from the Front-End, unless there is a redesign. The next set of changes go through the same set of processes again and again.
The Final Point
Well, let’s just say that Back-End driven development is good for certain types of projects. Let’s just say that it can lead to a major problem if the project is consumer/customer facing or consumer oriented, especially if the Back-End driven project was not developed with real customers in mind. If the customers enter the process later, it may still be ok, especially if there is a budget to redevelop the entire project (front-end design) from scratch. Most start-ups and divisions of companies don’t have the luxury of being like a government project. There are many reasons why software projects fail or have to be redeveloped from the beginning. In order to make sure this does not happen, starting with the Front-End method of development can help seriously reduce this problem.