Summary
We launched Frugal Mechanic in the summer of 2008 and operated it until 2019 or so. By mid 2014 and early 2015 we had started doing some work for Opticat and TecAlliance leveraging the technology that was developed at Frugal Mechanic. By the summer of 2015 we were doing full-time work for TecAlliance under our Eluvio DBA.
Details
A friend and I who were both laid off from SecondSpace along with a third person who was still working at SecondSpace founded Frugal Mechanic. At a high level it was a comparison shopping site focused on automotive parts. You could select your vehicle year, make and model to find matching parts. You could also search by part number.
We launched the site during the summer of 2008 and had some early success with SEO traffic and had started to generate some revenue. In early 2009 we raised money from Founders’ Co-op.
Features
Retailers would usually modify the manufacturer part number to prefix some sort of brand identifier. They would also sometimes use entirely different part numbers (e.g. reatilers using Worldpac). We did a lot of work to match up these part numbers across retailers to make it easier for the consumer to compare pricing.
Over time we added features like:
- Shipping costs
- Tax information (based on zip code)
- Retailer Coupons (which were automatically included in price comparisons)
Example Pages
Frugal Mechanic no longer exists. A spammer snatched up the domain when it expired and attempted to clone some of our old pages with added spam links.
Here are some examples of what it looked like originally via the Internet Archive:
Screenshots
Ruby on Rails and Java
The website front-end was originally written in Ruby on Rails with the backend written in Java.
As the website evolved over time the Ruby on Rails code became painful to manage. The Java code was also not ideal because it was very verbose. At some point I came across Scala which seemed like it had the best features of both Ruby and Java. Eventually everything was re-written in Scala.
Scala
Scala made up probably 90% of the code at Frugal Mechanic. I ended up writing many Scala libraries
SEO
We had a lot of initial success with SEO traffic. We spent a lot of time making sure our website was SEO friendly following all of the various tips and tricks that we could find at the time. We tried to avoid any dark patterns that were questionable to avoid any Google penalties.
Attack of the Blog Spam!
We found Google de-prioritizing our website and instead prioritizing spam blog sites. In many cases these blog spam sites were scraping our website and showing part and pricing information from our detail pages as dummy blog posts. You could easily tell that these sites were 100% junk. There were even references to Frugal Mechanic on their pages that were directly taken from our page titles and descriptions. Yet Google thought these sites were higher quality than our website. Good job Google!
SEM
We were managing over a million keywords across 20+ accounts via the AdWords API.
With the SEO no longer working out we made the pivot to SEM. In hindsight we should have branched into SEM earlier but I guess the thinking was: why pay for traffic when we were getting it for free? After some successful experimentation, I built out an entire SEM management system for both Google AdWords and Microsoft AdCenter.
There were not many people bidding on automotive part numbers so our strategy was to place minimum bids on all of the various SKUs we had. AdWords accounts were limited to about 50,000 keywords so we ended up needing 20+ accounts to manage all of our keywords. We were careful to make sure we followed all of Google’s policies and setup everything up with guidance from them. Everything was linked under an MCC account.
SEM worked great for us! People searching for part numbers were usually looking to price compare and purchase the part. So we had a very high conversion rate for SEM clicks. We occasionally had part numbers that overlapped with non-automotive products that people were competitively bidding on. Fortunately our minimum bid strategy prevented us paying too much for those searches. We were managing over a million keywords across 20+ accounts via the AdWords API. We had a similar setup for Microsoft AdCenter but it was only a fraction of the traffic that Google was sending us.
One annoying thing about the AdWords API was that every other year or so Google decided that they needed to break the API in non-backwards compatible ways. This usually meant re-writing how we made use of the API to match whatever new model they had.
Over time Google started to discourage the long tail minimum bidding strategy that we were using. They did not really want our million keywords that were low volume with minimum bids. They wanted us to bid on more popular keywords higher volume keywords that people were competitively bidding on. They would prefer we bid on something generic like “fuel pump” which would have cost us more while having very poor conversion rates.
Unfortunately our SEM traffic diminished over time due to Google not showing ads for the low volume long tail keywords. We tried to adapt by smartly increasing bids on products that were making us more money.
SEM, now with machine learning!
I implemented some machine learning (via Weka) that would take all of our click and revenue data, group together similar parts and attempted to predict how much we could bid and still make money for each keyword. This worked okay but we still were not making as much as our original minimum bid strategy.
ACES and PIES Data
All of our original product data came from the retailers via a combination of data feeds and scraping. Over time we started getting ACES and PIES data from the manufacturers. This was either directly (email or FTP) or via one of the industry data repositories like Opticat or SEMA Data Co-op.
We attended SEMA and AAPEX in 2009 and walked around to all of the manufacturer booths asking for their ACES and PIES data. We were wearing t-shirts with the Frugal Mechanic logo on them and had a really nice looking flyer with information about who we were and why they should give us their data.
We got some ACES and PIES data out of that trip but the people at the booths were mostly sales people. Some knew to direct us to their data person and others had no clue what we were talking about.
Opticat
We became a data receiver on the Opticat (now JNPSoft Opticat) platform which allowed us to request ACES and PIES data from manufacturers who were also part of the platform. Whenever a manufacturer uploaded new data OptiCat would send it to our FTP site. Using OptiCat along with SEMA Data Co-op (which functioned similar to Opticat but with a focus on the specialty equipment market) was a much more efficient for both us and the manufacturers. Instead of manufacturers needing to directly send us data, all they had to do was check a box in the OptiCat (or SEMA Data Co-op) system.
Opticat took notice of our website and was impressed by how fast and easy to use it was. They wanted a website like Frugal Mechanic but using their data. This led to Eluvio.
By this point Frugal Mechanic was shifting into maintenance mode as we started to move into consulting work for Opticat and TecAlliance via our Eluvio trade name.
Frugal Mechanic d.b.a. Eluvio
Opticat took notice of our Frugal Mechanic website and was impressed by how fast and easy to use it was. They wanted a website like Frugal Mechanic but using their data. And since they were a data repository they had a lot of data! So in the summer of 2014 we agreed to use our technology to build them a website. OptiCat OnLine (Archive.org did not capture the styling so the page does not look very good) was born and ready to launch at the 2014 SEMA and AAPEX show. But there was just one problem…
We had a “Powered by Frugal Mechanic” link in the footer. Some of the OptiCat stakeholders (who were mostly auto part manufacturers) saw this and did not appreciate being associated with a comparison shopping site that had their parts on it. Whoops! There was a big panic at Opticat and talk of taking the site down over the situation. So we setup “Eluvio” as a DBA of Frugal Mechanic and changed the footer link to be “Powered by Eluvio”.
Everybody was happy and the site was successfully presented at SEMA and AAPEX 2014!
TecAlliance
Opticat showed their parent company TecAlliance what we had done for them. TecAlliance wanted the same thing except using their data!
Opticat was focused on the North American market which was using the AutoCare data standards. TecAlliance was focused on Europe and other areas outside of North America. TecAlliance used the TecDoc data standard (which they fully controlled). Unlike the North American market where you had multiple competing data repositories (e.g. Opticat, SEMA Data Co-op, etc.), TecAlliance was THE data repository for Europe. If you were dealing with aftermarket automotive parts in Europe then you were probably a customer of TecAlliance (either directly or indirectly).
At the time, TecAlliance already had an internally developed catalog website built on top of their TecDoc webservice. Unfortunately the webservice was slow, unreliable and clunky to use. The webservice was called directly by the browser (the catalog website might have been an SPA) with some pages requiring multiple webservice calls. When you added in all of those round-trips back to their datacenter in Germany the catalog website was especially slow for anybody outside of Europe.
We were in talks with a new Vice President at TecAlliance along with the Product Owner of the existing catalog website and webservice. They had some issues dealing with their internal development teams which led them to talk to us. They had a trade show in Brazil that was a few months away and wanted to debut a new fast and easy to use catalog website for the Brazil market. They were a little hesitant given the short timeline and uncertainty that we could deliver. But we sweetened the deal by saying:
If we can’t deliver in time for your trade show then you don’t pay us
This made it very little risk to them so it became an easy sell. Unfortunately that made it a lot riskier for us! We were working with an entirely new data model with very complex business rules.
Fortunately, we were able to deliver! It was a very busy few months trying to figure out the data model, business rules, building out an entirely new backend and website. But we delivered on time for the trade show in Brazil and everybody was very happy. The site was being hosted from my house and everybody was impressed by how quick the site was even though they were accessing it from Europe and Brazil.
After the successful Brazil catalog launch TecAlliance was asking us if we could also re-implement their TecDoc webservice using our technology. They had stability and performance problems with their current TecDoc webservice that they were unable to resolve internally. After some back and forth we finalized an agreement to re-implement and host their webservice.
Shortly after finalizing that agreement TecAlliance asked us what it would take for us to just work full time for them. That eventually led to us being acqui-hired by TecAlliance. We entered into an agreement where we would work full time for them and they would pay to license our technology. The licensing fee was used to buy out our Frugal Mechanic investors, Founders’ Co-op, and provide a them a return on their investment. We felt good about that!