Few people know it, but Webconnex actually has a mascot. It’s a shark with a laser beam attached to its head. The shark pops up in various places in our company; from our first company t-shirts to laser pointers, to even our 404 pages.
The shark with a laser beam attached to it’s head has become symbolic of our pursuit of excellence in our software. If you aren’t familiar, it’s a famous reference from the movie, Austin Powers: International Man of Mystery.
I thought to take a few minutes to explain the story of how the shark with a laser beam attached to its head became our company mascot. It’s also the story of why we decided to rewrite software.
We founded our company in late 2008 and wanted to build the simplest donation and event tool possible. We wanted it to be different than other solutions. Instead of being known for all the things our software could do, we wanted to be known by what it didn’t do.
For example, we have always hated passwords, setup fees, contracts, lengthy checkout processes, and more (to name a few). Our product was known by how it didn’t have any of this stuff — things commonly found in other providers.
Our primary focus was meeting the needs of smaller organizations and let the other providers with bloated software service the large enterprises.
A funny thing happened along the way…
Not only did we get great traction with the small guys, the big guys came knocking as well. Lo and behold, billion-dollar enterprises wanted something simpler, faster and easier to customize. They were fine that it didn’t integrate with their million dollar ERP. They just wanted something that worked.
Between 2008 and 2011, we went through 3 iterations of our software culminating in the version that saw our product branch out into 4 distinct brands: TicketSpice, RegFox, GivingFuel, and RedPodium. By that time, our processing volume had reached $50M annually and had been doubling every year.
We had great product market fit, but we saw that in order to stay ahead of where the market and technology was going, we would need to rethink our software. The potential was huge, but we had some technological handcuffs that would make it difficult to get there.
To slingshot ourselves into a position where our technology could do everything we and our customers dreamed of, we came to the conclusion that a rewrite was the only way.
Let’s do this…
We set out to build a 4th version of our software, aptly called 4.0. The goal of 4.0 was to re-invent our software to not only meet the needs of our growing customer base but to re-imagine how web technology could advance the future of events and fundraising.
We envisioned a platform that was infinitely customizable, blazing fast, hyper-scalable and dead sexy. We had a dream list that was over a hundred features and functionalities long. We had storyboards for how we could reinvent how many organizations configure their events and fundraising.
In our minds, we had the most brilliant visions for the product we could ever imagine.
One thing stood in the way…
Without getting too technical, our software lives in the realm of unstructured data. Meaning, there is no form, template, model or cookie cutter for how any event page or fundraising campaign is configured. An organization is free to capture as much or as little data as they want. They can have one option or 100 variations of 100 options.
Yet the system would need to validate, store, index, report and even mutate every field and option in real time and at scale. Additionally, all this had to simultaneously work in conjunction with payment processing, editing, refunding and diff edits. To make matters even more complicated, the system would also have to reliably manage complex inventory and supply controls.
(If your head is spinning, it should be.)
Easier said than done…
We quickly learned that anything is possible until you have to build it. Our grandiose visions and feature lists would face regular reality checks when it came time to build it. No one particular functionality was hard in of itself. But, it was the combination of hundreds of workflows, settings, and functions (and future implications) that all had to work in harmony together. That was the hard part. A change or rework in one area regularly would cause a cascading effect that would require us to rethink how large portions of our software would work.
Our team experienced many highs and lows trying to build our 4.0 version.
If only we would’ve standardized (ie: restrict) the way customers create events and fundraising pages, our problems would’ve been solved. But we knew we would never be satisfied in telling our customers their efforts needed to be confined to our predetermined box.
There was a brief time where it seemed like our expectations were just too unrealistic to pull off. Luke, our longest standing developer, joked that our expectations were impossible and were tantamount to “Sharks with Frickin Laser Beams.”
We all had a good laugh.
The truth was, Sharks with Laser Beams was exactly the magnitude of awesomeness that we were committed to for the product. It had to be unimaginably awesome. But unimaginably awesome outcomes are difficult to come by.
“Good” was not good enough
We would build, iterate and test. Some things would be good, but good was not going to cut it. We were relentless in the vision: the ultimate system that would give customers more control than ever before while remaining simple, beautiful and flexible.
If it wasn’t simple, beautiful and flexible, we went back and tried again. It had to be at the level of Sharks with Laser Beams. As we would test things, we would ask ourselves, “Is this Sharks with Laser Beams?” When things were simple, beautiful and flexible, we reached our standard for Sharks with Laser Beams.
Sharks With Laser Beams Took A Long While
Before any customers ever knew we were working on a new version, two years had passed and we had already re-written our framework twice. We even briefly hired a nuclear Ph.D. physicist to help crack the code! Sharks with Laser Beams was taking us a really long time. Even in the movies, Dr. Evil didn’t realize actual sharks with laser beams until a later sequel.
The same was with us. We were committed to a level of awesomeness, but it was painfully slow, detailed and complex.
All told, it would take us almost 4 years to reach Shark with Laser Beam status for our 4.0 system. That is an eternity in the tech world. We had some euphoric highs and some very low lows. In order to build the best, we had to hire the best. Over the years, we expanded our team to a diverse group of people who are world class. They saw the vision and worked relentlessly for it with great passion (and some epic debates).
We went into private Beta last June and then public Beta in October. On that October day, we gathered everyone on a video call and projected it on our main office wall to pop the champagne together.
There were some tears that were shed on that day. I think some of us wondered if that day would ever come — and when it did arrive, it was a lot.
Since the launch of 4.0, we have seen meteoric growth. We had hoped maybe our growth might double after a year. In a few short months, our growth was exponential.
Our 4.0 system is actually better than we ever imagined. We continue to iterate, improve and add new features. Our dream list is getting shorter and shorter. But no matter the feature or functionality, Sharks with Laser Beams will always be the standard.
So if you are ever in our software and notice a hidden shark or maybe an Austin Powers reference, now you know why.