Building DailyKilobyte - The Research

Before late of 2017, DailyKilobyte was a hobby website for me to fool around. It was once a full blown lawn care service website that I build to test to see if I could get any service requests. To my surprise, within four days of being a lawn care service website, it received its first service request which I turned down due to not knowing anything about lawn care or owning any types of equipment to do so. I think my excuse was that we’re at full capacity and could not accept more clients until so and so date. This project went on to receive a few more service requests in the 30 days or so before I shut down the site. I went on to build out a few more websites after that.

Sometimes in the mid of 2017, I had an idea to turn DailyKilobyte into a deals finder site. I am an avid deals seeker, and I buy a lot of stuff. My family and friends ask me to look out for the things that they want to buy all the time, I thought I could build something like this.

I began to put a plan in the process of how I could go about building a site like this. As I studied and searched through all the places that I use to find these deals, the only thing I notice is that they’re all different in the way they present themselves and in the way they show the deals. I knew studying those sites isn’t going to take me anywhere, so I just slab a default Wordpress site up and began post deals that I am into.

A week into posting these deals, I started to get fatigue because it was taking way to much time to post a deal. It was becoming more of a chore than anything by week two. By week three, I was on autopilot and that was also when I began to see common patterns. My number one focus at this point was to reduce the amount of time it takes to post a deal. Initially, it would have taken me at least 5 minutes to post a deal and then down to 2 or 1 by week three. It’s still a lot of time.

Being a developer, I know there just got to be many different ways I can do to solve the issue. First, I wanted to build an API that interacts directly with the database. At the time, I have the knowledge that Wordpress has a restful API plugin. Of source, I scraped the idea of building an API to interact with the database, and change it to creating an API to interface with Wordpress API itself. With my custom API, I would script out the language of the deal and would only require specific data attributes to be able to post a deal.

Building a custom API to interface with Wordpress API was simple, the issue is Wordpress API itself. Authentication is very flaky. I spent more time setting up the authentication than building the custom API. Once the handshake process between my custom API and Wordpress is resolved, posting a deal takes less than five seconds.

My next thought was to redesign the frontend to make it look semi-decent, halfway through the design I notice that there’s no easy for me to do this properly without having proper access to the data attributes first. I went back to the API and start adding custom fields to the post so I could reference them in my new theme, and it works. As I spend more time doing front-end, I began to ask myself if I want to continue using WordPress and make improvements to it? Or am I using WordPress as a research platform so I can see common patterns when running a deals site? The answer is the latter. So I skip the whole redesign thing and just focus on understanding the data and the patterns.

I’ve since made tons of improvement to the API. I think the next step for me to build a new CMS to replace Wordpress with more specific needs for a deals site.

Until next time…