Migrating Email Hosts and Registrars with Minimal Downtime

Email is the focal point of our professional online identities. Whether you like it or not, that is the most reliable and consistent way for people to get in touch with you, and it’s not going away anytime soon (sorry, Slack). That’s why it’s imperative for your email provider to be reliable, resilient, and especially in today’s world, trust-worthy. 

Recently I realized that my email host is not great. I registered my domain and set up email accounts there long before I was thinking about privacy concerns or shopping for competitors. They were ok at what they did, but they specialized in assisted hosting services and email was clearly an afterthought, let alone any privacy or scalability concerns. 

I knew I needed to migrate email providers. And I knew that this is going to be a tricky and intricate operation. What I was looking for was:

  • minimal downtime,
  • end up on a provider that I trust long term and,
  • migrate all of my current emails and folders. 

It also happens that my domain was registered through the same email provider host and I wanted to transfer that over to my everyday registrar, Namecheap. Might as well knock everything out at once and be in good shape for the next while so that I can sleep well at night without worry. 

Decisions, decisions, decisions

First thing’s first is you have to find the new registrar and email provider you want to migrate to. This involved some heavy research on my end, because you don’t want to have to do this migration more than once. Everyone has their own priorities in what they’re looking for; for me it was privacy, management, and support. That One Privacy Site has a great article on what to look for in email providers, along with a Simple Email Comparison chart. I spent quite a bit of time looking through these options, and ironically ended up picking a host that wasn’t even on the list, Migadu. As for a registrar, I default to Namecheap as I already have quite a few domains registered there and like their service. 

Inform Your Users

I am a big believer in transparency, and especially with today’s internet climate, more transparency is better. I sent a letter to all of the active users on the domain stating that 1) I plan to migrate our email provider and why, 2) to which provider and why and any differences in services they should expect, 3) estimated timeline, and 4) I need their email passwords. 

That last point is a point of contention. In order to back up and migrate my users’ email accounts to a new host, I need to ask them to give up their privacy temporarily. Since I am my users’ everyday ‘IT guy’, they trust me and didn’t worry about this point. As a good measure, I linked them to the page where they can change their passwords before they share it with me, so if their password is one they use a lot, they can change it to something they’re more comfortable sharing. 

That being said, even with the proper transparency, be sure to listen to your users and address their concerns. If you did the proper research ahead of time, they should trust you with this transition, but it is up to you to keep them at ease and make sure that they are ok with your plan moving forward. 

Start Back Up & Migration (Emails)

I wanted to not only migrate my current emails, but back them all up as well, in case something went horribly wrong. Here’s the thing, there were a lot of emails on our server. I wanted this back up and migration to run continuously on a stable connection. AWS to the rescue! I simply spun up a t2.micro EC2 instance running Ubuntu and attached a 100GB Block Store to it. This was going to be my ‘command center’ for all things IMAP (and SMTP) during this transition. 

Behind every software success story is a powerful open source tool behind it. This story is no different. 

As for the tools necessary, I searched far and wide for reliable, stable, and open source solutions capable of iterative processes. I came across imap-backup for backing up emails and imapsync for migrating. Once you have these 2 tools installed, follow their respective set up processes and plug in your user’s credentials. 


For imap-backup, you want your config.json file to look something like this: 

  "accounts": [
      "username": "username@domain.com",
      "password": "",
      "local_path": "/ext_vol_data/username_domain",
      "folders": [

      "server": "imap.server.com"
  "debug": true

Of course, be sure to fill in the values properly. You can leave the folders array empty to move over all of the folders. The local_path here is currently pointing to an EBS store that I mounted onto the EC2 instance. And I have debug set to true so that I can monitor the progress of the script through its output. Then, simply create 1 account object per user on your email domain. 

Since this is simply backing up our accounts, you can start running this immediately! This script works iteratively so you only need to do a ‘full’ backup once, and every time after that it will only download the difference. 


Once imapsync was installed properly, I found this Github Gist to help sync multiple accounts at once. For multiple accounts, simply duplicate the line in the accounts.list file with the proper credentials. Make sure you also properly set the CONFIGURATION variables in the imapsync.sh file. This script is now ready to run, but it won’t work until you have both hosts set up and ready to receive requests. More on this to come. 

Start Back Up & Migration (Hosting)

The domain I was migrating also happened to have 2 different sites hosted on it on 2 subdomains that I wanted to bring along with me. Be sure you’re prepared for this by picking a new host and making sure that your environments, databases, and source code are all backed up and can be spun up in a new hosting environment. 

Take any action you need to try and spin it up before the actual migration. This is easier to do than an email migration since you can have the same site set up on multiple servers, but you can only have 1 email host at a time! Ideally, your sites should be migrated and simply waiting for the DNS change to take effect. 

Configure New Email Host

Because I wasn’t only migrating email hosts, but also registrars, I couldn’t pull the trigger on the domain transfer until I was sure that things looked right on the new email host’s side. I got in touch with Migadu’s support and they worked with me to ‘enable’ my domain name even though it wasn’t transferred yet. They also gave me a 1 month free trial ‘Basic’ account so I can see the full extent of the service. 

Using this, I was able to make sure that the new email host was up and running. 

I created email accounts for all our users on Migadu with template passwords that I could provide them for their first login. I also set up things like alias email addresses (so one can use emails like name+service@domain.com) for everyone. 

Regex for ‘+’ email aliases: ^username\+(.+)@domain.com

Since I know had the original email host up and the new email host up, I was able to use imapsync to start transferring all the data to the new email host. With the proper configuration, the previously mentioned imapsync.sh script made the transfer smooth and seamless, migrating over all emails within their respective folders, and incrementally. 

Admin Stuff

If you also plan on transferring your domain to a new registrar, be sure that the ‘webmaster’ email for that domain is an email you have definite access to and that is not tied to the domain that you are migrating. 

Pulling the Trigger

Ok, now everything is in place and backed up. What’s left is actually pulling the trigger and starting the migration process. Pick a Friday or Saturday night, a relatively quiet night for emails in order to minimize the ‘blast radius’ in case anything does go wrong. Again, for transparency purposes, be sure to inform your users when you plan on doing this, so that if they see anything fishy, they know that you’re be behind the scenes working on it. 

Before officially starting the transfer process, be sure to run the imapsync and imap-backup commands one last time to ensure the mailboxes on each host and backups are as up to date as can be. 

Now, begin by transferring the domain to your new registrar. You can do this by going to the ‘transfer domain’ page at your new registrar. You will need to ‘unlock’ your domain from your previous registrar and make a note of the domain code for the transfer. 

Once that is triggered, be on the look out for any emails coming through to the webmaster email of the domain from your previous registrar. A lot of times they will confirm it with you before enabling the transfer to go through. 

Now you should start configuring any MX and DNS settings for your domain on the new registrar. The MX records are the most important to not have any downtime for your email accounts. Once those are complete, be sure to set up any other DNS records you may need for the sites you had hosted on the domain and point the nameservers over to the new web host. 

Time to make sure everything is working properly! 

In your mail client of choice, update your email settings to point to the new email host with updated credentials. The first thing you should notice is that your Inbox and all other folders should be present just as you expected, thanks imapsync! Now compose an email from any other email address of yours to the email on the domain you just transferred and make sure it comes through – IMAP is working properly. And compose an email from your newly transferred domain to your other email account – SMTP is working properly. 

Inform your users that the migration has taken place and provide them with the new host’s settings (IMAP and SMTP servers, ports, etc) and their new passwords. Of course, you’ll have to do this through means other than their email 🙂 Be sure to point them towards the settings page they need in order to update their passwords to something personal and unique. 

Once you’re sure your email is working properly, be sure to also test any hosted sites you migrated and all of their functionality as they now live in a new environment. 

It’s All About the Customer

Follow up with your users to make sure that everything is working as expected for them. This is also a good opportunity to talk to them and see how they felt about the whole process: was it smooth? Painful? What could have been better? Hopefully you won’t need to do this again, but it’s good to get this type of feedback in general. 

Clean Up

So now you should be sure that all of your emails and sites are migrated properly and working as expected. 

What’s left here is cleanup, which is just as important as set up! Do not cross this off your list until you finish properly cleaning up any set up you may have done. I would still wait a solid few weeks or so before starting this to make sure that everything is in place before you can’t go back, but be sure to set yourself a reminder so you don’t forget. 

Our main cleanup consists of running rm -rf on any and all email backups in the EC2 and Block Store. Be sure to do this for all the settings and config files as well, as your user’s (as well as your own) passwords are present there! You can now tear down these resources confidently knowing that your information lives only on your new host’s servers. 


Phew! Give yourself a pat on the back for a job well done! 

Be sure you have a real, paid account with your new host to stay on their good side and not let a trial expire without realizing. 

That’s it! Congratulations on a completed migration performed well with minimal downtime!

Photo by Web Hosting on Unsplash

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).


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!


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.


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!). 


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.


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.


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 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.


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.


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.


“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.


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 😉