It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness… ~ A Tale of Two Cities by Charles Dickens
There is a revolution happening in the tech world. An emerging paradigm that’s letting development teams focus on business value instead of technical orchestration. It is helping teams create and iterate faster, without worrying about the limits or configurations of an underlying infrastructure. It is enabling the emergence of new tools and services that foster greater developer freedom. Freedom to experiment. Freedom to do more with less. Freedom to immediately create value by publishing their work without the traditional barriers created by operational limits.
Serverless computing is the future. It is changing the way we build applications which will change the way we build businesses. It will take years for people to fully realize its potential, but I believe that eventually code execution platforms and managed services will host the majority of our software and data. Developer productivity will increase dramatically as infrastructure will no longer be a limit to our imaginations. And most importantly, all kinds of problems, even the seemingly impossible ones, will have new armies lining up to challenge them head on.
I wrote a fictional story below that follows two hypothetical development teams. They both have the same idea to build a restaurant recommendation service, but each team takes drastically different approaches. Parts of this story are eerily familiar to me, but I assure you that any resemblance to persons or companies living or dead, is strictly a coincidence.
The story also loosely pits serverless versus Kubernetes. It’s important to note that the current debate over containers versus serverless is simply attacking a straw man. Containers may eventually be an essential part of serverless compute environments for things like “on prem” setups, if that even makes sense. But in terms of the cloud, one requires responsibility for the management and provisioning of infrastructure, while the other does not. That is one of the main points I am trying to make with this story.
Ultimately, I believe that the two paradigms are incomparable, and should therefore not be commingled. There are valid use case for both, and as of now, there are still limitations to serverless architectures that containers or other compute resources handle more efficiently. In the very near future, however, it will no longer make sense to build your own toaster, when all you need is a piece of toast.
So, without further ado, I present to you…
A Tale of Two Teams
Chapter One: An Introduction
Meet Mike and Amir. Mike was the SVP of Sales at a company that just had a successful exit. Amir is currently a senior developer at another tech company and has lots of experience building web scale applications.
Mike and Amir have known each professionally for some time. One night they got together at a local pub and discussed starting a new company. Mike would be the CEO and Amir would be the CTO. Mike told Amir that he knew several investors from his previous company and would be able to raise capital very easily due to his previous success.
They discussed the business idea for several minutes, but most of the conversation focused on equity allocation and creating a business plan and pitch deck. Since Mike would be working on this full time (and it was his idea), he would take much more equity. Amir would only be able to work nights and weekends until they were funded. They shook hands and both left very excited.
Jane met Javier in her Data Structures and Algorithms class in college. They’ve remained friends ever since. One Saturday afternoon they met at a local coffee shop and discussed Jane’s idea to build a restaurant recommendation service. Javier was very interested. They both agreed that they would need to keep their full-time jobs, so they would only be able to work on it nights and weekends. They spent the next two hours discussing the product and how it would work.
They took lots of notes and by the time they were ready to leave, they had an entire MVP sketched out. They knew they couldn’t build this for free, so they agreed to talk to their partners and discuss each making a small personal investment to fund the project. Jane knew from experience that success was about execution, not ideas. They agreed that if this turned into something, that they’d split it equally. They were very excited when they left.
Chapter Two: Funding an Idea
Mike spent the next several weeks working on a business plan and a pitch deck for the new company. Amir helped when he could, mostly adding some technical language and diagrams to Mike’s PowerPoint presentation. Amir also started working on some ideas for the infrastructure, but didn’t want to spend too much of his own money setting up test accounts. Once the business plan and pitch deck were done, Mike started setting up meetings.
The first few were relatively easy to get since he had a few connections from his previous job. After that, it became harder and harder. Amir joined him on a few meetings, but often felt like the potential investors were just gathering intel for their other portfolio companies instead of legitimately considering funding them. It was demoralizing to be turned down so many times, but after the 64th meeting (and six months of trying), they got a term sheet for $750,000. They were very excited.
Jane and Javier went home that night and told their partners about their restaurant recommendation service idea. Money was tight for Javier ever since his daughter was born, but his wife agreed that this seemed like a good opportunity.
Jane and her partner had been living together for several years and was immediately supportive of Jane’s new endeavour. She texted Javier and said she could start by putting $2,500 into this. Javier responded that he could contribute the same. They were very excited.
It took Mike a few more weeks to work out the details with the lawyers. He was recommended to a firm that was experienced representing startups, so he signed an agreement with them that would defer payment until they received the investment.
The firm set up a Delaware Corporation, created Restricted Stock Agreements with four year vesting schedules, reviewed the term sheet, helped them get set up with a corporate bank account, facilitated the final pieces of the investment negotiations, and even drafted employment agreements with a stock options incentive plan. They did all this for only $50,000. Two weeks later the first installment was transferred into their business account and Mike told Amir to give his two week notice.
On Sunday, Jane spent a few hours doing some research on opening a “business” bank account and found a one-page boilerplate partnership agreement that formalized her relationship with Javier. She emailed it to him and they met later that afternoon to both sign it. Javier gave Jane a check for $2,500.
The next day, Jane went down to her local bank and opened up a DBA account and deposited $5,000. They even printed a debit card for her right at the bank! She headed back to the office with plenty of time to grab a Greek salad on her way.
Chapter Three: Creating Identity
Mike was insanely busy. The term sheet required at least three board members, one of which was chosen by the investors. He spent hours pouring through LinkedIn looking for former colleagues that could be potential board members. Later that day, he had a meeting scheduled with a real estate agent to look at some potential office space downtown. He also had a call scheduled with Amir and a tech recruiter. They knew they needed some great developers and fast, since they only had 6 months to reach the first milestone spelled out in the term sheet.
After a few more weeks, Mike had signed a year lease at this hip technical loft. It was a little expensive, but he figured there would be lots of other companies to collaborate with. He found a great design firm and paid them $5,000 to create a corporate identity for the company. With a new logo and color palette in hand, he put in an order for a bunch of t-shirts and stickers. He also had his first board meeting. Amir was finally full time, so work on the product had begun, sort of.
Amir was spending a lot of his time reviewing résumés and talking to potential developers on the phone. He found three devs that he thought would really round out the team, so he and Mike met them and made them offers. The first two accepted, but the third didn’t. His fourth choice declined as well. Amir was able to hire his fifth choice. In a couple of weeks, they’d have a full engineering team.
Jane and Javier got together on Tuesday night after work and spent a few hours chatting about the product. They agreed that neither of them were particularly good at UI/UX design, so they would definitely need to outsource that. They were both very familiar with AWS as well, and they figured that the free tier for most of the services would save them money.
They also agreed on a name for the site. It was simple and straight to the point. Plus the .com domain name was available. By the time they left that night they had set up accounts for AWS, Github, Slack, Mailchimp, Buffer and Twitter. They also registered their domain name and paid $50 for a logo design. They were ready to start building.
Chapter Four: Getting to Work
Mike, Amir, and the three new developers were finally settled into their new office space. They spent the first few weeks discussing the product and getting the new people up to speed. Mike was very hands on with the product (it was his idea after all), so he assumed the role of product manager as well as CEO. Fortunately for Amir, Mike was often busy taking meetings with potential partners and other people that the investors wanted him to meet. These meetings, along with dealing with running the business stuff (payroll, health insurance, legal, taxes, etc.) kept Mike away from Amir just long enough each week for Amir to actually get some work done.
The next day, Jane went to Upwork.com and posted a job for a designer. She figured it would take a few weeks to find someone, so she didn’t want to waste any time. She also wrote up a little description of the app and sent if off to Javier. Javier created a landing page using a static website hosting S3 bucket and embedded the Mailchimp email capture form. The landing page certainly wasn’t going to win any design awards, but the logo looked good and it gave them a way to capture interest in the product before they launched.
Jane added the logo and the link to the landing page to their Twitter profile and started following some local restaurants. Marketing wasn’t really her thing, but she knew that they needed to do something to start building a following. She spent about two hours doing some research and found a bunch of restaurant review sites as well as a ton of great restaurant related blog posts. She spent two more hours using Buffer to schedule the next month worth of tweets that linked to the articles she found.
Chapter Five: Cloud Architecture
Amir chose AWS as their cloud provider since he was very familiar with their offerings. However, Mike (after talking with one of the investors) was a bit concerned about “vendor lock-in” and told Amir to be as cloud agnostic as possible. It was a bit of a rough start, but after a few weeks, they had designed a fairly straightforward architecture.
They would use Kubernetes to run the app, Cassandra as their NoSQL store, Redis for caching and geospatial indexes, and Elasticsearch for log aggregation and full-text searches. The machine learning component was still a bit up in the air, but one of the new developers had experience with TensorFlow, so they figured that they would experiment with that.
Jane and Javier met later that week and discussed the architecture of their product. With their limited budget, they knew they couldn’t keep a bunch of servers running, so they decided that they would use a serverless architecture with AWS Lambda as their compute layer.
DynamoDB seemed like the logical choice for a NoSQL database solution since it was completely managed and provided auto-scaling capabilities. ElastiCache running Redis would be great for geospatial indexes, but that would require setting up and paying for a VPC. They decided that using the the AWS Elasticsearch Service would allow them to do both full-text searches and geospatial queries. They also figured they could use Elasticsearch for log aggregation if they outgrew CloudWatch Logs.
Neither of them were machine learning experts, but after a little research, they figured they were dealing with a relatively straightforward multiclass classification problem. Jane agreed to spend some time playing around with Amazon Machine Learning and SageMaker to see which one would best fit their use case.
Chapter Six: Building a Foundation
Amir didn’t realize how much work it was to manage three developers. He spent a lot of his time answering questions and trying to keep everyone on the same page. He had one developer focused on setting up the Cassandra ring while the other two were working on writing some foundational code for the app. Amir spent most of his “free time” trying to get the Kubernetes setup working. He ended up just using the Amazon EKS service and figured they still weren’t “locked in” and could move containers to a different cloud provider if ever necessary. He figured the same thing for Redis and Elasticsearch and decided to use native AWS services for those as well.
Everything was finally coming together now that the development environment was set up. The development team all shifted their efforts to working on code. Mike was busy too. He researched and hired a UI/UX firm to design all the screens for the site. $20,000 seemed quite reasonable given all they would be getting for it.
Jane and Javier got to work. They chose the Serverless Framework to help manage deployments and resource configuration. They split the app into a series of microservices and created Serverless Framework projects for each one.
Javier focused on the API and built several functions that managed CRUD operations for restaurants and site users. He set up a few AWS Cognito user pools to manage authentication and integrated them in with API Gateway. He also created a function that was triggered by DynamoDB streams and had it write changes into the Elasticsearch cluster.
Jane spent some time working with Amazon ML and decided that it would be best for their use case. She set up some models and ran a few tests. They didn’t have any real data to work with yet, so she decided that would be her next task. After a bit more research, she was able to buy a list of over 10,000 restaurants with geo coordinates and cuisines for less than $100. She wrote a quick Lambda function that imported the data into DynamoDB. This let Javier start working on the search functionality, including geospatial and category indexes.
Jane also found a few designers from Upwork that seemed pretty good. After a quick discussion with Javier, she hired a woman from the midwest for just over $1,000. Jane went back to working on the recommendation engine. She created a new microservice that allowed users to record which restaurants they have visited and indicate why they liked or disliked it. This was based on several factors including wait times, price, breadth of the menu, service quality, etc. They were starting to make some really great progress.
Chapter Seven: The Slog
Mike, Amir and his team were making progress. They had the majority of the application components built. They’d written a series of ETL tasks that would batch data from Cassandra and replicate it to Redis and Elasticsearch. The geospatial search functionality with Redis was lightning fast and the API they built was locked down with OAuth 2.0. They had to deploy their own OAuth2 server, but this way they figured they had much more control over user security. Kubernetes was performing well also.
The TensorFlow developer was making some progress too. He had some initial training models and was able to make some predictions using the test data he created.
Mike had spent quite some time going back and forth with the UI/UX firm, but they eventually delivered some very professional looking screens. One of the developers started slicing up the designs and coding the HTML templates.
Amir started working on automating the infrastructure and setting up a CI/CD pipeline. He created a “staging” and “production” AWS account and decided to use Terraform to manage the infrastructure.
Jane’s training models and prediction tests were making some real progress. She set up a Lambda function that processed data from a form hosted in an S3 bucket. She and Javier emailed this form to several friends and family members and asked them to submit information about local restaurants to help her train and refine her model.
They also got the first round of designs from their Upwork contract. They definitely got what they paid for, but they agreed that it was a lot better than either of them could have done. There was a bit of back and forth and some minor edits, but eventually they were “okay” with the designs. After all, they thought, if you’re not embarrassed by your first version, then you waited too long to launch.
With her machine learning component near complete, Jane switched over to working on setting up the AWS environments and configuring a CI/CD pipeline. She created a “staging” and a “production” account in AWS and decided to manually set up the Elasticsearch service for each account. The other resources, including IAM roles and DynamoDB tables, were all managed by the Serverless Framework, so she didn’t see a need to automate just the Elasticsearch component. She also set up AWS CodePipeline, which simply pulls code from their GitHub repository, runs their Mocha tests, then deploys their code using the
serverless deploy command.
Chapter Eight: The Calm Before the Storm
Mike was getting really nervous. They had a board meeting coming up next week to review their six month milestones and the app still wasn’t launched yet. He asked Amir to get “something” live so that he could show the board the progress. It doesn’t matter how much code you’ve written, if the board can’t see it, it doesn’t exist.
Amir pushed his team and was able to get a version of the site up and running in the staging environment. The entire UI hadn’t been fully enabled, the recommendations weren’t plugged in yet, and the authentication system was being wonky on Safari and Microsoft Edge, but at least it was something to show.
The board meeting went better than expected, and everyone seemed pleased with the progress. The recommendation would be to release the next installment of the funding as soon as possible. That was a good thing, because their burn rate was eating cash very quickly.
Jane and Javier were very happy with what they had accomplished over the last 10 weeks, especially since they’ve only been working on this a few nights each week. They had a complete working version of the site up and running in their staging environment, plus the combination of their Twitter account and outreach to their friends had generated over 500 signups to their Mailchimp email list.
Javier wanted to optimize a bit more for SEO, so he used Lambda@Edge to generate static pages for every restaurant in their system. This not only dramatically reduced the number of Lambda invocations, but also made response times ridiculously fast. They agreed that they should start letting real people into the site as soon as possible. Javier deployed the site to a “beta” S3 bucket and limited access based on Cognito user identities. They sent an email to 100 people on their mailing list asking to help them “test” the new site. Then they crossed their fingers.
Chapter Nine: The Launch
Another few weeks had passed, but the site that Amir and his team had built was finally working in their staging environment. With all the automation scripts in place, they were able to deploy to the production environment as well. The site was LIVE! Mike hired a PR firm and they sent out a series of press releases. At the Board’s request, they also hired a new marketing manager. She set up all their social channels and started a company blog.
Thanks to a favor from one of their investors, they eventually got an article written about them on TechCrunch. They got over 10,000 visitors that day, but only a handful of signups. The development team started working on a bunch of new features, including the ability for restaurants to enter in their menus and daily specials.
It had been almost 9 months since they first started, and they were getting near the end of their runway. The board and the existing investors started putting together meetings to raise a series A. Mike started spending all his time raising money.
72 of the 100 people that Jane and Javier emailed signed up for an account. The feedback was mixed, but mostly positive. There were a few bugs that were quickly identified and squashed, several comments on the design, and one user that was particularly outspoken regarding his disdain for the company’s logo. Other than that, the system was performing well. They emailed another 200 people from the mailing list and waited for more feedback.
This batch was even better than the first. Of the 168 people that signed up, almost all of them gave some great insights. Most of the bugs had been fixed with the first group, so this feedback focused more on usability with lots of great suggestions and ideas. They iterated quickly and after another week, emailed the remaining people on the list (which was up to over 600 total now).
More great feedback! There were lots of suggestions and ideas, but no show-stopper bugs. They were ready for launch. Jane and Javier had been working hard for the last 3 months, and they wanted to make sure that the launch would be successful. They had just about 500 users, so they figured they could get some more buzz with a contest. They decided to offer a chance to win a $100 restaurant gift certificate to any user that invited at least five friends. Javier built a simple sharing form for the contest, and they pushed the site LIVE!
The contest worked brilliantly, with over 2,000 additional sign ups just from that. A day later, someone posted the site to ProductHunt and they received another 4,000+ signups over the course of the next week.
Chapter Ten: Post Launch Hustle
Mike had been meeting with every VC and investor group he could get in front of. So far, all they received was lukewarm interest. The PR, blogging, and social media campaigns had gotten them just over 11,000 user signups, but users were not coming back to the site like they thought they would. They also only had 16 restaurants using the new features they built, and most of them stopped updating their specials. They would get an angry email every once in a while that would indicate some sort of bug. They’d eventually chase it down and fix it.
The marketing manager suggested emailing all of their users to “re-engage” them. Maybe eventually even a weekly newsletter that highlighted new restaurants and user reviews. She decided to send an email to all 11,000 users with some updates about the site and asked users to come check out the new features. The open rate was abysmal, and there were quite a few spam reports. After that, Amir was afraid to email users again.
At the end of 12 months, they were just about out of money. Between six full time employees, rent, and an $8,500 AWS bill each month, they weren’t going to be able to keep this up much longer. Mike struck a deal with one of the existing investors that he would continue to fund the company under two conditions. First, they would get much more favorable terms (something about anti-dilution, liquidation preferences, and an exit horizon), and second, they needed to cut the burn rate.
Mike tells Amir that they have no other choice, so they take the deal.
The last three months have been a blur for Jane and Javier. They’ve continued to encourage feedback and the site users have been extremely gracious (well most of them anyway). They’ve made a lot of changes to the site as well. They built out new interfaces and features that let users more easily manage their previous restaurant ratings. They added a new rating system that let’s users rate restaurants and leave comments without filling out the entire review form.
Jane hired her nephew (he’s a junior in high school), to find email addresses for some of the restaurants that were getting reviewed. Then they would email the reviews to the restaurant with an opportunity to respond. 70% of the restaurants responded positively and signed up for their new “restaurateur” accounts.
One user suggested that they allow social sharing of reviews. It took just two days to build and launch a feature to share your review to Facebook and Twitter. After that, user sign ups really picked up.
Jane kept on working on the Machine Learning model, and based on user feedback, had gotten the false-positive rate to less than 8%. They also ran lots of experiments. Everything from slight wording changes for call-to-actions to completely different layouts. These A/B tests increased the signup rate by 11%, pushed the average time on site up by over 2 minutes, and dramatically increased their WAUs (weekly active users).
They were also killing it with SEO. Several searches for local restaurants returned links to their site on the first page. Sometimes right below Yelp! They were seeing thousands of users from organic search traffic every month.
This was all great, but their original $5,000 investment was starting to run out. With the larger Elasticsearch cluster size and the increase in traffic to CloudFront, Lambda, and Amazon ML, their AWS bill was up to $254 per month. Then something amazing happened.
Chapter Eleven: Decreasing the Burn
Mike and Amir had to layoff two of their developers, per the deal with the investor. They also moved their office into a shared coop space that was much less expensive than their previous digs. The refrigerator wasn’t constantly stocked with LaCroix, but they figured they could deal.
The next six months were very tense. The new space was often loud and inconvenient to get to. On any given day, two out of the four of them would work from home. Mike continued to pitch VCs, hoping to turn things around and get off of this shoestring budget. Amir and the other dev spent most of their time keeping the systems running. They had an issue with the Cassandra ring that took them nearly three days to fix and fully restore missing data.
User signups were relatively flat, and you could tell that the marketing manager was completely checked out. They weren’t even in the new office a month when she gave her two week notice. Mike and Amir both agreed that they should use that extra money to hire another developer, so they posted a job description. They got a few candidates, but most asked about the current funding situation and were overly skeptical. They ended up hiring a junior dev who had just graduated from college.
Mike tried to keep up with the social media accounts, but he was inconsistent at best. The new dev was very green and was constantly asking Amir for help. They did make some feature updates on the site and they scaled back most of their compute resources to save some money. At the end of the six months, Mike walked into the board meeting with a target on his back.
Jane checked her email before heading off to work one morning and there were two emails that piqued her interest. Both were from restaurants that said several of their patrons told them that their restaurant was recommended by the site. They were wondering if there was a way to advertise or promote their restaurant using the service. Jane forwarded the emails to Javier and asked for his thoughts.
Later that night they discussed how they might be able to implement some sort of advertising system. They knew they couldn’t do banner ads, and they certainly didn’t want to compromise their recommendation service. They knew they would need to limit the promotions geographically, so they would have to figure out the overall value as well. They had some ideas, but ultimately decided to ask the restaurant owners that emailed what their thoughts were.
Both restaurants wanted prominent listings on the site, one of them used the term “featured” to describe it. One of them did suggest some sort of a banner ad, but they both indicated the ability to advertise promotions and specials. They had been letting restaurant owners update their profiles for quite some time, even letting them link to their menu, but would a “specials and promotions” feature be worth paying for? They needed more feedback, so they emailed 100 of their “restaurateur” users with a SurveyMonkey survey.
They received 41 responses. The feedback was consistent. They knew what they had to do. They put together a plan and got to work.
Chapter Twelve: The Logical Evolution
The board meeting went just as Mike had expected. As part of the new term sheet, two new board members had been added. Mike had been replaced as chairman of the board the first time the new five-member board met six months ago. He was actually a bit relieved at the time, because honestly, he felt as though he was faking his way through most of it.
The meeting focused entirely on him. Even the board member he had handpicked was a bit antagonistic towards him. Apparently the board had been meeting without him and made the decision to replace him as CEO. They had a formal vote, it was 4-1 in favor.
They asked Mike to stay with the company for a while to help with the “transition.” He basically had the option to agree, or lose the majority of his shares. The good news was that this “change in management” also brought in another round of funding. There was some discussion of “re-capping” the company and creating a larger option pool for new hires, and then Mike got the ultimate kick in the, er, well, let’s say “slap in the face.” The guy that he asked to join the board, would be taking over as the new CEO.
Jane and Javier spent about two weeks building the new “Restaurant Promote” feature and emailed the 41 survey respondents and the two original restaurants with an invitation to sign up. Based on the survey responses, and some of their own intuition, the new feature gives restaurants a “featured” listing on local cuisine pages, plus a more eye-catching listing when they come up in recommended listings. They also allow them to promote everything from food specials, to happy hour deals, to bands that are playing at their establishment this weekend.
Given the limited regional reach for each restaurant, combined with their current site traffic, they figured they’d start with a flat rate of $25 per month. Of the 43 restaurants they emailed, 29 of them signed up. And just like that, they had revenue.
Chapter Thirteen: The Push for Profit
Mike had known Kevin for almost 14 years. He was the CEO at his first sales job, and now he was going to be the CEO of the company Mike had started. They had worked together before, but Mike felt a bit betrayed and wasn’t looking forward to being his subordinate again.
Amir was skeptical too. He knew that the user numbers Mike had been feeding to the board were complete bullshit. I guess it depends on how you define a “user”, but anyway you look at it, the numbers were intentionally misleading. Kevin met with Amir and told him how he had run several companies and that he was going to turn this company around and they’d all be rich.
Kevin brought in a CMO and a new VP of Sales to ramp up marketing and increase revenue. After three months, Mike had finally left. Amir was asked to join Kevin on several investor calls, which not only distracted him from the product, but confirmed his worst fear. Kevin knew nothing about the technology they had built or what it was capable of. There were times that Amir wasn’t even sure if Kevin was pitching their company or was confusing it with one of his old ones.
Three more months passed and Amir still hadn’t been able to hire the additional engineers he was promised. Meanwhile, sales added two people and the CMO got a new marketing manager to work under him. Frustrated and tired, Amir broke down and gave his notice. They asked him to leave immediately.
Jane and Javier’s new “promote” feature was working really well. As soon as the first few restaurants went live, they started getting emails from other restaurants asking how to participate. They rolled out the program over a course of a month, testing and tweaking along the way. At the end of that first month, they had over 200 participating restaurants.
Feedback from users was positive as well. There were a few complaints about “pay to play” and the impropriety of manipulating results, but adding a simple “What’s this?” link that explained the program and how it worked seemed to satisfy the vast majority of complainants.
By the end of the second month they had changed the program slightly to vary pricing based on geographic population and restaurant density. They now had over 500 restaurants paying for the program, generating over $14,000 in MRR (monthly recurring revenue). The next month it was over $19,000. Jane and Javier both gave their employers their notice and started working full time on the restaurant recommendation site.
Chapter Fourteen: The Next Chapter
Six months later, Mike and Amir met at bar to grab a drink and catch up. Amir keeps in touch with one of the developers who still works at their old company. Apparently the company started running media campaigns for restaurant chains based on geolocation or something like that. Supposedly there is some revenue, but the margins are terrible.
Mike is still out of work. Amir took a job at a large tech company. He’s not particularly happy there, but the pay is good and he has a heck of lot less responsibility. Neither one has any vested interest in the old company and have no idea how it is still operating.
They reminisce about the early days and how excited they were when they first discussed starting the company almost three years ago. Actually, it was at the same bar, but a different table. They have a few drinks, a fews laughs, and share a plethora of theories and excuses for their ultimate failure. They shook hands and both left disappointed, but ultimately relieved.
Jane and Javier had hired five people in the last six months. Their “Head of Restaurant Relations” (often referred to as the maître d’) managed sales and had an assistant who helped handle restaurant onboarding, training, and notifications if specials weren’t updated regularly. He even had several national chains in the pipeline.
The new marketing manager took over the Twitter account and expanded their social channel reach. She started blogging regularly as well, with a few of her restaurant roundup posts gaining significant popularity.
They also hired a data scientist to help with analytics and machine learning. The insights were fascinating. They used the data to analyze clickstreams and optimize traffic flow. This increased signups by another 8%, bumped up time on site, and ultimately led to an increase in month over month revenue growth. They also hired another developer to help build new features and iterate on existing ones.
When things had started to take off, Jane and Javier decided to form an LLC. They signed up with a payroll company, hired an accountant and put a lawyer on retainer. Jane sort of ran the company, but still plays an active part in the product and ongoing technology development. Javier was happy to focus on the tech, but Jane and Javier always consulted before any major business decisions were made.
They now had over 2,500 restaurant customers and were generating north of $70,000 per month. They also had over 2 million registered users, with more than 40 million monthly page views.
Jane and Javier stopped to get a drink after work one night. They discussed the business for a bit and agreed that there was still a lot more work to do. They reviewed their latest AWS bill, $740 for the month seemed a bit high, but it was still reasonable. They also agreed that the last 14 months of hard work had certainly paid off. They shook hands and both left very excited.
If you’re interested in serverless, read my 10 Things You Need To Know When Building Serverless Applications to learn from my mistakes. For more information on securing your serverless applications, check out Securing Serverless: A Newbie’s Guide and Event Injection: A New Serverless Attack Vector.