This month's Clerk x Hashnode Hackathon was exciting to me. Authentication is one of those sticky issues that you should never try to make on your own, and the APIs for Clerk seemed mature and easy to use, plus the chance to win some traffic and cash for my effort didn't hurt either!
Well, as I wrote about on Monday things didn't exactly go to plan with the idea that I would have a luxurious four weeks to build a product on top of Clerk and RedwoodJS. Instead, I found myself on Wednesday with 72 hours left before the submission deadline and only the barest idea of what I wanted to build.
So now the question was - could I sprint a product from inkling to prototype (and write a blog post about it) in 72 hours to get it into the running for this hackathon? What tools could I learn in that time to help get me across the finish line?
Shaving down the concept
Before I dove into engineering tools, though, I had to first tackle the product concept itself.
On Wednesday, my concept was this:
DomainWatch is a website where you can search for available domain names, add them to a favorites list, get updates via email on ones that get bought or become available, compare prices across multiple registrars, and (when you're ready to buy) link out to the cheapest registrar to make your purchase.
Great. As someone who has to resist dumping silly amounts of money into Google Domains whenever I have an idea for a side project, the idea of a private wishlist where I could keep track of my ideas was appealing to me. But this was clearly way too much to build in under three days.
I once heard the saying "if you're not embarrassed about your MVP, you waited too long." So, I began mercilessly shaving off bits of scope from my concept. (I also had to change the name because it turned out the one I'd picked was already taken.)
By the time I hit "deploy", the MVP did this:
Watch That Name is a website where you can search for available domain names, add them to a favorites list, see their price on GoDaddy, and when you're ready to buy link out to GoDaddy.
(I'm not a huge fan of GoDaddy, they just had the easiest API to integrate with...)
Fallen by the wayside were: most analytics, periodic email alerts about your wishlist, price comparisons, and all monetization via affiliate or ads. But this was a product that I was both embarrassed by how spartan it was, while also confident that it provided some value over just writing your domain wishlist down on paper.
Gotta Go Fast - Framework as Foundation
As I wrote about in my "Rails of React" story, there is a gold rush on right now among frameworks. Many big name developers are launching free or paid frameworks with the goal of enabling you to prototype or build your app faster.
So, I though this would be a great way for me to get a head-start on my development process. I chose to use RedwoodJS because it's trendy and full-featured, and TailwindCSS because I know it and trust it to make a good looking website.
Of course, it wasn't all perfect. As Redwood is happy to tell you, they are Not Production Ready™️ and I ran into that a few times during this process. Because they are building so quickly on their end as well, a couple of times I ran into documentation that was out of date or features which were not yet implemented. Working my way around these issues killed a couple hours during my sprint, but that time lost didn't come close to the amount of time that using Redwood saved me, especially on the backend. Indeed, at the end of this sprint, I am much more excited about the future of Redwood and much more invested in its success. Now that I "get" it, it feels like the early days of NextJS where there is tremendous possibility for this framework going forward.
Tailwind, meanwhile, remains verbose but excellent.
But What About Clerk?
But what can I say here about Clerk? Honestly, not much, which is downright astounding. After I got Clerk integrated with Redwood, I honestly didn't think about it again until it was time to deploy. It's hard to explain how game-changing that is. I didn't have to think about auth at all during development. It really did "just work" once the initial settings were in place. This was definitely the biggest time saver during development.
The last frontier that is often a time-suck for me during development is being able to set up a staging and production deploy so that I can start bug-testing my code and, eventually, get it live for the world without having to clean out the testing database.
Here as well the tools have come miles in the last five years. For this project, I used Railway and Vercel. These and Clerk all share one feature I simply love: they support separate development and production environments inside of one app from day 1. No longer do I need to juggle different credentials or multiple applications to manage the different stages of the product lifecycle!
So, honestly, there isn't much to say here either. I put the app onto Github, pointed Vercel at it's
develop branches, and connected Railway to Vercel so that it would automatically populate the environment variables for the databases. Again - it was shockingly easy.
So It's Done?
And so after 72 hours, Watch That Name is live. But is it done? No of course not.
There are a wealth of features I cut out of this project to get it done before the deadline. But that's ok - I'm shipping it now while I'm still embarrassed about it with just a basic Plausible.io analytics counter embedded on it.
Nonetheless, though, I managed to build a product in 72 hours! This is something that would have felt impossible during most of my 20's - in part due to perfectionism and in part because Typescript, my preferred language for the web, has lagged behind server-side languages on tooling. But now the fiddly parts of building a web project - the boilerplate dealing with deploy and databases, auth and styling - have been abstracted away by years of foundation laid down by the heroes: open source developers.
Who knows, maybe I'll set aside another 72 hours next month to add on the rest of the features I'd like to have!