I have a friend, Richard. Over twenty years ago we worked together at a small software startup in Kearny Mesa. Since then Richard has delved into real estate and investments, while I’ve continued down the path of a software developer. We hadn’t talked in a while, so we agreed to meet up for coffee about a year ago. 

“I’ll pick you up.”, he offered.

“You sure?”, I asked.

“Yes.”, was his response.

A few days later he rolled up in front of my house in a bright orange McLaren supercar. It stood in stark contrast to my current ride, a 2010 Chrysler Town and Country ( yes, that Town and Country ).

In the blink of an eye my daughter, Kaylee, who had been watching from the living room window, ran outside and pleaded to sit in the driver’s seat.

After Kaylee was pacified I climbed in and Richard and I headed for coffee.

After swerving to avoid anything bigger than a pebble, I realized that supercars come at a cost.

“Your ride is cooler, but mine is way more comfortable.”, I told him. 

“But overall, you seem to be, uh, doing well”, I continued, looking around the interior of his car.

He smiled.

Over coffee we discussed several things, but focused on a project that he wanted to build and launch. He wanted to bring to market a digital guestbook, and was looking for help.

He explained that it could be used at weddings, birthdays, baby showers, etc.., to streamline the process of registering at the party, making it easier for the party’s host to send correspondence. 

“Instead of signing a physical guestbook, guests will photograph a QR Code. The QR Code will redirect them to an online guestbook.”, he told me.

“Then, after the party is over we can automate emails to all of the party’s guests”, he continued.

Without thinking I uttered the words no developer in their right mind should ever say.

“That sounds easy…”, I told him.

And then I uttered the other words no developer in their right mind should ever say.

“It shouldn’t take too long.”, I told him.

Richards’ proposal was timely. 

I had studied Software Engineering in college for the creative aspects: the ability to create something from nothing. For the last year I had been working as an Application Development Manager, and, although the role offered me the chance to mentor other developers and plan and guide projects, it didn’t leave much time to, well, to create. Furthermore, I felt my programming skills stagnating, as well. So, when Richard asked me if I’d like to partner with him, I jumped at the idea.

A year later we launched Deetoh, Rich handling marketing and legalese, and I the software development. Here’s the link :

www.deetoh.com

Please check it out.

The Technology Stack

I decided to use Azure, .NET Core,  Angular, and Bootstrap for Deetoh’s technology stack to create some synergy between Deetoh and what I was doing at my employer, a .NET shop with Azure “cloud” aspirations.

I have been using Angular since its initial implementation a decade ago, so no problem there. Bootstrap, too, although I would be using it foremost for its “mobile friendly” layout engine, and secondly for its UI components. Deetoh was to be a “mobile-first” application, after all. 

I have been using .NET for over twenty years. Back then ASP.NET Web Forms and MVC were king. For Deetoh, however, I’d only be using it to create Web APIs – or, REST APIs that the Angular front-end could consume. In retrospect, I probably should have opted for Azure Functions as hosting a Web API as an Azure Web Service on Azure is pricey. Given Deetoh had no established audience, pay-as-you-go Azure Functions would have been much much cheaper in the short term. On the other hand, .NET Core, which Deetoh’s Web APIs were built upon, can be run as Linux Containers on Azure. Initially, I had everything running on Windows on Azure. After realizing I could migrate to Linux and cut my hosting costs in half, I switched.

Admittedly, Azure was new to me. At my prior employers I had used Amazon Web Services. What I found is that for every product offered by AWS, Azure had a doppelganger. 

I used Azure AD B2C and MSAL for user management and token-based authentication. This project provided a good foundation for my Angular front-end. Azure B2C provided user flows for registering new users, signing in, and password resets. My only complaint is that it proved to be a little lacking in custom claims. The JWT tokens generated by Azure B2C were limited to the standard username, address, phone number, etc….

For security, I would rely on Angular Guards to authorize access to each of Deetoh’s routes. The Guards would leverage the MSAL library to “sniff” the token generated during sign-in. On the backend, the WebAPI would also use MSAL to restrict access to the various REST endpoints based upon the same token. So, even if a user were able to circumvent the front-end’s security, they wouldn’t be able to access any data on the back-end.

My .NET Core Web API would consume Azure’s NoSQL database, called Cosmos DB, using Entity Framework. In retrospect, using an ORM was probably overkill, but the implementation would be sparse and straightforward given the flat, non-relational nature of NoSQL, so I figured, why not? 

To support Deetoh’s emailing of guests I used Azure’s Email Communication Service and a Storage Account. At my employer I’ve used SendGrid for sending emails, but SendGrid only offers up to 100 emails/month for free. After that it’s $19.95/month. Knowing that I’d likely blow well beyond 100 emails in testing alone I opted for Azure’s platform, which charges a flat fee of $0.00025 per email. Azure’s service doesn’t have as much polish as SendGrid, but so far it’s worked out well. 

“If Deetoh ever gets enough traffic so that our costs increase enough to warrant a revaluation of our platform, our service providers, or even a refactoring –  I think it’ll be a good thing!”, I joked with Richard.

That’s not to say Deetoh isn’t production ready, but if it miraculously receives traffic rivaling Evite overnight, there will definitely be growing pains. Obviously, I don’t expect that. Don’t build a cruise ship when a sailboat will suffice, right?

A little help from AI

About a month before launch Richard was demoing Deetoh to a couple of his friends that wanted to use it for their upcoming wedding. At the time Deetoh was fully functional, if not a little rough around the edges.

“It needs a better help experience”, he told me. “They didn’t know how to use it.”

At this point Deetoh’s system consisted of little help bubbles that could be toggled on-and-off. Richard, however, wanted full page overlays with rich graphics.

“Who is going to do the artwork?”, I asked Richard, already knowing the answer.

If you’ve been following my website long enough – heck, just by the website’s name alone, you probably realize that I am an artist, too. However, at this point I had already revised Deetoh’s email feature twice per Richard’s request, and just wanted to launch. After sketching up what I wanted the help pages to look like I quickly realized the custom artwork was going to take a lot more time than I was willing to spend. I started perusing the web for open source artwork, but realized that I’d never find content specific enough. Then I tried AI. 

AI is an acronym that has been met with both fear and excitement. As a software developer, I’m scared that someday it might be able to render code well enough to replace me, yet I am excited by its possibilities as a tool I can use to speed up my daily work. As an artist, I discovered the same fears, only multiplied. I have little doubt that in less than five years the majority of corporate artists will be replaced by AI. Keep in mind I say “Corporate Art”; this is the “generic” kinda’ stuff you see on internal memos, training videos, and the like. Anything public facing will undoubtedly undergo more scrutiny. For Deetoh, however, AI just worked. With the help of a mobile application called Recraft I  was able to generate specific-enough content for Deetoh’s help pages. Admittedly, I still had to make alterations ( i.e. “nip and tuck” ), but overall it took me easily a quarter  the amount of time. As far as the alterations? I vectorized the AI-generated imagery using Adobe Express Online and manipulated the resulting graphics using Inkscape. Here’s a sample of the end result. What do you think?

Closing thoughts

Deetoh took a lot longer than I expected. At most jobs I’ve worked I’ve taken to doubling my estimates and then some when determining how long something will take. Rarely, have I come under ( or over, for that matter ). For Deetoh, I went over. Way over. Why? It came down to two things :

1. A simple misunderstanding between what Richard, the product owner,  wanted, and what I built.
2. An inability on my part to determine how many hours a week I could dedicate to the project.

Ironically, these two problems plague every single software project that I have led or worked on. Part of the problem is Agile Methodologies, or incremental / progressive development. Agile doesn’t leave a lot of time for proper design. However, I’ve worked on way too many waterfall-based projects, Agile’s polar opposite, where all planning is done up front, to realize its faults, too. I’ve seen Waterfall stall out before a single line of code, much less a prototype, saw the light of day. With Agile, the focus is in delivering something, anything. 

Aside from governance, developing Deetoh gave me a renewed respect for Cloud to leapfrog development. There was a time not so long ago where I would have had to provision my own servers, my own user management, my own database, my own authentication, and so on. Now, I can do it relatively quickly ( and cheaply ).  Cloud is not just for large corporations, but for the little guys, too – like Deetoh.

Please give Deetoh a try if you get a chance. 

Thank you for reading!

– Scott

---

#WeddingPlanner #GuestRegistry #BabyShowerPlanning #Guestbook #BridalShower #GiftRegistry #EventPlanning #GuestList #Barmitzvah #Batmitzvah