“I’ve been imitated so well, I’ve heard people copy my mistakes.” ~ Jimmy Hendricks
SIGN UP BELOW AN JOIN US ON OUR RIDE AS WE NAVIGATE THE ROUGH WATERS OF BIG BUSINESS
Everyone likes a good backside, right? Well, in technology the infrastructure is often the difference between a novelty act and a large company. It’s cute that software can handle 100 customers, but what if that number spikes to 1,000,000 users?
A lot of apps have beautiful design, dazzling features and would fall apart with 2500 simultaneous users because the backend is not their strength. Look at it as a Ferrarri body, with a moped engine.
In mid-October of 2014, we learned that lesson the hard way.
So there we were, six months ago planning our launch. The software was working very well. I even used it for the holidays and was surprised by how well it actually worked. Well…it wasn’t just that. I was surprised by my own product, by how well it worked and I was surprised by how good it made me feel not to be enslaved to my phone on Christmas. I was super confident.
The date we chose for the launch was October 15, 2014. This gave us more than enough time to make a few programming corrections and get it out the door. Aside from a few things to correct we were ready. It was “go time.” We were going to take the world by storm and take no prisoners. Nothing could stop us now!!!
Then something wonderful and terrible happened and our worst fears were realized. What happened? What could be terrible and wonderful?
We had a meeting about our server infrastructure.
You see, we were all software and marketing/operations people. We aren’t server people. Server people are weird to the rest of us. Server people live in a world few understand. Server people stay up until the sun starts to peak up and then go to sleep. While the rest of us are watching reality TV or on Facebook, backend people build centralized gaming centers and functional products in their free time that could be sold, but that was never a thought.
We met with one of these backend wizards at lunch, and everything changed.
The entire premise of the meeting was “how should we structure our servers to be able to support large amounts of traffic?” This sounds so easy…I thought “all we need is a reporting system, a few load balancers and then a threshold to know when to spin up another server. If we know what our scheduled message traffic is and set the rules where there is enough lead time, we should be able to have servers ready to go when we need them.”
It was at this meeting that it was reaffirmed…I am not a server guy. Just because I’ve worked with them, does not mean I know what I’m talking about.
One of the first questions was simple, “if your software breaks, how will you know what went wrong?”
“Ohhhhhhhh, Fuuuuuuuudge” I thought, sounding like “Ralphie” from the Christmas story. This backend weirdo was right. We would not know if it was a data issue. We would not know what messages had been sent or received. We would not know if it was a queue issue. We would not know where the product had an issue, or how and where to go to fix it. The whole house of cards came crumbling down like we were in college playing a drunken game of Jenga.
Do we go ahead and do the "Lean Startup" or do we do it right? If we launch with what we have that's a BIG risk...it was a risk we could not take.
We came out of that meeting deflated but with clarity. The clarity was what we needed to get done was now in focus. Quite simply, it was that we needed to design an infrastructure that can scale up to billions of messages a month. We also needed to make sure we could trouble shoot without a single point of failure. That’s easy enough, right? The problem was clear now…we had approached the backend all-wrong. Our backside was weak! We needed a nice backside, and if we didn’t have one we could not enter the pageant (metaphorically speaking, of course).
Let me get back to the story. We were just getting to working on our rear. The purpose of the backend comes down to 5 primary things:
1) No single point of failure
2) Performance improvements/stability
3) Ability to support virtually unlimited messaging traffic
4) Much easier to identify where issues are and correct them
5) Automation of servers, which means less human resources and monetary savings
Knowing I was going to hate the answer, I asked: “so how long is this going to take?” To which he replied: “I don’t know…maybe six months?”
Did he say weeks? He meant weeks, right? You heard him!
Oh, how I loved the truth and hated what it meant. It meant we were going to be out a lot of time, and a lot of money at a time when we could afford neither of those things. It meant I look like an ass for telling people we were close to launching. It means competitors could possible catch up (they are way behind...seriously).
It also means we didn’t roll out a half-baked product. It also means we didn’t launch and have our first customers end up hating us. It also means our first impression wasn’t “these guys have no clue what they are doing.” It also means we slipped past an iceberg and lived to see another day. None of those latter things I mentioned were reassuring me six months ago. I was focused on the first ones, least of which was looking like an ass.
Getting our perfect backside would take work! Six months of work!
My job as CEO was to say something profound as we were all deflated walking out of that horrible restaurant. All I could muster up was: "at least now we know."
Now to those of you reading this and thinking: “what is six months? That’s nothing!”
Let me address that before moving on. In technology, six months is an eternity. Six months is 1/20th the amount of time since the original Ipod came out. Six months is about 1/3rd the amount of time since 5G came out. Six months is FOREVER in software.
Now here we are, a small software company talking about six months of no customers! This means six unanticipated months of not only no revenue but also MORE expenses. Why more expenses? Again, we are a team familiar with software development and not with the creatures that roam the backend of all technology products. We needed to hire some help.
The first thing we had to do was find a resource to help us have a nice backend. We brought on two people…one cost us a fortune, the other saved our collective asses.
That “six months” ended tonight. As I was writing this article I got the call that the server infrastructure is now ready.
So six months later, I am happy to report we are now in testing mode. Essentially, testing mode is to make sure all of the servers talk to each other correctly and report back to our main management server.
So what does this all mean? It means having a nice backend takes a lot of work! Most software companies focus on looking pretty, but if they can’t handle large amounts of traffic eventually they will hit a wall. On the other side of that wall they will have to spend a lot of time and effort to get the backend they need to be successful.
We were lucky to have learned that lesson in early October of last year - before it was catastrophic. A big salute and thank you goes out to all those server and infrastructure people, without you nothing works smoothly.
ABOUT THE AUTHOR:
Eric Beans is CEO of Texting Base, Inc., out of Orlando, Florida. Texting Base is a cloud-based software that adds efficiency and power to business texting communications. Combining the efficiency of a “mass text” and the effectiveness of a personal text message, Texting Base uses patent pending software to allow businesses to build relationships with their customers like never before. Prior to Texting Base, Eric was a partner in Premier Mortgage Capital, Inc., a nationwide state charted Mortgage Company that grew to over 1B/Year in originations. Eric is an inventor, investor, and entrepreneur. Eric has experience in writing, radio, TV and entertainment.