Share Your Stack – How to Architect the Perfect Travel Blog, WhereTheHellAreTomerAndMichelle.com

When Michelle and I started hatching together our plan for our trip, I knew I wanted to grow, both as a person, and as a developer. The very first step that I could do to start growing was to pick a new technology stack to host our travel blog. I had already worked with WordPress, published on Dev.to, and I knew I wanted to host something (i.e. not Medium).

Requirements

Besides the basic blog necessities, my requirements were:

  • Static – This would be a simple site and I wanted to keep it light weight – no need for server side lifting here.
  • Easily updatable – I wanted to be able to easily update it and remove any roadblocks from publishing new posts or updating the site. Once you go CI/CD, you never go back!
  • Posts in Markdown – Markdown is simple, and it’s now everywhere. This is also a good way to separate your content from your site if you ever want/need to migrate your posts to a diffrent stack.

For a long time I had been hearing about Jekyll and Github Pages hosting and the simplicity and integration between the 2 technologies. This seemed as good a time as any to pick it up and run with it!

I use the Lagrange Jekyll theme for our site as it seemed pretty simple and we liked the way it looked (how does anyone pick anything??). I went ahead and forked the project and then started putting our own touches on it.

Basic Setup

Jekyll makes it very easy to customize certain parts of the site in the settings.yml file. We made sure to update our social links, About page, contact, etc.

We also definitely wanted our own domain name and not a github.io subdomain. Who would’ve thought that WhereTheHellAreTomerAndMichelle.com was available?? With my favorite domain name registrar, NameCheap, and $13, we were the proud new owners! Github Pages makes it easy to host your site on a custom domain name as long as the repository is public. Using the Pages Settings for your repo, it will configure your custom domain name by creating a CNAME file in your repository. Github Pages will also automatically take care of an SSL certificate, how thoughtful! We were off to the races!

Travel-ize It

Since it is our travel blog after all, we knew we needed to put our itinerary and picture slideshow on it. For the interactive map/itinerary we chose TravellersPoint.com‘s embedded map. I have used them before for my Eat, Pray, Code travel and loved what they provided. To customize the embedded map even further, I upgraded to a ‘Budding Member’ and placed the embed code directly in the Jekyll page. Since this is an iframe, I also added some Javascript and proper styles to ensure that the map works well on mobile as well as desktop views.

Pictures were slightly trickier. The first part was figuring out where to store my photos. I wanted to be able to upload only select photos, not have to worry about storage limitations (at least for the forseeable future), and be able to share a public album. Eventually Google Photos won out because of their ability to share an album publicly. (I am still open to suggestions of other photo storing/sharing solutions out there!)

The next issue with Google Photos is that I wanted to create an automatically updating embedded slideshow on our homepage. The tricky part comes with Google Photos’ lack of an API. Luckily, I came across this page where, given a publicly accessible Google Photos Album, it will create an embedded slideshow widget. At the moment this does not automatically update, I simply have to update the slider code every so often when I publish new photos to the shared album.

Publishing Posts

One thing that I was really looking forward to with this new stack (and Jekyll in general) was publishing posts in Markdown. As a developer, I love the simplicity and ubiquitousness of it, while still giving the author control over any elements they may need. When I begin to create a new post, I simply pop open my Markdown editor of choice, MacDown, and start typing away! When I finish a post and run it by Michelle for final touches and editing, I can publish it using a simple git push command!

Comments

I’m sure we’ve all come across Disqus at one point or another in our WWW adventures, and that is what I originally set up for our site. But seeing as I am a self hosting connoisseur, when I heard of Commento.io, I immediately knew I wanted to try it out. Luckily, not long after that, the Cloudron team pushed out the Commento.io self hosted application on their platform. I set it up on my Cloudron instance, imported all the data from the Disqus instance, and replaced the comments code with the proper Commento embed script. Viola! You now have self hosted, secure, and privacy focused comments on our site.

Analytics

Google Analytics is probably the go-to for many sites and blogs, but I have long been using Matamo (formerly Piwik), also self hosted. Using the Matamo Analytics dashboard to set up a new site is a breeze. Then, simply replace the Google Analytics code provided by default by the Jekyll theme with Matamo’s code, and push it up!

“But what if you get hit by a bus?”

Michelle, out of her love and thoughtfullness, one day asked me, ‘how do I publish new posts if you die?’ She had a point. Not only is she not a developer and has never used Github before, but the site’s repository is also only under my username.

After some quick research, I came across Forestry.io – a Jekyll CMS. This seems to be a fork off of Jekyll Admin, but either way, Forestry is a fantastic tool to make everything easier for managing a Jekyll site in the way of hosting media, direct integration to Github and Github Pages, and of course, creating and editing posts. And yes, they do offer a generous free plan for a personal site! Getting this set up was a breeze, the only slightly tricky thing was getting the media folder set up properly, but even that was done without a hitch. And since they support multiple users per site, both Michelle and myself have access to update our Jekyll site – including writing and publishing posts – through their CMS platform.

Stack Birds Eye View

As most good things in life, this took time and is not done evolving. You can check out the Github repository to see for yourself how each of the items above grew and were implemented over time. Sure, I had a general idea of what I wanted on the blog to begin with, but a lot of these ideas took time to develop and implement. Be sure to check out the final product (for now)!

When Google Shuts Down a Service, a New Browser Window is Opened

How a Google Project Shutdown Opened the World of Self Hosting to my Eyes

I want to take you all the way back to 2013, before major privacy scandals peered their heads every other week, when everyone finally could answer the question ‘What does the Fox Say?’, and when Google shutting down a(nother) service of theirs still didn’t surprise us. 

I was an avid user of Google Reader, the search giant’s RSS aggregator that allowed one to follow multiple news sources in a clean, streamlined, and unobtrusive manner. I forget how I first came across this service, or even RSS as a whole, all that I knew is that this was my main, and pretty much only way to consume news online. It made sense; there weren’t ads or paywalls on any of the news sources I followed, I could save stories for later viewing, and I could always go to the original source if I wanted. 

Then came that fateful day in March 2013 when Google announced they were going to shut down Google Reader. Of course, by this time, it wasn’t much of a surprise that Google was sunsetting yet another one of their ‘Lab’ projects. And with RSS being a pretty niche medium within the ‘nerd-o-sphere’, this announcement went off without much of a mainstream fuss. All the while, I’m scrambling for a solution to migrate to after this unjustified killing. 

Little did I know, not only my RSS aggregator, but my entire online lifestyle and primary hobby that keeps me up at night, was going to change. 

There were a few different alternatives to Google Reader that started popping up after this news. A lot of them even would help you transfer over your Reader data, so you can pick up right where you left off. Call me a cynic, but it was hard for me to hand over my data, and more importantly trust, after the unfair shutting down of a service that I relied so heavily on. And then I came across the ultimate solution: Tiny Tiny RSS

Tiny Tiny RSS (or TTRSS) is an open-source (meaning anyone can view what makes it run, add suggestions or improvements, or update the application for their own needs), self hosted (meaning it can run on your own computer, instead of only on a company’s computers) RSS aggregator. This meant a few things for me: 

  • I can move off of Google Reader safely and migrate my data to this new service (a feature of TTRSS). 
  • If there’s an issue or a new feature I want, I can make the updates on my own. 
  • I won’t need to trust any other 3rd party to house my data or to stay online, it will all live on my computer! 

Getting it set up and working properly was a relatively easy task to a software hacker like myself. And I was amazed by the results! TTRSS instantly became my most used tab, like Google Reader before it, except now I knew that no one could tell me that this was ever going to be shutdown – it all ran right on my computer! 

After years of using this application, it really engrained in me the value of self hosting and owning one’s data. It’s truly a beautiful thing knowing that you are not at the mercy of any company’s will or bottom line. 

And then I discovered the entire sub-culture of self hosting. 

A Whole New World

This opened my eyes to a whole slew of applications that I can self host and stop relying on others for. My most crucial find during this self hosting renaissance was Cloudron. Cloudron is a self hosted platform that allows one to install applications through an App Store, a la Apple’s App Store. 

I currently am self hosting a Cloudron instance running a few applications including WallabagMonica HQ, and, of course, the trusty TTRSS (still my most used tab to this day!). 

Privacy

A major aspect of self hosting one’s own services is the fact that your data is always in your hands (or computer). In today’s privacy-less world where companies are hungry for your data, self hosting provides a haven where you own your data. 

"Anything thou publishes unto the World Wide Web is forever out of thy hands." 
- Honest Abe

I wouldn’t have known it at the time, but I am very thankful that Google shut down their Reader service. If it weren’t for that, I might never have come across this intriguing and captivating subculture of the internet. 

If you are tech savvy and want to try to rid yourself of the handcuffs that data aggregators have on you – and also have some fun while at it – I highly encourage you to check out the world of self hosting. Some great resources to start are the Awesome Self Hosted Github page and Reddit’s r/selfhosted

🍻 to a reliant-free and self hosted future!

Sunsetting a Live Service

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.”

-Steve Jobs

As a developer who’s started more projects than I can count, it’s good to take a look at one’s portfolio from time to time and do a bit of a spring cleaning.

What

BaDumChh was a daily joke texting service that I launched a few years ago. You can read about its inception here. TL;DR I was really excited about this idea for a long time and even ended up doing a relaunch after it was running for a while already.

Why

This decision was not easy. BaDumChh was close to my heart and not only was I a user of it, but I originally built this service for myself. So why did I decide to sunset it? A few reasons:

Not Curated Content

I always strived for BaDumChh to be a self-sustaining service that could run on its own. And it was that. But without moderation of jokes, there were some days where the joke that was sent out was inappropriate, offensive, or just not funny. This wasn’t the type of quality that I wanted tied to my name.

Growth

Growth was non-existent. I had only a small handful of people on the service and that number hadn’t changed in years.

Business Model

While payments were implemented and could run without intervention from myself, there were no paying users. And since this was a texting service, I was actually paying for this out of my pocket.

Needless to say, when I found myself looking ahead to the future and trying to focus on quality projects that I’d be proud to put my name on, BaDumChh didn’t make the cut.

How

Because BaDumChh was a live service and had many moving pieces, I had to make sure to come up with a graceful exit plan.

Using a feature I had built into the service a while back, I was able to schedule a message to all users on a certain Friday.

Once this message was sent out, I pushed up changes to the site that I had made ahead of time that would alert incoming users of the discontinuation of the service. These changes included:

  • Invalidating the API
  • Invalidating webhooks
  • Invalidating cron scripts
  • Updating the home page to say that the service has been discontinued
  • Updating the Twilio endpoints to have a proper response

After these were pushed up, I still had to make some updates to the environment itself. That included:

  • Removing the cron jobs entirely
  • Deleting environment variables for live services
  • Deleting the test environment
  • Emptying the database with user’s information. I value my user’s privacy.
  • Deleting the subscription plans in Stripe

I also have a scheduled calendar notification in 1 month to release the Twilio phone numbers I used. I wanted to keep these around for a transitionary period in case someone were to reach these.

Lessons/Ode

Some things that I experienced first hand from running BaDumChh:

  • ‘If you build it, they will come’ is not real.
  • If you want consistent and good quality, you cannot rely purely on an algorithm. You must either curate the content, or have some sort of democratic system (a la Reddit upvotes).
  • Know when to say ‘good bye’.

I don’t regret creating BaDumChh. I am a big believer in learning from one’s failures and moving forward. Otherwise, I wouldn’t be where I am today, and I’d like to think I’m in a pretty good place. I absolutely love the system I created for this service, even if it will no longer see the light of day. The only personally identifiable information I kept on my servers were user’s phone numbers. The whole system ran on its own without administration (though this was eventually part of its downfall). The login process was smooth as butter. And it even ended up putting a smile on some people’s faces. But alas, the time has come to focus.

Providing Better Meta Tags for the Rest of Us

Story 1 – Meta Tags

With messaging systems trying to satiate information-hungry users, it’s fascinating to see how standards are popping up around the decades old infrastructure of the internet. I’m talking, of course, about the meta tags and their evolution, or lack thereof. When sharing links on popular platforms, the new standard is to show a preview of the link so that users can know what they’re about to click on. Facebook introduced a new standard to help unify sites around the web and make information more easily scrape-able. Since then, there have been more standards added on to the age-old infrastructure of meta tags.

Story 2 – Serverless Architecture

A quite fascinating and paradigm-shifting technology is peeking its head on a lot of cloud platforms: serverless/Functions as a Service (FaaS). The possibilities that this technology opens up are not only quite endless, but also pretty darn cool. The premise is that one can deploy a simple function and only pay for the length of time that the function took to complete running. This is a great addition to micro-services and can instantly lower an API’s costs. Since well-designed API’s are stateless anyway, one doesn’t need a server constantly up, but only spun up as needed. It’s easy to see that FaaS can very easily turn API hosting on its head. And given my great interest in backend architecture and API design, I’ve been itching for a good excuse to play around with serverless architecture.

Story 3 – The Convergence

Meet Better Meta, the API that allows you to quickly and easily fetch any site’s meta tags in a digest-able JSON format, built on AWS’ Lambda. Better Meta is the perfect example of an API that can run simply in AWS Lambda with minimal resources and provide valuable information in a readable format for other developers to use in their applications. This allowed me to play with Lambda and get a feel for the serverless world and API’s, work with XPath (the scraping needs to be done somewhere, right?), study a bit of the history of the internet and evolution of meta tags, and of course, provide a valuable resource for fellow developers. Happy meta tagging!

Anything That Can Go Wrong…

…will go wrong. I used to think that this Murphy guy was just a pessimist who didn’t know how to see the cup as half full. And then, as one might see where this is going, I encountered the infamous law first hand.

That one client of yours that accounts for 80% of your income? They’re actively looking for a more economical solution.

The tickets that you were supposed to print for the upcoming event that you’re already late for? Too bad everyone was too busy to replace the ink in the office printer.

Your partner in the project who was supposed to lead the presentation? She might’ve forgotten to mention that she gets really bad allergies this time of the year.

Whether intentional or not, these things happen, and probably at the worst possible time. The examples above are all real. Yet, as the author of a blog post about Murphy’s law, somehow I was still surprised and unprepared when these times came around.

It’s important for us to constantly challenge the assumptions we make and to have a plan B for when the one constant you thought was always going to be there shifts from under you without a care in the world.

Budget for what would happen if this client disappeared off the face of the earth tomorrow.

Print the tickets ahead of time, not on your way to the event, or be proactive in replacing the ink for the printer and be everyone’s new favorite office mate.

Prepare with your partner and be ready to take the mic when the big presentation comes around.

What are the major assumptions you’re making, and what can you do right now to prepare for the day when those assumptions are pulled out from under you?

Please Leave Your Notifications at the Door

We are a lucky bunch. We live in a world where one can share the screen they’re looking at instantly with people halfway across the world. And I’m seeing more and more people take advantage of this amazing technical feature, as they should!

However, what I’m not seeing is etiquette around this channel.

When I have guests over at my house, I try to prepare for them appropriately: I clean the living room, puff up the pillows from their slouching state, put things in their proper place, spray some Febreeze and crack a window, and maybe even cook up some appetizers. And yet, when I partake in a screen sharing session, I don’t see similar preparedness. There are windows overlapping on one another, browsers with more tabs than I’d want to look at, and notifications coming in randomly to inform the viewers that the presenter’s girlfriend’s cat threw up in her shoes again. It makes me wonder where the disconnect is between people’s homes and workstations…

Given some of the bad practices and disorganized workstations I’ve witnessed, I propose the following Rules of Etiquette for the Remote Sharing of One’s Desktop:

  • If you plan on using a browser window during the presentation, open a brand new browser window. Then open any tabs you may need during your presentation. This way your coworkers won’t need to see which cat-of-the-week video you were watching or the controversial subreddits you follow.
  • Minimize all open windows and then open only the ones that will be needed for the presentation.
    • macOS: Hit Command + M for each application with open windows.
    • Windows: Hit Windows + D.
  • Enter ‘Do Not Disturb’ mode to make sure push notifications don’t interrupt your presentation.
  • Try to foresee any questions that may arise and be prepared for them by having relevant tabs/applications/windows open that you can reference.
  • If you’re on a Mac, consider using Spaces to create a clean workspace to work out of.
  • Within any open applications you’re presenting, maximize them to the full size of the screen to make sure users’ attentions are focused on the current agenda item. Given people’s attention spans, it’d be very easy for them to drift and oh look! A squirrel!
  • Potentially zoom in or enlarge text on certain windows when needed, such as web browsers, code editors, etc. While you’re only a few inches away from your monitor, people on the other end may be further away from their source of video. It couldn’t hurt to ask if the current size is appropriate for all the participants.
  • If you want to get really fancy: use the application switcher keyboard shortcut to be able to transition between applications and windows seamlessly and without a fuss. You can read up more about it here.
    • macOS: Hold down the Command button. Now hit Tab once. Continue to hit Tab until the application you are trying to switch to it selected, then let go of all keys and watch as that application pops into the foreground!
    • Windows: Follow the same instructions as for macOS above, but replace Command with Alt. Also important to note, on Windows, this switches between all windows, not only applications

Following these simple rules will help make desktop sharing sessions not only more professional, but more of a freshly welcomed home visit than a messy living room with a slightly sour odor…

The End of My Lithios Chapter

They say that when one door closes, another opens. Well, when an app is closed, you have the whole home screen full of opportunities!

I just ended my employment at Lithios (mobile-first software development consulting) and decided to see what the other side of the fence looks like. A more organized, 9-5 office job with a few locations, break room, and TPS reports (well, hopefully not that last part). It is a bittersweet feeling like none I’ve had before.

Lithios is just about all I’ve known of my professional career up until now. My friends and I were the board and C-suite and ran the whole operation bootstrapped for years – while always profitable and paying ourselves a (modest) salary, I may add. The freedom to start initiatives was exhilarating. The culture that we defined and carried out by example was captivating. The people we hired are amazing, each in their own individual and unique way. The amount that I have grown through my times at Lithios is intangible.

But alas, I am moving on.

Onwards to see what working as part of a larger company feels like. To be in a strictly technical, and not business role. To work with a veteran of the field who can code laps around me. To ‘shave off of someone else’s beard’, as the saying goes in Hebrew.

Needless to say, the good, great, and nerve-wrecking times at Lithios will not be forgotten. They will be carried with me into the next chapter, and beyond.

Water

“Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way around or through it. If nothing within you stays rigid, outward things will disclose themselves.

Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend.”
― Bruce Lee

Even before I came across this fantastic Bruce Lee quote, I felt this. I called it ‘neutral’. I feel like I’m a ‘neutral’ guy. I have a very easy time adapting to situations and getting along with people. I dislike very few people. I’m usually quite content wherever I am and with whatever I’m doing. Honestly, I feel like I have it too easy sometimes.

However, nowadays, when I’m faced with a tough (and sometimes even not so tough) situation, I don’t know what to do. I’m almost /too/ neutral. If I’m always content, I don’t have a preference for some things. Water is /too/ shapeless. I want to be jelly. Easily adaptable, but still have a shape of my own when I want. Does anyone have some gelatin?

Campus Cruizer: The Journey of my First Startup

If you know anything about me, it’s that I like to solve my own problems using creative software solutions. My college life was no different in that way, I just had a larger array of problems to pick from. So back in 2012, before Uber was ubiquitous, back when you actually had to think hard about whether to give your credit card number to a random app, back when going out in college meant one of your friends having to claim Designated Driver for the night, I experienced the Beeper System at Appalachian State University. Little did I know at the time, this was the start of something huge.

The Beeper System

In a small college mountain town, taxis didn’t have much of a presence; it didn’t make economical sense for them to be around. So the students came up with their own solution, the Beeper System – rumors are it originally involved beepers way back in the day. The Beeper System is a very large Facebook page where people can post their phone numbers on holidays and weekends and volunteer to drive people from A to B for a flat $2 per person, or $5 minimum. This concept was absolutely brilliant to me! First of all, you have a large community of students interacting and socializing from all cliques, while giving students a chance to make money on their ‘night off’ if they have a vehicle, while all at the same time keeping their town safe from drinking and driving incidents by giving people a reasonable and efficient option for transportation for the night.

While I absolute loved the idea of the Beeper System, I couldn’t help but cringe at the largely inefficient and manual system that was the cluster fuck of a Facebook page. Naturally, I started thinking (that’s when things can get dangerous…). I sat down with a then-acquaintance and now-best friend, co-founder, and business partner Arjun Aravindan and pitched him what I thought was an innocent side project, Campus Cruizer (Cruizer for short).

Campus Cruizer 1.0

After much discussion with my business partner, we cracked our knuckles, buckled down, and started coding. The first version of Campus Cruizer was one of the more elegant solutions I think I’ve ever created and still hold it dear to my heart. The system worked kind of like a strip club (though I didn’t even know how strip clubs worked at the time, I promise). We would be the main entity, the gate keeper, if you will. Drivers, or ‘cruizers’, would buy a ‘Cruize Coin’ and trade it in to get onto our ‘Queue’ for up to 8 hours (we never had anyone drive for 8 hours..). We had a dispatcher phone number, the ‘Cruize Line’, that would distribute calls evenly amongst all the cruizers that were currently live. So if you as a student needed a ride, you would call one central number, be redirected to the next available cruizer (with the driver’s number masked for privacy, though they could call or text the rider to coordinate), and talk details with them as far as how many people you were with, where you currently are and where you are headed. The pricing was based off of the Beeper System, $2 per head for around campus and $3 per head for downtown. All the tips the cruizer made during their shift were theirs to keep, we just kept the profits from the Cruize Coins. Also of note, if you were on the Queue and received no calls at all, you got your Cruize Coin back to try again another night – no money earned equals no money spent.

People absolutely loved this.

During our launch party (catered by cruizers), we had our drivers make over $100 per night. It was a huge success! I didn’t realize at the time what we had stumbled across.

It’s also worth noting that at the time, Uber and Lyft were just starting up and had yet to make their way to the Triangle area. As for NC State students, it was us, expensive self-entitled taxis, or find a designated driver.

We were able to find a mutual friend of ours that worked at the school newspaper and got an article about us on the front page. Our recognition shot through the roof! We had meetings left and right with different departments in the university who kept complimenting us about our product, how great and original it was, and offered their help in whatever area they could.

We launched the MVP of Cruizer in March of 2014. Uber and Lyft launched in the Triangle on April 24th.

Retaliation and Cruizer 2.0

That summer, while school – and therefore Campus Cruizer – was on a hiatus, Arjun and I knew we had to do something to keep up. We had proved our point and made a bit of a name for ourselves, but knew we had to innovate to stay relevant. After all, the new competition’s apps made their solutions much easier to use; you could use your credit card to pay without having to worry about carrying cash (also, more profits for the business), the apps could pinpoint your exact location without having to talk to someone on the phone, and their built in rating system gave both riders and drivers quality assurance.

Summer 2014 was probably the most stressful stretch of time in my life yet. Not only was I sick, but we had to work non-stop the entire summer to try and stay relevant. Within the duration of a single 3 month period, we were able to replicate the entirety of the Uber/Lyft system. This included rewriting our entire API with location tracking, payment integration, and rating system, and creating brand new apps for both iOS and Android to rival the functionality of Uber and Lyft’s respective apps. We also had to make sure NC State students knew about our service and why we were that much better than the new players in town; ‘For Students, By Students’. We had pushed our marketing efforts in the way of buying branded koozies and placing them in every single dorm room in NC State (with a partnership with IRC on campus).

To this day I don’t know how we were able to pull it off.

Loss of Momentum and the 800 Pound Gorilla

We had a secret weapon with us that we were using to try and maintain our position and keep our ground: our bootstrapped, homegrown, ‘by students, for students’ roots. The fact that we were NC State students, served NC State students, and worked with mostly NC State students, meant that we were part of the people; we could relate to the NCSU population and connect with them. In the same way that a small town’s mom & pop ice cream shop would thrive where a Ben & Jerry’s would merely sustain, we were hoping that our not-so-secret sauce, though still a crucial ingredient to our recipe, would be our winning move.

However, one thing that we (foolishly) overlooked throughout our business model was the lack of traffic during summer break. Since our driving value was a system built by students, for students, it actually worked against us in the summer months. During the May through August time frame, there were very few students around, and even less that were going out on weekends to their usual shenanigans. That entire summer, Arjun and myself were so focused on the product and the business that we didn’t realize that Uber was gaining on us, and quickly. While they weren’t nearly the size they are today, they were still VC backed with millions of dollars behind them. They were recruiting drivers left and right off of Craigslist and giving out free rides like there’s no tomorrow.

When school got back in session, we had a hard time getting back the momentum that we had at the end of the previous school year. While we, the founders, were busy with our heads to the grindstone working nonstop on the technology aspect of the product, we failed to realize that the larger players were taking over our market at an alarming rate.

Campus Cruizer never got back to where it was before that summer.

Growing the Team and an Uphill Battle

It didn’t take too long for Arjun and myself to realize we couldn’t quite do this alone, no matter how many hats we liked wearing all at the same time. Our first recruits were actually avid users of the service and had shown interest in helping out during a few Cruizes (Arjun and I would Cruize pretty often to keep an eye on our client base, see how they enjoyed the service and what could be corrected, and more importantly, set the vibe that we were trying to put out for the Cruizer service).

We hired two unpaid interns to help us with marketing. We hosted a few events around campus, gave out some the remaining of the koozies that we had left over from our summer marketing push, and stepped up our social media game (which I still personally see as a necessary evil in today’s start up world, #SorryNotSorry).

This marketing push was fantastic for us and got us some customers back. But with a loose regiment, not clearly defined enough goals and metrics, and everyone balancing a full school load, that tapered off after winter break.

Come spring time 2015, we had started to make another very large push towards getting Cruizer to where we wanted it to be. That included hiring two more developers (one of which I still work with today), a business development guy and a marketing guy. We really did have an all-star team. The biz dev helped us put together a more solid business plan and created an elaborate Excel sheet that would help us decide how much to charge per Cruize (we had shifted the model over to charge per minute and per mile to stay competitive). The marketing helped us plug in detailed analytics and tracking software into our apps to be able to track user flow and find out how our users are – or are not – interacting with our apps. And of course we, the developers, would then update the apps as necessary and implement any feature updates we saw fit. Arjun and I still oversaw all the operations and made sure things were running smoothly.

Our all-star team was working hard and making good progress. However (there’s always a ‘however’, isn’t there?), we were all still balancing either school or full time jobs at this point. While we were making slow and steady strides towards our goals, we weren’t making them fast enough. By early 2016, ‘calling an Uber’ was practically second nature to most college students, just as ‘Google it’ became a part of everyone’s vernacular, leaving competitors in the dust. Arjun and I had had many talks before, but the time came when we officially decided that our efforts weren’t seeing the progress and results we deserved.

Campus Cruizer was shut down in March of 2016.

Afterthoughts

Campus Cruizer was my first baby, there’s no doubt about that. It spawned from an idea, to a side project, to a full fledged start up with seed investors (thanks mine and Arjun’s parents!!), a full team, and two live apps; it was a living, breathing company. It was always a dream of mine to ‘invent things’, and this put me in the driver’s seat of exactly that. As a developer, I enjoy building things; solving problems with creative software solutions. I’ve published a few projects in the past that fit that description. But nothing quite like this. This was a tiny bit of what I like to consider a developer’s dream. I got to build a product that saw the light of day. It gained real traction, real users (over 1000 throughout Cruizer’s life), and real money was exchanged on this platform. We gave people jobs by giving them a platform to drive people. We made people’s nights by providing a ride back home for them, sometimes even stopping by drive-thru spots for some midnight munchies. We made a difference. While we couldn’t get Cruizer to the end goal we had hoped for, there’s no doubt that this adventure was incredible, and like no other that I’ve experienced. I am unbelievably grateful for this ride (pun very much intended, we loved these).

While I’m here, I would like to thank everyone who partook in this whole process, our team, our investors, our drivers and our riders, and everyone else along the way who helped or offered help or cheered us on. Seriously, you are all awesome.

I also learned quite a bit from this journey and would like to share just a few of those tangible lessons with you:
– Your business partner will have a huge influence on this entire voyage. Whether good or bad, that depends on who you bring along with you. As for me, I seriously lucked out. I didn’t know Arjun very well when I first approached him with this idea. I had simply thought he had decent business savvy and he could help me market the platform with his connections. It turns out I was right, but he was also so much more. If it weren’t for Arjun, Campus Cruizer would not have gotten as far as it did.
– Momentum is everything. I didn’t realize it at the time, but the fact that we had momentum in a few places and didn’t capitalize on it completely was a mistake on our part. I can only imagine how our users must’ve felt when they saw us going back and forth between activity and silence on social media and live cruizers.
– Startups are not easy. But you already knew that. At least I can say that from experience now 😉

BaDumChh and the Beloved Retro ‘Apps’

I hereby announce my newest project, BaDumChh; a daily one-liner joke texting service.

The idea for BaDumChh came to me one evening during a startup weekend when I was working on something completely unrelated. I simply wanted to create a fun, quick app that could run (and hopefully sustain) itself, built on Twilio’s phone system. I was so excited about this idea originally that I had trouble sleeping that night just thinking about the possibilities and how I would go about implementing a service like this, where I’d get the renewable jokes from, a business model, etc.

Throughout the development of BaDumChh, and even more so now, I realized what I love so much about this idea (even more than the guaranteed smile on my face once a day) – the fact that this is a texting service and not a mobile application.

In a world that is constantly evolving and being populated with countless apps for any and all needs you can imagine (and probably some you can’t imagine), I’ve grown to miss some of the simpler days without having to download an app specific to each need or constantly see how many notifications I’m behind. That is one of the beauties that the Twilio API enables. Sure, I can’t send push notifications to my users. Or easily charge them through in app purchases. Or send app updates. But why use push notifications when I can text my user? It makes communication that much more personal. And if I set up my own payment system, I can avoid the standard 30% cut that instantly comes of the top from app stores. App updates? I can push up changes to my back-end any day and all of my users will be on the new, updated version instantly. That also means I have one code base to maintain, not 2 (or more if I wanted to support more than just iOS and Android). Not to mention that while most cell phones ever have text message capabilities, only smart phones (of a certain operating system, version, etc.) can support apps.

I was recently introduced to another app that works through texting instead of an app, Digit.co. Digit Savings will hook into your bank account and inform you of your spending habits and move money aside for you in a separate Digit Savings account. All of this through texts. That tiny fact makes me respect this up-and-coming start up all the more. Digit also does not even provide an app option (as of November 2015).

Another startup that works through texts is GroupMe. GroupMe enables groups to chat easily through a single phone number instead of the mess that group messages can be (especially on a dumb phone). The interesting thing about GroupMe is that while they operate through texts, they also have an app that you can use instead of texts. Through the app you get a few more benefits like sending and receiving unlimited messages (they have a monthly quota for texts), favoring messages, emojis and images, and no message length limit (which is and always will be a limitation of texts).

So what is the ‘better’ option, a text message app, or an app as we’ve all grown to know and love? I don’t think there’s a right answer (what a cop out answer…); I think it very much depends on what you’re trying to do. But in today’s super busy, hustle and bustle daily routine world, BaDumChh will remain a simple and elegant service that will put a smile on your face the old fashioned way.