Also posted on IndieHackers and DEV.to. See the project case study [here]({{ site.baseurl }}/sz-project-tracker)

Four months ago, I didn't know React or any other JS framework. In fact, having done tons of static web dev work, I was terrified of React. How do you make an entire website in JavaScript??

Still, I wanted to go beyond making landing pages and WordPress templates. I made several attempts at learning React and some backend stuff like the MERN stack. In theory, I know how to spin up a MERN app with a CRUD API and all, but none of these tutorials really stuck with me. I was left not knowing how to deploy the local apps and servers I had built, not knowing how to extend it into something usable.

Eventually, I found my way to serverless-stack.com. This was a huge tutorial that teaches you how to set up an AWS backend (Cognito, DynamoDB, Lambda proxy API), as well as a React frontend connected through it. It didn't teach how to use these tools so much as just use them, throwing new functions and AWS services at you every other page. This is how I learn best, though -- from blitzing through full React page after React page, I started to pick up a better intuition than I had from any tutorial before. I finished the tutorial series in about a week and a half in May.

Throughout the process, I tracked my learning and progress in a markdown file committed to the repo. I did the same for another project. It was really useful to have screenshots and code snippets from previous versions to reference in blog posts, or just for personal reflection. Using a nice, lightweight markdown editor was the best solution I found for jotting down these quick updates, but I kept thinking about how nice it would be to have an app properly designed for this. I looked online, but surprisingly couldn't find one. Well, good thing I've been learning how to make one!

So that's the project that I jumped into: an app to track your projects, making dev and learning logs 10x easier to keep than with a traditional or markdown document editor. I actually ditched the Serverless framework as I was taught in serverless-stack, instead using AWS Amplify CLI to super quickly get all my services up and running; still, serverless-stack served as my main guide, for backend as well as frontend reference.

At some point in the project, I outgrew serverless-stack for both frontend and backend. Frontend came first. Serverless-stack used class components, while newer tutorials used functional components; my code was a hodgepodge of both at the beginning. Josh Kaufman says that, contrary to the 10,000 hours of learning => expert rule, you can learn something reasonably well in 20 hours. I remember almost tangibly feeling this kind of 20 hour mark. I split off my code into components and lib functions, refactored class components into functional ones with confidence. A partner joined the team, and I was surprised to realize how much better I could recognize good or bad React code in PRs just weeks after not knowing React at all.

Backend came much later -- really in the last week, even. I was scared of the Amplify CLI. There were so many config files, with so many parameters and variables. Every push I made came with the warning that things might break, that data might be lost. So I worked with the backend as little as I could at first. I set up auth, storage, API, and just left it; API schema updates were all I dared to run. I couldn't run away forever, though. Two features, both procrastinated until this very last week, forced me to actually learn. One was making images attached to public updates publicly viewable, as they were uploaded into private S3 buckets. My nicely protective Amplify functions weren't enough for this. Now I had to deal with ACLs, using the full AWS SDK, dealing with credentials and auth tokens directly -- diving straight into the backend config stuff that I feared most. The second feature was adding users to a Mailchimp mailing list on signup. Mailchimp has a nice API, but it can't be called on the clientside, so I had to set up a Lambda function for it. I decided to do this on pre-launch day. "This should be quick," I thought at 2PM; at 11:20PM, having coded discreetly through a meeting, it finally seemed to work. I asked a friend to sign up with her Google account, and felt a huge sense of relief when her email popped up in the Mailchimp audience list.

Progress on this project was quite sporadic, as side-projects often are. I would blitz forwards for a week, knocking out feature after feature and squashing bug after bug, then the rest of my life would catch up to me and I would take a lull. When a partner and mentor joined the team, progress actually slowed down; caught in thinking about containerized environments, CI/CD, delegating work, etc., I lost the motivation that came from tangible progress. I was also consistently working in unfamiliar territory. I had no idea how to solve or even approach many of the problems I came up against; I would stare for hours at documentation and tutorial videos, writing test functions, my frustration growing as I didn't seem to make an inch of progress. Out of many, many repeated such experiences, though, I found that this frustrated deadlock often did eventually result in learning and progress. "Micro-framework: let yourself be stuck on things for three hours. Stare at tutorials, write test functions, don't make progress; struggle & learn and eventually it just might click," I tweeted after one session. One potential implication, then, is that this kind of learning and from-scratch skill building can't be done in small chunks, but rather require continuous long blocks of time. (Not entirely sure if this is true, maybe it would actually be sped up if broken apart? To be tested, but the value of long continuous blocks of work time is a popular idea)

One day, I was tired of this project sitting around, draining me of my energy as the rest of my life and what I could be doing flew by.

"We're gonna launch in two weeks, by Wednesday, July 8," I told my partner. Planning out features, we frequently said things like, "this isn't necessary for v1, let's implement it for v2." It's the classic "cut scope rather than extending the deadline" -- and it worked. I had a target. My energy was back. I refactored code, redesigned UIs, and added small missing features like crazy, in the course of four or five days sprinting across the remaining distance to a mostly functional, fairly reliable app.

An online community/program I've been a part of, Summer of Shipping, has demo opportunities at meetings every Thursday. My goal was to demo that Thursday; I grabbed a few screenshots, wrote some copy, and put together a quick landing page (so easy with @rmrm's a17t and Tailwind CSS). My demo was full of bugs (Google sign-in redirected to localhost instead of live site, Twitter URL opened as relative instead of absolute...everything goes wrong in the demo), but it was mostly done and out there!

The idea of a ProductHunt launch was really only in the back of my mind until pretty late on. I had previously launched a Chrome extension, YouTube Liberation on PH. My friends and everyone I reached out to raved about how useful the extension was, but after hyping myself up, greating a fancy animated thumbnail, choosing the day to post to get maximum views, I got all of...three upvotes. For this project, my expectations were basically non-existant. I built it for myself; I hadn't showed many other people, nor did anyone seem especially like they were jumping for it. Still, I had pretty much already made everything I needed when making the landing page. It'd be minimal effort to just hop in Illustrator, turn these into graphics, and toss it up on PH, I thought. This time I at least have the Summer of Shipping network -- maybe it'll get a few signups.

Yesterday morning, I fixed the bugs from the demo, filled out the PH fields, and was about to hit launch when I remembered that PH allowed you to launch through a hunter. It just so happened that @swyx, senior dev advocate at AWS working on Amplify and a huge advocate for the "build in public" mentality that Summer of Shipping and my project tracker alike build upon, had given a talk at Thursday's SoS meeting and seen my demo. I messaged him on Twitter, sending over my prepared slides, asking him if he would be willing to hunt the product for me. I wasn't sure if he would -- were my product, my hastily assembled marketing materials good enough? Would he harshly dismiss me? No! He said yes!

I sent him some more materials. He sent me...bugs that he encountered when he signed up for the app. "Today will be a bit of a bug squashing marathon 😅," I messaged him. "Better prelaunch than postlaunch," he replied.

I had a bunch of other work I was planning to yesterday. For a design job, I needed to put together mockups by Saturday; for an entrepreneurship program, conduct a bunch of customer interviews. Instead of doing this, I ended up spending the whole day fixing bugs and making minor improvements. I changed the url from the abysmal sz-project-tracker-v0.netlify.app to the slightly less abysmal szpt.netlify.app. I wanted a mailing list of people who signed up, so I made a Mailchimp account and looked into their API. This, oh god, this was 8 hours straight of the standstill blundering-my-way-through learning that I had talked about earlier.

Everything was bashed out. The PH page was ready. At midnight, it went live. I woke up at 8:30 AM this morning. The PH page had 8 upvotes. Already broke my 3 upvote record, lmao...but I thought I could do better. I posted on Twitter; I asked @swyx, @irid, and some others to repost; I posted this very blog post, which was originally intended to be mostly promotional but turned into the much more substantial story it is now, on IndieHackers and DEV.to.

As of writing this post, SZPT has 47 upvotes on ProductHunt, dropping from 13th, to 14th, to 15th on the homepage as the day went on, with 27 new signups on the app. It's not huge -- this app isn't "taking off," so fortunately my AWS bill won't either -- but it's a good amount of people using an app that's my first-ever webapp, that I buitl for myself. My only hope is that they'll find legitimate value in it, and value in me as a creator of products.

This is the culmination of two full months of learning and building, from being terrified of JavaScript and writing about the death of hand-written CSS to falling in love with React and CSS frameworks like Tailwind and a17t. Other than technical skills, what have I learned? I think two big ideas have been heavily affirmed:

• "Do to learn, not to do." This is a long-held philosophy of mine, and it's really been the driving force for getting to where I am today. I didn't go to any bootcamps or follow any curriculums in the past two months, but I've made myself so much more valuable by just diving in and trying to make things that I care about (my GitHub got me hired as frontend developer at an early-stage startup!).

• Prioritize connections, people, and communities. Did going to Summer of Shipping talks about the inner workings of authentication or HTTP/CORS help me build my app? No, but it gave me a group of people to be a part of; my work provided value for the community, so mentors could invest their time in me. Indirectly, SoS had a huge impact on my network too, by pushing me to get on Twitter, and creating opportunities for engagement through mentors' and the community's accounts. Through SoS and more broadly on Twitter, I've connected with so many amazing people, building a network of experts and industry professionals as well as people working on their own projects and careers like me, who have kept me going and offered incredible insights and advice when I reached out to them.

These, really, are my two superweapons. They've empowered me so much; the realm of possibilities in front of me seems unbounded. What's next for me? We'll see how szpt goes, maybe I'll work on it a bit more. In the longer term, I have an amazing mentor pushing me to find something that I would want to work on for the next 5-7 years of my life; I'm chasing lots of other opportunities to keep learning, doing, connecting.

I hope you enjoyed reading this post. In my IndieHackers and DEV.to posts, I spammed this pitch for the app all throughout the article. In this more retrospective, chill blog post, I'll just leave it here at the end:

Whether it's to build in public, keep track of work for reports, or just to learn and reflect better, we could all benefit from logging our projects. SZ Project Tracker makes keeping dev logs or learning journals as easy as posting to Twitter 💨

📝 Write in markdown, drop images in 🌎 Make projects & updates public in just a click

▶▶▶ https://producthunt.com/posts/sz-project-tracker