Making a Website in a Day

Yes, it can be done. Building a website's no rocket science, even if you're thinking of abandoning the guider sites like Wordpress or Wix. Even if you want to code your way through, you can build a website from scratch in a day. How do I know that?

That's because I've done it! I'd made many websites in the past but it wasn't until the rush of the previous weekend that I realised this was possible. I sat down with 3 of my friends on a late Saturday morning, and we got down to it non-stop, finishing it by Sunday afternoon. Yeah, a little more than a day, but...

If you're not exceeding deadlines, you're not exceeding expectations.

I and my friends had taken part in a college Hackathon, the famous HackOnHills. Our entire journey over the weekend presents an amazing example of making a website. And mind you, the most important part in building a website is always the plan: the more organized and modulated the plan is, the faster and more efficiently the project would be completed. So let's begin!

Ideation - Defining the Problem

It's Friday evening. The four of us have gathered in a room to discuss how we'd go about the project. There's 4 people, 2 days and 1 project, and everything needs to be perfectly coordinated. But first, we must know exactly what we're making, and how it would be used. So we defined an idea:

Since the dawn of e-commerce websites in India, a lot of the offline businesses selling clothes, books and other such goods have been struggling to get customers. People are usually unaware about the location of a shop selling a certain thing that they're looking for. We need a platform to connect such consumers with shopkeepers. No concessions, no business model. We were building a simple platform that would make the businessmen interact with the consumers nearby. The consumer should be able to get all nearby shops selling the required product, based on his/her location.

Now why would the shops be interested in this idea? We definitely won't be adding all the data by ourselves. We would need the shopkeepers and the businessmen to make their own profile, and they would need a good reason to! Well, for starters, if this platform is basically to save their businesses, the very idea would serve as a good reason. But beyond that, we could win them over by integrating a billing system, so part of their data could be public, while the accounting stuff could just be visible to them. Anyway, we only had 2 days, so the billing system was phase 2.

It's a good idea to always segregate your project into phases: Phase 1 having features and ideas which you need unconditionally, and Phase 2 having ideas which you think might make your project better. This makes it easier to focus and build what is most important; also, it makes you feel like Nick Fury #MarvelReference.

Tech Stack 

Now that we knew what we were making, it was time to identify the technologies we'd be using to build the project. I had been coding for months in Node.js making APIs and smaller websites, so a comfort level in the tech was established. Abhishek, one of my teammates, was also learning about the environment and MongoDB, so the tech stack was implied. It was Node and MongoDB all the way.
(In case you're unfamiliar with these terms, read my short explanation on the Back-End technologies).
We would be using basic HTML, CSS, and JavaScript to code the front-end of the website.

Modularization and Work Distribution

We'd identified the problem, visualized our project, and decided what languages we would use. Now it was time to divide the work. 

Whether you're working alone or in a team, if you do not modularize your project, it's bound to be messy. 

What is modularization?

Modularization is the art of dividing your entire project's features and codes into smaller components and to-do's which become easy to manage. Once a project is modularized, it becomes better to visualize the code functionality, which paves way for cleaner code in each file, thus giving out a final clean product. I don't know how bigger companies operate, but I try to keep my projects as organized as possible. In such cases, I'm kind of like Monica! #FRIENDS

According to me, this very step marks the beginning of your website building. Whatever you do here will decide how much time you'd take to finish the web site. If you don't think clearly enough, you will have to pause later while coding, only to realize that you didn't think a particular case through. And that would force more changes. Of course, there are rare such cases when I don't stop in the coding phase, but such instances should be minimized as much as possible, that is, put all of your energy in modularizing the project. Still not sure how a project is modularized?

Let's take an example of Shopedia (yes, that's what we called our website)

Since it's a website, the best way to do this is through walking through the website's layouts:

There will be a Home Page, which would ask if the user is a Shopkeeper, or a Consumer. This would have two different paths. So there we have our first division. A Shopkeeper module, that takes care of everything that'll happen with the Shopkeeper, and another Consumer module, that'll do the same for the Consumer. 

Similarly, we sub-divide both these modules further into their different layouts providing different functionality, and we have many smaller modules thought of, and planned. 

The division of work becomes fairly easy now. Two of my friends, Deepesh and Gaurav volunteered for the front-end. The different front-end layouts were divided among them, and they started building the design. Abhishek would help in linking the pages with the back-end since he was quite good at JavaScript, and would look for the geo-location APIs. He also self-assigned himself to the shortest distance algorithm, which would find which of the shops were nearest to the location of the customer.

Now with most of the tasks already been taken, I was only left with building the Database Schema, and setting up the routes. 

The first step, was of course, making the Schema. A Schema is a declaration of how the data is going to be stored in the database.

If modularizing is the most important task in building websites, building a Schema is the most important one in building the back-end. 

The organization of data in the database will directly influence the ease of accessing the data as and when it is required, thereby making the back-end server 'fast' or 'slow'. In any case, this was my final Schema:

 

The entire database was for shopkeepers, and I felt extremely proud to use the Google+ API for the Login System. (If anyone is looking to build a Login System using Google, please refer NetNinja's amazing tutorial!) It just gives your application a very smooth and professional look.

A Schema, in my experience, was never perfectly built on the first try. I had to make many modifications to it as the project progressed. But again, as I said: the better you think about your project before doing it, the lesser you'll stop while coding against corner cases. So it's always a struggle for improvement. 

Setting up the routes wasn't hard at all. Ironically, it's the most fundamental part that builds a website. A site can function without a Database, but not without any routes. Yet, its the most simplistic and fun-to-do task. Here's a snippet of some routes that I'd made (these are the simplest ones :P):

If you don't understand the context of the code, it's totally fine. The point is to show how simply you can define a GET request and render HTML pages to be displayed on the browser. 

By the time I finished half my routes, the front-end team came up with an amazing template for our project! The website looked absolutely stunning!

A lot of Web Developers out there scoff at web sites based on a template. That's because they think it's copied, forgetting that the entire CS industry runs on StackOverFlow. 

If you think about this objectively, no one cares about where your web site is coming from. It's okay to build from a template, it's okay to borrow ideas from different templates and use them on your own. 

People borrow ideas from others and make a billion-dollar product out of it, you're just using an innocent template.

Unless you're a Front-End Geek who loves to design and build super-sexy web pages all day long, I'd say go for borrowing templates, there are plenty of sites up for it. To get an idea of the amazing work of Deepesh, here you go: https://shopedia.herokuapp.com/

Really sorry that it won't go beyond the login in this URL. There are certain configurations in the Google+ API which haven't been done after I hosted the site. You'd know what I'm saying here if you had seen the tutorial I suggested above.

Anyway, with some HBS templating & client-side JavaScript rendering, we finished the project at 3 pm, Sunday.

The point of this blog was not to teach you to code in building a web site. No, there are better teachers than me out there for it. I just wanted to share the amazing practice of modularizing your work, having a clear vision and an excellent team to accomplish building whatever it is that you want to.

Hope you liked it!