The Amazing Adventures of Building Squidoo
Ranked #3,525 in Education, #81,216 overall | Donates to Squidoo Charity Fund
About Squidoo
Founded in mid 2005, Squidoo quickly gained traction as a platform for sharing ideas online. Squidoo makes it easy to share your passions—hobbies and interests and stuff for sale and ideas worth spreading. As of January 2012 we're a Quantcast Top 100 site reaching over 1.5 million people every day.
With just a tiny full-time engineering team of three, we think it's pretty incredible to keep such a high traffic site online while also managing to release new features and bug fixes on a regular basis. And so I thought it'd be interesting to share a little background on our engineering efforts , the technical challenges we've faced, and how we got to where we are today. Enjoy!
With just a tiny full-time engineering team of three, we think it's pretty incredible to keep such a high traffic site online while also managing to release new features and bug fixes on a regular basis. And so I thought it'd be interesting to share a little background on our engineering efforts , the technical challenges we've faced, and how we got to where we are today. Enjoy!
What's Here
The Starting Point
Summer, 2005
Here we were—sitting in a small, sparsely furnished room, discussing how we were going to build a new platform (and ultimately, an ecosystem, a community) which we dreamed would change the way people find things online.
From the beginning we knew the traditional approach wouldn't work. We had a tight schedule, yet we had no VC money or plans for hiring a massive staff. How would we accomplish such lofty goals with such a tiny budget?
From the beginning we knew the traditional approach wouldn't work. We had a tight schedule, yet we had no VC money or plans for hiring a massive staff. How would we accomplish such lofty goals with such a tiny budget?
Choosing a Platform
Squidoo's first stage of development began in the fall of 2005. At the time, Ruby on Rails was starting to emerge as a dominant force in what was only recently being dubbed Web 2.0. Although we considered using Rails, it was still a relatively immature and unproven technology platform (boy, a lot has changed since then). We chose PHP in its place. Since PHP goes hand in hand with Linux, Apache, and MySQL, adopting the entire LAMP platform was a no-brainer.Choosing PHP—with its extensive documentation, ubiquitous server support, abundance of third party libraries and API wrappers, and optimizable speed—was a reasonable decision. PHP has its detractors, but with the right architecture and proper discipline in place, it has no shortage of potential for driving high-powered web applications (just ask Facebook).
CakePHP, Zend, and other PHP MVC frameworks were just a glimmer in a developer's eye when we began building Squidoo, so we had to roll our own. Today our custom framework supports all of the features a modern MVC framework should: routing, logging, caching, APIs, robust templating, etc.

Diagram of MVC (Model View Controller) architecture
Beginning Development
Setting up a team
To keep our staff as lean as possible, we considered several options, ultimately leading to a parnership with Viget Labs, who helped us build version 1.0 of Squidoo.Hiring in-house employees vs an outside consulting firm can be a difficult choice for any startup. On one hand, hiring employees can be a great (and sometimes inexpensive) way to ensure dedication to your project, but the security of fixed cost development and no long-term employee commitments proved to be the right choice for us.
Working closely with Viget's designers and developers, we created and managed a constantly evolving wiki that served as our team's development guidelines. The wiki technology actually turned out to be a great asset during development, allowing our team to iterate through new design ideas without waisting valuable time reconstructing a more formal specifications document. The same wiki system is still in use today, and remains a hub for our project planning and software specs.
We quickly established a habit of 2 week development iterations. On every third week our aim was to lock down a feature list for the next iteration as quickly as possible, reserving the latter part of the week for deploying updates, testing code, and fixing bugs. This approach allowed us to prototype new features and release them into the wild with lightning speed.

What a two week iteration looks like
Servers, servers, servers
In startup mode most employees wear multiple hats, and my role included not only development, but designing and configuring our server installation as well.
While I had maintained my own servers for years, I had relatively little experience with high traffic, high availability server clusters. To be on the safe side, we figured it wise to find a partner who could help fill in the gaps when it came to tough technical issues. That partner became Rackspace, a managed hosting provider well-respected for their focus on "fanatical support". Although their services come at a significant premium, Rackspace helped us navigate effortlessly through a number of technical hurdles.
With several high profile launch announcements, we expected traffic to grow quickly. To make sure we were properly prepared, our initial setup included a four server configuration: 1 staging server, 2 web/app servers, and 1 database server. Although a software-based load balancer was considerably cheaper, we chose a Cisco hardware appliance to split the load between our web servers—wary of the downtime required during the inevitable upgrade from a software to hardware-based solution once traffic demanded it.
In retrospect, configuring two web servers may have been premature optimization. Although our usage quickly grew to full capacity on both servers, the effort involved in synchronizing the two systems was tedious and error-prone.
With two web servers, we began running into all sorts of filesystem-related issues. We installed Unison (a two-way rsync) to synchronize our session data and lensmaster-uploaded images.
While I had maintained my own servers for years, I had relatively little experience with high traffic, high availability server clusters. To be on the safe side, we figured it wise to find a partner who could help fill in the gaps when it came to tough technical issues. That partner became Rackspace, a managed hosting provider well-respected for their focus on "fanatical support". Although their services come at a significant premium, Rackspace helped us navigate effortlessly through a number of technical hurdles.
With several high profile launch announcements, we expected traffic to grow quickly. To make sure we were properly prepared, our initial setup included a four server configuration: 1 staging server, 2 web/app servers, and 1 database server. Although a software-based load balancer was considerably cheaper, we chose a Cisco hardware appliance to split the load between our web servers—wary of the downtime required during the inevitable upgrade from a software to hardware-based solution once traffic demanded it.
In retrospect, configuring two web servers may have been premature optimization. Although our usage quickly grew to full capacity on both servers, the effort involved in synchronizing the two systems was tedious and error-prone.
With two web servers, we began running into all sorts of filesystem-related issues. We installed Unison (a two-way rsync) to synchronize our session data and lensmaster-uploaded images.
Launching Our Beta
December 2005
I screwed up. After our first few encounters with the blogosphere, we managed to compile a list of enough interested participants to begin a limited beta. Sure, our product was still a little buggy, and definitely needed some improvement, but it was finally ready to be tested by real, live humans. The mailing list was compiled, the email copy was written, and the beta invitations were sent....three times.It was as public a statement as we could make that what we were offering was truly a beta product. And although we quickly learned from the mistake and added "take more care" as our mantra for potentially dangerous tasks, to this day I still haven't recovered from the anxiety of emailing large groups of people. If you've ever wished you could take back an email you wrote, you know what I mean. Daily Candy and Photojojo, I don't know how you do it.

A full page spread in the local paper
Making the Transition
Finally, in March 2006, our beta was complete. The world was ours.
Our contract with Viget had just ended, and it was a difficult time for us. Suddenly it was just down to one designer (Corey) and developer (myself). Our platform wasn't anywhere near complete, and we had enormous goals to extend it with a plethora of new features.
Although I worked closely with Viget while developing our beta, there was still a significant learning curve in getting up to speed with the system (at that point it was approaching nearly 50,000 lines of code). Luckily, their team was very supportive during this process.
Hat tip to Ben for putting up with my hourly IM conversations, which usually went something like "So I'm building an Ajax call for saving tags from the profile page. Which controller do I put that in again?" Frustrating for him, but it didn't take me long to get the hang of things.
The larger issue was how to balance new development with resolving bug reports, responding to our community, recruiting freelance developers (for smaller projects), and, last but not least, marketing!
We struggled initially, but over time we were able to find a development process that worked for us, and things were just peachy...for a while.
Our contract with Viget had just ended, and it was a difficult time for us. Suddenly it was just down to one designer (Corey) and developer (myself). Our platform wasn't anywhere near complete, and we had enormous goals to extend it with a plethora of new features.
Although I worked closely with Viget while developing our beta, there was still a significant learning curve in getting up to speed with the system (at that point it was approaching nearly 50,000 lines of code). Luckily, their team was very supportive during this process.
Hat tip to Ben for putting up with my hourly IM conversations, which usually went something like "So I'm building an Ajax call for saving tags from the profile page. Which controller do I put that in again?" Frustrating for him, but it didn't take me long to get the hang of things.
The larger issue was how to balance new development with resolving bug reports, responding to our community, recruiting freelance developers (for smaller projects), and, last but not least, marketing!
We struggled initially, but over time we were able to find a development process that worked for us, and things were just peachy...for a while.
Server Gremlins
One day, out of the blue, all of our servers just crashed. I couldn't login from the command prompt, and we called Rackspace to manually reboot them. Once rebooted, the site ran normally, and I could find no trace of what happened.Everything was fine for a few days, but then it happened again. And again. And again. It seemed we could only keep our servers online for a few hours at a time without requiring a hard reboot. At this point, it's safe to say I was seriously considering the benefits and lack of responsibility that come along with delivering pizzas for a living.
We soldiered on, and with a few days of effort and the help of a guru from Rackspace, we were able to trace the problem. A few new Squidooers had unwittingly added RSS modules which linked to the RSS feeds of their own lenses. When a surfer visited one of these corrupt lenses, the RSS module would update by visiting the lens, which would update the RSS module, which would visit the lens, which would update the RSS module...ok I'm going to stop now, because all this recursion is making me dizzy.
Once we found the culprit it was an easy fix. The RSS module now carefully screens for self-referencing feeds, preventing the same disaster and keeping the servers online so lensmasters can do their thing.
Like a Slug
Although we had already spent some time optimizing the database layer (by being picky about the data we selected, creating indexes, etc), the database just couldn't keep up. Squidoo was crawling. We weren't database experts, but once again Rackspace came to the rescue. It turns out that even though we had a dedicated MySQL server, only small portions of its available resources were being used.
With a few quick tweaks (to the key buffer, innodb buffer, table cache, and a few others), Squidoo was flying again. Even better, our database server was a good sport and didn't even complain about the extra load. Thanks, db1.

Squidoo accepts an award at SXSW 2007
Spam: The Internet's Worst Nightmare
By June 2007, fresh from winning an award for "best community site" at SXSW, Squidoo was in great shape. Our traffic was continuing to grow, and, if I got lucky, at least one person at every party I went to had at least heard of us (note to new startup founders: perfect your elevator pitch, because you're going to be using it a lot).
Things were going so well, in fact, that spammers started to notice. Within the course of a few short weeks, an enterprising spammer began massively polluting the blogosphere with links pointing to their Squidoo lenses. The spammer exploited the fact that we allowed <iframe> tags for more flexibility. In this case it proved too flexible, and the effect was that clicking on a link from a blog would bring you to a Squidoo lens, but immediately redirect you to a site that hosted—you guessed it—pornography.
The method used by the spammer made it appear that Squidoo was somehow affiliated, and shockwaves rippled throughout the blogosphere. We got a fair amount of heat, but did our best to remedy the situation as quickly as possible. Soon after, I posted followup notes explaining our position on spam and the new steps we were taking to keep Squidoo spam free. But the damage was done.
Lesson learned. Spam is a major problem on the internet, and in an age where reputation is everything, organizations can't afford not to have an aggressive anti-spam policy.
Things were going so well, in fact, that spammers started to notice. Within the course of a few short weeks, an enterprising spammer began massively polluting the blogosphere with links pointing to their Squidoo lenses. The spammer exploited the fact that we allowed <iframe> tags for more flexibility. In this case it proved too flexible, and the effect was that clicking on a link from a blog would bring you to a Squidoo lens, but immediately redirect you to a site that hosted—you guessed it—pornography.
The method used by the spammer made it appear that Squidoo was somehow affiliated, and shockwaves rippled throughout the blogosphere. We got a fair amount of heat, but did our best to remedy the situation as quickly as possible. Soon after, I posted followup notes explaining our position on spam and the new steps we were taking to keep Squidoo spam free. But the damage was done.
Lesson learned. Spam is a major problem on the internet, and in an age where reputation is everything, organizations can't afford not to have an aggressive anti-spam policy.
How We Fight Spam Today
A Fused Approach
Over the years we've discovered a number of signals that indicate a high likelihood of spam. The catch is that any one signal can also include legitimate content. To raise our confidence level for identifying spam, we've developed a complex system called FUSE that combines all of these signals into a spam likelihood score.
Content believed to contain spam is never allowed to publish at all. While the algorithmic approach is highly effective, we also have a team of human reviewers scouring Squidoo daily.
Content believed to contain spam is never allowed to publish at all. While the algorithmic approach is highly effective, we also have a team of human reviewers scouring Squidoo daily.
How We Handle Customer Service
With so many users, it's only natural that customer service is going to be a big issue.
On the technical end, more users means more opportunities for running into obscure bugs, and when major ones hit it means responding can take a long time.
Our "release early and often" philosophy means that we get plenty of feedback from users on new features (sometimes within minutes of deployment).
In addition, keeping spam at bay is a major concern. Although we have a number of automated tools designed to block spam before it starts, we also rely on the community to report suspect activity.
All this leads to lots and lots of feedback. To save our sanity, all feedback is filtered through FogBugz, where our wonderfully dedicated customer service supervisor helps with common customer service issues, filtering and prioritizing any remaining bug reports, which then get sent to our development team. We also have a dedicated anti-spam editor who reviews spam reports (and other suspicious activity) and takes action as necessary to keep Squidoo a safe, well-lighted community.
On the technical end, more users means more opportunities for running into obscure bugs, and when major ones hit it means responding can take a long time.
Our "release early and often" philosophy means that we get plenty of feedback from users on new features (sometimes within minutes of deployment).
In addition, keeping spam at bay is a major concern. Although we have a number of automated tools designed to block spam before it starts, we also rely on the community to report suspect activity.
All this leads to lots and lots of feedback. To save our sanity, all feedback is filtered through FogBugz, where our wonderfully dedicated customer service supervisor helps with common customer service issues, filtering and prioritizing any remaining bug reports, which then get sent to our development team. We also have a dedicated anti-spam editor who reviews spam reports (and other suspicious activity) and takes action as necessary to keep Squidoo a safe, well-lighted community.
Breaking It Down
The key to creating a scalable application is designing an architecture that can be broken down into bite-sized chunks.
When our application servers started working overtime, we offloaded images and other static content to a lightweight web server (lighttpd) and optimized it for caching. No longer having to serve up a dozen or more static files with each request, our app servers gained a little breathing room.
When our Javascript codebase kept growing, we minified it into one tiny, compressed file. Now there are fewer web requests and less code to download.
When our database started slowing down, we installed memcached and scrutinized our model classes to cache everything possible. The result was a faster Squidoo.
When our application servers started working overtime, we offloaded images and other static content to a lightweight web server (lighttpd) and optimized it for caching. No longer having to serve up a dozen or more static files with each request, our app servers gained a little breathing room.
When our Javascript codebase kept growing, we minified it into one tiny, compressed file. Now there are fewer web requests and less code to download.
When our database started slowing down, we installed memcached and scrutinized our model classes to cache everything possible. The result was a faster Squidoo.
Batch Processing & Queues
With our growing data size, some computations are just too slow to be performed in real time. Tasks like updating our search index, recalculating LensRank, and processing payment, are now performed on independent servers with more resources to spare.
A queueing system allows us to perform slower tasks (like purging our caching servers after publish) in the background without slowing down lensmasters.
A queueing system allows us to perform slower tasks (like purging our caching servers after publish) in the background without slowing down lensmasters.
Now Accepting Your Feedback
Did I miss something? If you have any questions or comments please feel free to comment below.
submit
-
Reply
-
i-PhoneDeveloper
Feb 7, 2012 @ 6:52 pm | delete
- very nice
-
-
Reply
-
Zut_Moon
Feb 6, 2012 @ 9:23 pm | delete
- Nice ...
-
-
Reply
-
---Chazz
Feb 3, 2012 @ 10:55 am | delete
- Thanks for the history lesson. Very cool. Glad to learn about the early days and congrats on your amazing accomplishments.
-
-
Reply
-
squidyou
Jan 24, 2012 @ 6:59 am | delete
- So nice to hear about the history of Squidoo.. nice to meet you too!
-
-
Reply
-
sherridan
Jan 17, 2012 @ 6:33 pm | delete
- ...............and the rest is history! Really interesting to hear about the initial difficulties.
-
-
Reply
-
favored1
Dec 23, 2011 @ 2:15 am | delete
- Nice to know how you all came together in the making of Squidoo.
-
-
Reply
-
manlalakbay
Dec 3, 2011 @ 12:10 pm | delete
- Thanks for presenting the history of Squidoo. =)
-
-
Reply
-
TheGourmetCoffeeGuy Nov 27, 2011 @ 1:26 am | delete
- One of the coolest and most interesting lenses I've read! Really neat to get a "look behind the scenes" -- thank you for sharing!
-
-
Reply
-
WebaliciousGuides
Nov 26, 2011 @ 10:26 am | delete
- It was really interesting to read about how Squidoo was set up, thanks for sharing the story.
-
-
Reply
-
RenaissanceWoman2010
Nov 23, 2011 @ 9:18 am | delete
- What an amazing ride. Impressive... all that has been accomplished. Kudos to the team!
-
-
Reply
-
ShoeCleaner
Nov 18, 2011 @ 7:21 pm | delete
- Great read on the start of Squidoo.
-
-
Reply
-
technospunky
Nov 15, 2011 @ 1:36 pm | delete
- Thank you for posting it!
-
-
Reply
-
LeCordonDude
Nov 9, 2011 @ 9:03 pm | delete
- WOW!! You guys are like Jedi to me!! It's great to have a history of the Order in the Archives! :0)
-
-
Reply
-
SIALicenceUK
Nov 4, 2011 @ 7:41 am | delete
- Very interesting to find out how squidoo got started.
-
-
Reply
-
WayneDave
Oct 26, 2011 @ 12:11 pm | delete
- So interesting to read. Like Expert Presenter said, good see some behind the scenes information! Thanks a lot for sharing this.
-
-
Reply
-
ExpertPresenter
Sep 17, 2011 @ 9:57 am | delete
- Good to read the behind the scenes at Squidoo. This is a great site that's made self-publishing into a "fun game." I'd love to see more in-depth business-oriented topics. Some of the stuff is a bit too vanilla and elementary; but that's why we're here!
-
-
Reply
-
howel
Sep 15, 2011 @ 9:44 pm | delete
- I read the above with a feeling of admiration - obviously the end (perhaps current is a better word) result is impressive, but from my point of view, the vision and the perseverance is admirable.
-
-
Reply
-
manchester Aug 14, 2011 @ 11:54 am | delete
- I think what's been achieved here is great. In spite of Squidoo attracting spammers and similar, the quality standards here are high and it's my absolute favourite user generated content platform on the web.
Great job... and I love the monsters!
-
-
Reply
-
cbessa
Jul 26, 2011 @ 8:44 pm | delete
- Hey, man, great work you guys have done here. Really inspiring.
Im not an architeture or programmer but know a little bit of server and programming. Been trying to put together an small bloggers pool (20 bloggers) on my own VPS and i've been having a hard time.
But, the work you guys have done here is so inspiring that I keep learning. at least, enough to understand the challenges i will face in some projects i have. Nothing as big as Squidoo, but sure inspired by.
Thanks!
-
-
Reply
-
GayleMcLaughlin
Jul 8, 2011 @ 9:29 pm | delete
- I didn't understand all of it, but it was certainly interesting to learn about how Squidoo was started!
-
-
Reply
-
bercton
Jun 12, 2011 @ 8:17 am | delete
- Great platform for developing and identifying writing talent. I give it the x factor.
-
-
Reply
-
vallain
May 23, 2011 @ 2:17 pm | delete
- A fascinating glimpse into Squidoo's back room. I can't begin to understand all the tech details, but it satisfied my curiosity about how it was started.
-
-
Reply
-
sluggasteve May 21, 2011 @ 1:56 pm | delete
- Way to steal my idea. Lol. Good for you man.
-
-
Reply
-
PeteSchultz Apr 13, 2011 @ 9:24 am | delete
- Over my head, but I had to check it out. I enjoy posting info to Squidoo and creating lenses....how it happens is smoke and mirrors as far as I'm concerned.
-
-
Reply
-
garrekds
Apr 4, 2011 @ 8:15 am | delete
- I always enjoy hearing about what goes on behind the scenes at companies I like. Thanks for sharing!
-
-
Reply
-
huvalbd
Mar 24, 2011 @ 3:08 pm | delete
- Really enjoyed this, especially the liberal sharing of technical and logistical details. Thanks!
-
-
Reply
-
sorana
Mar 18, 2011 @ 9:55 pm | delete
- Very interesting. Thanks for Squidoo; it's a great platform.
-
-
Reply
-
JoyfulPamela
Mar 17, 2011 @ 7:42 pm | delete
- Cool! I adore Squidoo, so thanks so much for helping to create it!! =D
-
-
Reply
-
WateredGardenCreations Mar 9, 2011 @ 8:40 am | delete
- What a great story. Thanks for all your work at Squidoo. It is truly appreciated.
-
-
Reply
-
miaponzo
Feb 16, 2011 @ 2:41 pm | delete
- Just want to say thanks for Squidoo :)
-
-
Reply
-
hotbrain
Dec 27, 2010 @ 8:23 pm | delete
- This is an excellent lens with great information about the development of Squidoo. It's a great platform and I plan to be on it for as long as the focus is quality :)
-
-
Reply
-
Luminosity
Dec 13, 2010 @ 6:58 pm | delete
- Thanks for creating a community platform where a multitude of people can benefit from it's beneficence.
-
-
Reply
-
LabKitty
Nov 9, 2010 @ 6:17 pm | delete
- It's great to get the inside story from one of the architects. Great job. Now all you need to do is fix that bug that keeps people from finding our stuff :-p
-
-
Reply
-
capriliz
Oct 28, 2010 @ 11:02 pm | delete
- An amazing story! Thanks for everything. I think Squidoo is wonderful.
-
-
Reply
-
Tipi
Oct 8, 2010 @ 11:20 am | delete
- Thanks for all that you do Gil! ~ I love Squidoo.
-
-
Reply
-
JollyvilleChick
Oct 8, 2010 @ 1:14 am | delete
- From a Lensmasters' point of view, you've made Squidoo quite easy to use. It's a nice blend of default modules but you give us room to customize it with a little bit of code. If you come back to Austin for another SXSW, how about a Squidoo meet-up!
-
-
Reply
-
jptanabe
Sep 24, 2010 @ 1:18 pm | delete
- Fascinating to read how Squidoo got started!
-
-
Reply
-
Christene
Sep 8, 2010 @ 11:46 am | delete
- Blessed by a SquidAngel :)
-
-
Reply
-
skiesgreen
Sep 1, 2010 @ 11:58 pm | delete
- Wonderful of you and the rest of the squad to do this and for you to explain it so well. It has become a major part of my life now and has grown into a wonderful community of friends and good relationships. *-*Blessed*-* and featured on Sprinkled with Stardust
-
-
Reply
-
QueSea
Apr 13, 2010 @ 7:53 pm | delete
- Thanks for the history. You and the rest of your team do a bang-up good job!
-
-
Reply
-
QueSea
Apr 13, 2010 @ 7:50 pm | delete
- Thanks for sharing the history. I'm not programmer, but I'm very interested in how Squidoo came into being. You and the rest of the team are doing a bang-up good job!
-
-
Reply
-
planproject8
Mar 9, 2010 @ 8:43 am | delete
- Really it's a great lens. Some valuable suggestion contain in this lens. Here are also some essential links. I think that these will be helpful for me.
Thanks a lot
-
-
Reply
-
seegreen
Feb 20, 2010 @ 8:24 pm | delete
- Interesting stuff. Perfecting an elevator speech is vital in a lot of areas and is something that people often don't think to prepare.
-
-
Reply
-
dannystaple
Feb 20, 2010 @ 2:47 pm | delete
- A good read. Having looked at community style software before, I am interested to see how you dealt with some of the challenges.
-
-
Reply
-
Timewarp
Feb 19, 2010 @ 4:47 pm | delete
- Cool to hear the technical side of Squidoo development, a great example of a lean DIY startup.
-
-
Reply
-
KarenTBTEN
Feb 19, 2010 @ 9:09 am | delete
- Wow, that was quite a read -- something I will probably share with some friends outside of Squidoo.
-
-
Reply
-
Tipi
Feb 18, 2010 @ 9:25 pm | delete
- I can hardly believe that its been almost a year since a member of Squidoo commented on this lens. I mean...WHAT? I was the first to tweet it according to the Twitter thingy, that can't be right! ~ Its getting lensrolled and promoted, featured too! :)
Thank you Gil,
Susie
-
-
Reply
-
prosperity66
Feb 18, 2010 @ 11:57 am | delete
- Joined three years ago but I'm an Angel since only one month so this is my opportunity to bless a page that any Squid newbie should read so that they learn how it all started and the work you do behind the scenes.
Blessed by a SquidAngel.
-
-
Reply
-
jgelien
Dec 31, 2009 @ 1:36 am | delete
- I was curious about how Squidoo got started. Thanks for a very interesting short history.
-
-
Reply
-
almirah
Dec 27, 2009 @ 12:35 pm | delete
- Here you are! I have been looking for how was the Squidoo developed. And how developers worked hard to make it as we what we all are enjoying now! Thank you to all the Squidoo founders
-
- Load More
by giltotherescue
giltotherescue
I'm Gil, the Chief Engineer at Squidoo.
- 8 featured lenses
- Winner of 13 trophies!
- Top lens » PHP vs Rails
Feeling creative?
Create a Lens!