Canary Marketing is a full-service marketing agency with a simple mission: creating merch people actually want to keep. I am the primary technical contact at Canary, focused on our web presence internally and externally when representing our clients on web storefronts. Canary is a smaller company that I started working with as a contractor when they had around 50 employees and they now have more almost 200! Growing up with this company has been a pure delight, especially because I was able to wear many hats which allowed me to learn a lot of lessons about business & tech. 

Core Responsibilities

• Active member of the Operations Team, Webstore Team, ISMS Board, Leadership Board, and Processes Board to oversee the technical direction of Canary
• Liaison between Canary executives, Canary project teams, and external client contacts through video calls or email chains 
• Filled and reviewed technical security documents to ensure the project was approved by client technical teams and moving along for the Canary sales teams.
• Managed another developer as we built custom web apps or made customizations to existing builds for various web and tech projects. 
• Domain Administrator for ~75 company and client domains, updating DNS records, creating redirects, buying domains, and more.
• Worked with industry giants like Visa, Google, DocuSign, Spotify, Pinterest, Spotify, Zoom, Workday, and more.

Coding

"canarymarketing-shop"

Canary initially reached out to me through a mutual connection to solve their business issue when COVID hit the "company swag" industry, every employee in the world was suddenly at some random address and not the corporate office, so delivering swag became much more difficult. The companies buying their swag didn't have a great way of asking this question of their employees, as well as getting their sizing/gift choice, so suddenly Canary needed to get this shipping data to provide their services while a global pandemic was disrupting the world. Canary initially found some workarounds with 3rd party software solutions like Shopify, Brightsites, etc, but Canary's use case was more niche. They wanted a quick pop-up web shop, with no need for credit cards at checkout, but since no credit card payment was required, there was no way of preventing invalid orders such as one employee "accidentally" placing multiple orders, or some random person getting ahold of the link.

I was hired by Canary initially as a contractor in Jan. 2021 to create a solution for these web pop-up shops, starting with Stitch Fix's 10th Anniversary project which had an expected guest list of ~10,000 users. In 4 months I built a custom CMS with React.js CRA and Firebase, where Canary employees could interact with multiple shop tenants (separated by URL paths i.e. url.com/shop1, url.com/shop2) each with their own set of data. See "canarymarketing-shop" screenshots below! On the front end, visitor users would first register for an account (or log back in), pick free items, and checkout by entering their shipping info. Users had a profile page where they could update their profile/shipping info and check their order status. On the backend, Canary employees on the project would be able to view orders, download distro CSV, update guests permitted to enter, and more. Ultimately the project was a huge success, with ~11,000 happy customers over around a month, ~380,000 page views, and a 10 min average session duration!

Google Analytics snapshot

There were many discoveries for me with this being my biggest app to date:

• The first issue that popped up was some orders were coming in that had the same order number. I soon realized that the speed (1k-2k in an hour) at which orders arrived in the database caused the sequential ordering of order numbers to not work well. This is (obviously) because there is a high chance 2 people place an order in quick succession, so the server will be running 2 back-end functions in parallel, both looking at the current value for the number of orders and then assigning that same number to 2 different orders. I fixed this by simply assigning a random ID to the order, however, I still wanted to count the number of orders, which required me to look at the previous value to increment. The solution was using distributed counters which fortunately was already a plugin available for Firebase apps!
• This version also brought the realization that React and Firebase may not be the right tech stack for a multitenant app. Other players in the industry typically use a sub-domain to permit out their client's web apps, so I began searching for a better solution to this problem.
• I also realized this was still too much of a full e-commerce experience for Canary's use case and thus didn't need a cart checkout process and full account authentication. Fortunately, these are components I built that would be useful to use for the full e-commerce solution in the future.

This webshop project was so successful that I was hired full-time in March of 2021 as their web engineer to bring a full "Canary-custom" e-commerce experience to life. As I transitioned to a full-time employee, I dreamed of a greater web app/shop system that would eventually include customer authentication, admin management, item postings, checkout, and payment. 

"ship-form-template"

I switched my approach to a more simple data gathering method of a simple email guest list sign-in then on the next page the approved user would have info about the event, a gift choice, and shipping fields! Instead of hosting all client "shops" under one domain separated by paths, I decided to create a GitHub template that I could copy to a new repo and just attach a different Firebase project to the backend. The CMS only allows Canary employees to change the guests via single record create/delete or mass upload via CSV, as well as updating orders, which were the 2 most typical functions after the project launched that the admins would need to make. Changes to the theme, products, verbiage, fonts, colors, logos, users, etc would need to be hard-coded to be specific to the project at hand. I would prefer the project not to be separate code bases I would need to then manage, but for this use-case, it worked because the project was typically short-lived. Having a separate code base for each project also allowed me to make highly specific changes to each storefront; the sky was the limit. This helped a ton for making iterative changes based on what the client wanted, I would just copy those changes over to the template for the next build. We ended up hiring a pen test company to audit the build for concerns, which came back with only a few HTTPS headers that needed to be adjusted. We went on to use this template for ~20 production sites before I needed to allocate more time to make this more scalable. Check out the screenshots below for the ship-form-template! Our web store requests were starting to become unmanageable for just me (plus sales teams doing some non-technical platform CMS work) so we needed a better way to also manage all stores from the top level. Ideally, Canary sales team admins or client admins could just log in to the backend themselves and view all stores relevant to their team or client. Admins could then access and adjust specific details about the project like name, colors, logos, banners, products, etc. This is when I started transitioning to the "canary-hub" build!

Example links below, use "doug@canarymarketing.com" or "help@canarymarketing.com" to access (but don't check out so someone else can see haha!):

• https://workdayaltitudegift.com/
• https://ship-form-template.web.app/
• https://gki-swag.web.app/
• https://pure-storage-cx-gift.web.app/

Other links that likely are closed:

• https://stitch-fix-leadership-swag.web.app/
• https://docusign-connect-team.web.app/
• https://zendesk-sko.web.app/
• https://stitchfix-holiday.web.app/
• https://karmanos-team-gifts.web.app/
• https://adyen-holiday-gifts.web.app/
• https://stitch-fix-freestyle.web.app/
• https://workdaycustomerexperience.com/
• https://hubspotproductteam-2021.web.app/
• https://sephora-holiday-gift-2021.web.app/

Traffic for production build "workdayaltitudegift.com"

Traffic for production build "workdaycustomerexperience.com"

"canary-hub"

The natural evolution of this was to create a more multitenant solution, but because of time constraints and resources, I couldn't research and develop a full multi-tenant solution, I needed to rework the ship-form-template a bit so that we would only need to boot up one CMS code base per client account, instead of a codebase for each storefront. This would dramatically reduce the number of codebases we would need to manage, and if built properly, could be transitioned to the full-multitenant solution in the future. I spent about 6 months building "canary-hub" with Geof Rosenmund, spending about half our work days on this research and development project. The goal was to create a "template" for these "hubs" that could be used for all storefronts, but initially focused on the immediate need that the "ship-form-template" solved: quick user validation, gift selection, and shipping info gathering. So a Canary admin could log in, then create "shops" which would contain "products", "orders", "contacts", and "users". All data was generally associated with a shop, but 1 product could be used in many shops and 1 user could be used in many shops. I created an agnostic way for data collected to grow and shrink, as clients' expectations change for projects. The React components I made to perform CRUD on records on the database were easy to plug and play, just by adding a few lines of code. I initially focused on building a "hub" to showcase the features that were specific to Canary, since Canary had our own internal pop-up webshop needs, so we could test it internally, then iterate, then release it to be used for client pop-up web shops as well!

One of the more complex systems in this hub was the role-based access control (RBAC), which was necessary for new ISO compliance protocols. Users would need to go through a 2FA flow to log in (thanks GCP) and they were then assigned roles permitting them from performing specific CRUD (plus if they got CCed or BCCed on create emails) actions on specific tables or even specific records with tables. The system took forever to debug and get right for all the use cases I could imagine, and I learned a ton along the way. After toiling for months on this specific system, the hub was mainly ready to demo.

After many minor and major tweaks to the system, I had to demo the system to the executive team for them to fully grasp what I was working on, and how it could be integrated with the company. The demo went amazing, I feel like I drove home all the points I wanted to make about the system, however, communicating an ambitious build like this in a company full of non-engineers proved difficult. Canary executives decided against pursuing this path, citing concerns about liability insurance for software development, which applies to code touching PII (Personally identifiable information), which is a fair point. They didn't want to invest in resources to build proprietary solutions, and instead use existing solutions like Brightsites, Shopify, etc. I vehemently disagreed, as I wanted the best for Canary and my fellow coworkers to build a lasting brand, but respected their business decision and appreciated them allowing me to research, develop, and learn when working on this code project!

Check out what we ended up building as screenshots below!

Some other projects

• DocuSign hosted multiple stores internal and external through Canary and wanted a single landing page that pointed to all their stores for their employees to use. They provided a wonderful wireframe which I was able to match perfectly. Happy client!
  • https://docusign-merch-hub.web.app/
• Coors needed a landing page for a QR code scan from a physical product, and I was happy to oblige! They provided a simple mock-up that I mimicked to a tee. Turned out simple and perfect!
  • https://coors-bottlerock-vip-suites.web.app/
• Okta hosted multiple stores internal and external through Canary and wanted a single landing page that pointed to all their stores for their employees to use. I made quick and easy work of this, nothing complicated. 
  • https://oktaswagdepot.com/
• View screenshots below!
• "bird-bytes" was an internal GitHub repo organizing various code snippets we used around apps for 3rd party platforms and custom platforms such as email signatures, NetSuite scripts, custom email templates, Wufoo form design templates, and more.
• As domain admin, we regularly bought domains on behalf of clients to connect to the web store we created. Canary's domain organization was a mess when I arrived: some domains were the God-forsaken platform they call "GoDaddy" and others on the archaic "NetworkSolutions" registrar, with many being unused, but set to auto-renew. After much deliberation, I decided on the newly out-of-beta Cloudflare registrar and cloud platform to move all our domains to. After sifting through hundreds of domains and collaborating with sales teams to determine which we needed to cancel and which we needed to move, we landed on moving about 50 custom client domains to Cloudflare. The other 25 we moved were domain variations of Canary, such as .cc, .co, .us, etc. I was able to negotiate and buy a domain from the previous owner who had "canary.marketing", which I was quite proud of too! Now all Canary's domains are safely organized under Cloudflare's infrastructure and I always recommend Cloudflare to all my clients!