Starting In The Front-End vs. Back-End Web Development

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.

Remember to buy my book.  Just click this link and it will take you to Amazon.com, where you can purchase Thinking Like A Start-Up.

Dealing with Feature Overload in Web Product Management

Simplify, Simplify Again, and Simplify a 3rd time

Having come into contact with at least 20 different websites and start-ups over the past 2 months, plus having to manage all the features in our new start-up Krowde, I am starting to see the light on the words “Simplify, Simply Again, and Simply a 3rd time”.  Back when we were at Caffeine Spaces in Boca Raton, someone wrote this on the dry erase board.  It has a lot of meaning to me and can be applied to so many aspects of building out a website or mobile app from design, functionality, marketing, architecture and other aspects of these tech start ups.  I am focused on product management in this context.  (but I could write another article on any of those disciplines)

Feature Junkie

It has a lot of meaning to me because I am a feature junkie. Everytime I come up with a new product or concept, I can think of  a million cool features.  This is what we do as creative people and when you combine that with a technologist, more specifically a web developer, you can have a thousand little features that are cool and different and meant to change the world, even a world within a world.  But overall, what you are doing with complexity sometimes, is really showing off your ego.    We all want to show off what we can do, how smart we are, and we are, but not always in business.  Trust me, it’s my downfall.  In web product management too many features and quite often the wrong features can be the death of a product or at least delay it indefinitely before it goes live.

What’s The Delay And I Want It All Now!

Now, if you think about it, how can you produce all these features when your time is limited.  That is not the real question.  The real question is what features are really needed first, and what features can’t wait.  I can’t really expound on the features in Krowde that I am talking about, but I can come up with an imaginary app that I probably will never create.  Let’s call it Park Finder, and let’s say it was being built for iOS and Android.

Anyway,  you have spec’d out the mobile app.  You have come up with a dozen great features from a map with icons, a search of that map, a link to that park’s page, a listing and a small profile per park, the ability to share that Park with your friends instantly via Facebook, Linkedin, Twitter, an ability to talk about that park, an ability to upload pictures about that park for others to see, rate that park, a list of parks by ratings, park contact info, park office instant chat.  Wait a second!  Park office instant chat.  That needs to go into the list of “Would Like” stuff.  And that is the issue.  In fact, that list has a lot of cool stuff, but ultimately his park finder app could actually be live and working with just 3 features, a search, a map and a link to the website for that park.  All the other park finder features sound so good in your head and they are, but the customers don’t know what they don’t know.

Customers Don’t Know What They Don’t Know

I like saying this line and it has come back in many conversations, because it is really important and tied to the simplification concept.   The second issue with product complexity occurs in the mind of the technology founder.  Sometimes they think that more is better.  They think that the value increases with number and breadth of features.  But it is not exactly the same for the customer or customers.  Customers don’t always think the same or use the same features.  When only 5 out of 1000 users used that feature, then of course it was not very important.  Also, from a development standpoint, what about getting the thing finished and out to the market.  That is what is important.

Timing

Getting the Park app out into the market, with limited features is the best way to do it.  It is what Fried says in Rework, Brad Feld says in his blog and it makes common sense.  If you want to get your product out there and in the market, only include at first the core features, the features that make your product usable.  It will not fail because it does not have all the final pieces and bells and whistles you envision.  It may be that the park finder app may have been well received and done very well with only these basic features.  You have the time to add new features after that.  Add your sharing, commenting, rating and other features later on.  It is painful, but worth it and the difference in your app making or not making it to market.

What Can I Live Without?

In the end people are the problem, because even I have fallen into the “I want it all” trap.  And then I was the problem. You think you can have it all, but sometimes more doesn’t necessarily sell your product.  Sometimes less does.  Sometimes doing a small thing well is more critical than anything.  There are products and services that are bigger, feature rich, etc, but they are not for the small boot strapped start-up.  There is a cost associated with more, and sometimes those features never amount to anything or any usage.  The people you can’t always control, because they may be in charge and have the purse strings.  But at least you understand yourself what the issues are, and can say to yourself, what can I live without?