My Virtual Baby Shower: Creating Intimate Events in a Virtual Space


Since COVID-19 began, all of us have been looking for good alternatives to our traditional in-person get-togethers with family and friends. In this post, I’m going to be talking about my most recent side project creating a virtual baby shower. 

Why Work on Side Projects

Side projects are a big topic in our field, and there are a number of benefits to working on side projects in your free time, including:

  • Learning new skills
  • Scratching an itch
  • Trying out an idea
  • Solving a specific problem
  • Working with the freedom of constraints and limitations.

For most of us, there are two types of side projects: you either learn something new or you get something done. Over the years I’ve probably done  25-30 small side projects that were never in a usable state, but helped me to learn a new skill. For most of these side projects, I have learned a technical skill, but they will likely go nowhere. 

While these types of projects are great for learning something new, if your focus is to get something done, it’s usually best to focus on a skill you already know. That’s not to say you can’t learn something new and do something useful at the same time. However, when your time is limited, it’s typically best to have side projects that aim for only one of the two objectives. 

There can also be disadvantages to our industry’s focus on side projects. When side projects have the potential to cause you to burn out or when you don’t have an idea for a side project, it’s okay to take a break. After all, doctors don’t come home from work and perform hobby surgery to get better at their profession. 

It’s therefore best to pick side projects you are excited about when you have the time to do them.

Virtual Baby Shower Side Project

For my most recent side project, I decided to create a virtual baby shower. My wife and I are expecting a baby in the fall and my mom wanted to host a baby shower for us, but, due to the current coronavirus pandemic, we were unable to travel to have the shower with our family. When we began to talk about the possibility of a virtual baby shower, we quickly decided that we didn’t want to have the standard Zoom event that has currently become popular.

Some folks we know who have attended Zoom baby showers told us about their experiences.  As with most video calls, a few key people dominated the call, and many of the participants didn’t know how to mute their mics, so there was constant background noise. We also thought it might be awkward to be in a Zoom call with people you don’t know that well – my wife has only met my extended family a few times, and I myself rarely see them. We therefore decided that we didn’t want to have a video chat for our baby shower.

The Big Picture Concept for the Virtual Shower

After time spent brainstorming, we decided we wanted to have a non-Zoom virtual baby shower that included the following features:

  • Guests can RSVP
  • Guests can play a few different games
  • Guests can view information about us and the baby
  • Guests can be linked to the gift registry

Once we had the general concept for our baby shower, I began to build the actual application for the event. 

Constraints and Considerations

The constraints and considerations for this project were as follows:

  • Guest List: We decided to keep the baby shower small and only invite 13 guests. As a result, I didn’t have to worry about performance or scaling when creating the application.
  • Release Timing: Not everything needed to be ready immediately, so I was able to roll out features progressively. Because we wanted this to feel like more of an event, rather than a page you quickly visited, we rolled out new games weekly to encourage people to keep coming back to the shower page. 
  • Time Prioritization: I needed to move quickly while minimizing the time I spent working on the application, because I wanted to be able to still enjoy my evenings with my wife. I wanted a simple, opinionated tech stack that solved all of my problems and included all of my dependencies. I didn’t want to spend time wiring up dependencies and dealing with complicated architectures. I just wanted to hit the ground running and go. 
  • Application Use: I anticipated that most people would be accessing the baby shower application using a smartphone or tablet, so the mobile experience was a must when designing the application. 

The Stack

When designing the tech stack for the application, I wanted to pick programs that would maximize efficiencies for both application production and deployment. After careful consideration, I decided to use the following programs:

  • Rail 6.0: The tech stack I chose for my baby shower application was Rail 6.0. The only gem that I added to the Rail 6.0 tech stack was Devise, whichtook care of the user registration and authentication.
  • PostgreSQL: I used PostgreSQL as my data management system. 
  • NewRelic: I used the NewRelic free plan to monitor for errors in production.
  • Docker and docker-compose: To deploy the application to production, I used Docker and docker-compose on my personal server. 
  • Typescript: I only used a single class of typescript to do a dynamic countdown to show the time remaining for one of the games. I used typescript because Rail 6.0 allows you to configure webpacker with typescript in a single command.

As part of the creation of the tech stack, I specifically chose not to include the following tools:

  • React.js
  • Templating language like Haml or Slim
  • CSS Framework

I can see the value of these on a much larger project where you want to have standardized components. However, given the size and scope of my baby shower application, they were not necessary.

I started to develop my application by porting a static announcement site into Rails 6.0. I made the site dynamic and I gutted out the bootstrap things to replace it with my own simple CSS using flexbox. I used a free color scheme generator to randomly generate color schemes until I found one I liked and I applied that to my application. 

Due to the size and scope of this project, I did not write any tests for the application. I tested the application on my own devices and concluded that if it worked for me, it would likely work for the other 13 attendees. 

Baby Shower Games

To keep the feel of a real baby shower, we wanted to give guests the chance to play several different games. I created a list of games for the guests to view, and set up each game so that the user could see their submissions and/or results after playing.  

We released four games over the course of several weeks. At the end of each game’s play period, the winner or winners would be given raffle tickets for the prize drawing. Each game had a slightly different build based on the construct of the game:

  1. Advice for a New Mom: This game provided users with a single freeform answer in which they could provide my wife with advice. The submitted answers were logged in an administration panel. Once the game was over, my wife read the responses, judged them, and picked the winners. 
  2. How Big is the New Mom’s Belly: We uploaded several photos of my wife and allowed users to submit a freeform answer. Once the game was over, we used “Price is Right” rules to choose the closest guess that did not exceed the correct answer. We had a tie in our submissions, and declared them both winners.
  3. Word Scramble: The word scramble game presents letter jumbles and allows users to submit freeform answer responses. This was the only game that was automatically scored, as it was the only game that had a single correct answer for each question. 
  4. Pooh Trivia: We had a Pooh Trivia to keep in line with our Winnie the Pooh theme. The Pooh Trivia allowed users to enter freeform responses to the questions. Given the variance that was possible in each answer, we manually corrected each quiz. We considered using a multiple choice method so that we could auto-score, but decided that the freeform route would require less of a time commitment overall. 


One of the largest challenges in the development of this application was choosing what to prioritize with my limited time allotment. Deciding early on what to not spend time on and what to not build was valuable, because it helped me stay within my desired time commitment. Some of the features we considered, but did not implement, included:

  • Auto Scoring on All Games: We didn’t use automatic scoring for all of the games because it would have been difficult and time intensive to program. However, it would have been fun for users to see their results in real time.
  • Automatic Raffle System: Users who won the games were given raffles to be entered into the prize drawing. Once the games were closed, we exported the automatic word scramble results to a CSV, and then into Google Sheets. The manually graded results were also put into Google Sheets and the results of all of the games were tallied. 
  • Self-Help Tools: I didn’t build any self-help tools. Instead, I had people email or call me if they had issues and I assisted remotely. As mentioned before, the size of our guest list made this solution much more feasible than it would have been with more users. 

Deploying to Production

To deploy the application to production, I wrote a docker-compose.yml file that defined my postgres database, the application, and Nginx. I also used a Docker file to build the application’s container. 

For scaling purposes, I decided to run two instances of the application. While I certainly didn’t need two instances given my expected activity, I knew it would result in a more robust system. I used Docker’s DNS round-robin with Nginx to reverse proxy to the application instances. The DNS seemed to favor one instance or the other, but my logs revealed that both instances did get traffic. 

I deployed the application on my personal server, running a KVM-backed virtual machine. I therefore had the resources of 16 gigabytes (gb) of RAM, 8 CPU cores, and 80 gb of SSD storage in RAID 1. To deploy my application on the server, I ran Nginx on the host that pointed at the docker reverse proxy so that the host Nginx was the entry point into my server through the firewall. This allowed it to handle all of the secure socket layer (SSL) terminations.   

Production Deploy

Once the procedure for deployment was set, I pushed my Git-repo from my laptop over Secure Shell (SSH) to a directory on the server. I then pulled the working copy from that directory and used a deploy script for deployment.

The deploy script was able to:

  • Build the production Docker image
  • Restart the running containers with new images
  • Run Rails 6.0 database migrations against the new code
  • Prompt any required one-off tasks, including changes to things that had already been deployed


The reality of side projects is that you never have as much time as you’d like. If I had been able to invest more time in this application, there are several key improvements that I would have focused on:

  1. Additional Administration Tools: Specifically, it would have been beneficial to have a data dashboard rather than viewing data via the Rails console and queries. Whenever my wife or mother had a question (e.g. “who has RSVP’d?” or “How many people have played the games?”) I had to use the Rails console to write a quick query. With a dashboard, I would have been able to provide answers more quickly and track the status of the application more efficiently.
  2. System for Raffles: It would have been cool to have a system for awarding people raffle tickets, either manually or automatically. Instead of a drawing, we are using a random number generator to pick a random column in Google Sheets. Though our system is technically sufficient, a raffle system would have been more fun for both us and our guests. 
  3. Scoreboards for Guests: In the current system, guests could only see their score in one of the four games, and were unable to see the scores of the other participants in any of the games. Having a page on which users could see who had played the games and who was winning would have bolstered more competitive fun. 
  4. Restricted Registration: Due to the small size of my guest list, restricted registration was not necessary. However, for similar applications with larger guest lists, it would be better to restrict registration in some way to ensure that only those people who were invited were attending. For example, a code on each invite would ensure that only people with physical invitations were able to enter. 


As I mentioned at the beginning of this post, every side project is either a chance to learn something new or to get something done. For me, this application presented the perfect opportunity to use my skillset to do something special for my wife and my family. 

After undertaking this project, I have come away with several key takeaways:

  • Even simple scope and minimal engineering effort projects take time. The development of this application took me approximately 30 hours over the course of a few weeks. 
  • Engineering without constraints is a fun change. This project allowed me to build something with no pre-imposed technical restraints or outside opinions. I knew what needed to happen and simply accomplished it how I wanted to. 
  • When your client doesn’t know what they want, it’s your job to help them realize their vision. If you consider your mom and wife clients, then my clients needed a lot of help. They didn’t talk a lot between the two of them, so I was the person in the middle. When my wife had one idea and my mom had another, I would find a middle ground that would fulfil both of their expectations while also maintaining efficiencies. Most importantly, I had to be able to justify my decisions and stick to them. 
  • If you put your end users first, it shows. After the baby shower, a lot of our guests reached out and said that they had a lot of fun and enjoyed the uniqueness of the event. Even when people needed my help because they forgot their password or submitted something incorrectly, it was fun and valuable for me to be able to work with them directly. 
  • NewRelic stats are extremely boring when you get virtually no hits. On my heaviest days, I was only getting 30 hits in 24 hours, so the NewRelic stats were minimal. However, despite the pitiful graphs, it still helped me catch errors during production. 

The Next Project

With the imminent arrival of my child, my next side project will likely be focusing on being a dad for a while. However, I loved that I was able to use my skills to bring my family together in the midst of the pandemic, and I look forward to future family-focused side projects.  

Leave a Reply

Your email address will not be published. Required fields are marked