Prevents serverless cold starts by pinging your API every 5 minutes. Keeps your app feeling lightning fast.

FixColdStarts.com

A progressive web app that lets you easily track reps and weights for all your exercises. Uses Airtable to store your workout data.

Weightlifting Progress Tracker

The #1 app for cross-country skiers with 15,000+ users – available on iOS, Android, and Web. Featured in an article in the Duluth Tribune.

Skiwise – 15,000 users, 4.5⭐ on iOS

A 2022 remake of one of my first coding projects. Built to easily view your most listened to Spotify tracks in one place. 

Discover Your Spotify Top 50

A customizable habit tracking calendar that embeds directly into your Obsidian notes.

Obsidian Habit Tracker

A B2B SaaS tool to generate automated tests for your startup using plain English. Ensure your most important features never break.

TestingBee.io – Automated testing with AI

A tool to create your own draft rankings chart for your fantasy football draft. Customize player rankings and build your perfect draft strategy.

Fantasy Football Draft Ranker

A B2B SaaS tool that transforms your existing Notion pages into a modern, self-service knowledge base for customers.

Engine.so – SaaS Addon Tool for Notion


It’s been a long time since I wrote…  
The reason is this: Why write when an LLM can do it? I wanted to switch mediums. Should I record audio? I recorded a couple things but the ideas don’t get flushed out as well.  

Is faster actually better?


I've always liked the idea of tracking habits. A couple years ago, I had a large whiteboard and I would draw a calendar and put an X on every day where I wrote some code towards a side project. 

When I needed the whiteboard space, I switched to marking an X on calendars printed out on paper. At one point, I had over a year's worth of calendars hanging on the wall. It was super gratifying because I got to see all the months of progress stacked up next to each other.

<Image src='/content/images/2026/01/old-cal.jpeg' alt='Old habit calendar setup' />

Today, I don't have that same habit tracking setup anymore. And this year I realized I've been missing it.

I initially thought about hanging calendars on the wall again, but I felt like there was a better way to do it now.

So, I looked into various mobile apps that do habit tracking. They work fine, but they add yet another thing to sign into. I already feel burnt out from signing into apps all day and spreading my attention across so many platforms.

Then I thought: *what about Obsidian?* I already spend time every day in that app. I write a daily note every day with my tasks and scratchpad thoughts for the day. So why not add my habit tracking to that?

I looked for plugins that could do habit tracking. I found a couple ([Contribution Graph](https://github.com/vran-dev/obsidian-contribution-graph), [Tracker](https://github.com/pyrochlore/obsidian-tracker), etc). These seemed great, but they store your habits in daily notes. And since the data was stored in each note, I couldn't click on the calendar view and mark days as done. So marking previous days meant digging through old daily notes. That's annoying.

So I decided "What's the easiest way to build this myself?". I settled on building a simple web app hooked up to a Postgres database that I could embed in Obsidian via an iframe.

That code is available publicly on [Github](https://github.com/spencerpauly/obsidian-habit-calendar).

Long-term, I could see this information living in my daily notes. It should be possible to go back to old notes and automatically mark them with a property without doing it manually. But I didn't want to go through that hassle, so I'll let somebody else figure that out. For now, this works for my needs.

---

## My habits for 2026

So let's talk about the habits I'm tracking this year!

<Image src='/content/images/2026/01/ff.webp' alt='My habit tracker in obsidian' />

I have 3 main habits I want to track for myself this year.

#### 1. Running and Skiing
I don't have specific goals here, but it's something I like to track. It feels good to know when my last run was and to see how frequently I'm training. It helps me stay motivated and judge how hard I should push myself.

#### 2. Lifting
I've been going to the gym consistently for a couple years now. I've made a couple apps to help track my workouts. Adding this to the habit calendar is just one more layer on top. It's an easy way to see how frequent I train. I already know I go consistently, but having it on a calendar helps me *feel* like I'm making progress. And that matters. Knowing I've been consistent for a month gives me confidence to push myself and lift heavier.

#### 3. Building in Public
This is the big one. And the reason I made this calendar. I define "building in public" as shipping something that's visible to others. Originally I had this habit labeled as "coding" or "side projects" but I realized that's not the metric I care about. Growth, and by extension how much I can gain traction, is the metric I care about. And the actionable way to gain traction is to spend time every day driving awareness. So that's what I'm tracking.

---

## A final note

I want to talk about this last goal a little more.

I'm building a new app called [QueryBear](https://www.querybear.com/), where you can talk to your database like a human. As I build new features, I find myself doing a lot of work that ends up being wasted. This is common when building anything. But, it feels like wasted time. It doesn't end up in the product. It doesn't end up in marketing. But it's also a necessary part of building anything.

So my goal is to share those dead ends as they happen. At least try to create some value from them.

Also, it's 2026. With AI, it's easy to ship new stuff. I should be shipping a bunch of free little widgets like this habit tracker. I build these things anyways, but I don't usually share them publicly. That needs to change. Not just for other people, but for myself so I can get used to promoting something and putting my name behind it.

So yeah, I'm excited for this year. I'm excited for the habits I'm tracking. And I'm excited to see what I can build this year!

--- Spencer



New year, new habits


My blogging journey started 5 years ago on [Medium](https://spencerpauly.medium.com/). I had a blast writing on that platform. Then, I moved to [Ghost](https://ghost.org) and put my writing on spencerpauly.com. I wanted a central hub for my content. 

Ghost was perfect – it had a beautiful editor, [elegant themes](https://demo.ghost.io/), and everything just worked. I was happy there for years.

But something changed this year. I realized I was tired of dashboards – tired of logging into interfaces designed by someone else, adapting to their workflow instead of mine.

The core problem with dashboards is this: <Highlight content={<>
<p>This is so annoying! It's kind of crazy how normalized GUI dashboards have become.</p>
<p>The problem with them is I have to understand their specific way of doing things.</p>
<p>And I have to toggle checkboxes, fill out forms, and click buttons just to have my information locked into their proprietary system.</p>
<p>In an age where AI could configure these settings for me, why am I still using tools that don't support that?</p>
</>}>I have to go to the data instead of the data coming to me.</Highlight>

Every time I need to view something, publish something, or update something, I have to context-switch out of my workflow, log into someone else's interface, and adapt to their mental model of how things should work.

For years, this was just the price of using software. Dashboards were better than building everything yourself, so we accepted the trade-off.

Here's what changed: <Highlight content={<>
<p>Nowadays I can "vibe code" an entire blog like this in a day. And when it's finished, I have full control over design, publishing, and deployment. And since it's code I can duplicate it as many times as I want.</p>
<p>Previously, I resisted coding a blog like this because it wasn't just a day of work, it was a month.</p>
<p>But, today the economics completely flip. Why would I accept someone else's constraints when I can launch my own similar tool in the same amount of time?</p>
</>}>AI made owning my own code less painful.</Highlight>

Previously, if I wanted to code my own blog, I would have to manage metadata, post excerpts, and SEO, as well as everything else around a blog. Ghost was attractive because it had built-in systems for all of that.

However, now with AI, doing all that stuff with code is actually easier than using Ghost. 

Suddenly, having my blog in my own codebase isn't a burden – it's an advantage.

# Creating my blog in 6 hours

Normally, programming your own blog, while not hard, is very time consuming. Not this time.

> I was able to code this blog website in six hours – thanks to AI

First, I gave AI a screenshot of my Ghost site and asked it to generate a stubbed-out Next.js codebase. This created the layout, components, and basic structure in about an hour. It took some back and forth to get the design exactly how I wanted it, but it was much faster to iterate on than I could have done myself.

Then, I exported all my content from Ghost's admin panel – years of blog posts, images, and configurations in their proprietary format. I had AI generate a Python script to convert all that exported content to clean Markdown files. What was once locked in Ghost's proprietary format became portable `.mdx` files I could edit in any text editor.

Then, I programmed Next.js to render these Markdown files as blog posts. I even added custom Markdown components to render editable code examples, highlights, custom tweets, etc. And now I can write directly in my editor with live preview.

I spent another hour or so tweaking the navigation, adding mobile responsiveness, and refactoring the code. I spent another hour redoing my products page. But the entire process end-to-end only took six hours.

Finally, I deployed my new site to Vercel and turned off my Digital Ocean droplet running Ghost. That's $120 a year back in my pocket. The result? I finally own my blog posts. <Highlight id="blog-posts-as-code" content={<>
<p>This means I can treat my blog content like any other code. I can use git for version history, create branches for drafts, revert back to old versions.</p>
<p>Each post becomes a file that can be searched, scripted against, and manipulated programmatically.</p>
<p>Instead of being locked in a proprietary database format, my content is now portable. I can render other things I build within this codebase. I can render these posts in other things I build.</p>
<p>It's amazing!</p>
</>}>My blog posts are now code, not content trapped in a database behind a web interface.</Highlight>


# The future this enables

Now all my blog posts live as Markdown. In the short term, this means I can have custom components to convey ideas better when I write.

In the long term, this means I can have my blog posts automatically fan out to other platforms like [Medium](https://medium.com), [dev.to](https://dev.to), and social media.

I can generate Twitter posts, LinkedIn posts, and other social media posts from my blog posts.

<Image src="/content/images/escaping-dashboard-trap/blog-post-fan-out-to-places.png" alt="Diagram showing markdown file at center with arrows pointing to various platforms like Medium, dev.to, Twitter, LinkedIn" caption="One source of truth, infinite distribution channels - the power of owning your content pipeline" />

I can copy this codebase over to any other SaaS product I launch and spin up a blog for that product in minutes.



Instead of me hunting for data, the data comes to me. And the best part? It's all free. No more paying to upgrade for more features.

# The big picture

In the early 2000s, you downloaded your software as an executable and paid a one-time fee. You owned it forever, but updates were manual and you had to manage everything locally. 

In the 2010s, the big innovation was SaaS products where you pay a subscription and no longer need to download anything. Everything was always up-to-date and accessible from anywhere, but you had to adapt to their interfaces and workflows.

The next innovation is one that's been enabled by AI: 

> SaaS tools that come to you.

More specifically, SaaS tools that come to you wherever you interact with LLMs. You shouldn't have to tweak knobs and toggle settings. You should be able to operate as a manager. You should be able to give AI instructions and have the AI manage things at a more granular level.

For me, where I interact with LLMs is in my code editor. So naturally, bringing workflows into a codebase makes the most sense for me.

Take an analytics product. Yes, it's nice to have a dashboard to look at trends, but most of the time you spend interacting with analytics, you have a very specific question you want to answer. 

Something like: "How did my last email campaign do in terms of sales of this product?" 

You shouldn't have to dig around a dashboard to get this information. You should be able to ask an AI and it should generate you a chart right there in your chat window.

And it should be a two-way street. The AI should also be able to start a chat with you. If it notices a sharp drop in sales for a product, it should alert you and be able to give you any context needed to understand the problem.

This is a fundamental shift away from a world of dashboards and email alerts and into a world where the LLM is your proxy for interacting with the world.



For me, this blog migration is just the beginning of a push towards that future. I'm pulling more of my digital life <Highlight content={<>
<p>I plan to build another SaaS product soon, but I don't want it to be a dashboard-based one.</p>
<p>It's going to be something where you interact with it through a chat and you don't have to do dashboard-level knob tweaking.</p>
<p>The future of software isn't more dashboards – it's allowing you to do your job at a higher level of abstraction.</p>
</>}>out of dashboards and into conversations</Highlight> – not to build everything from scratch, but to build interfaces that come to me instead of forcing me to go to them.

Everyone should be able to feel like Iron Man interacting with Jarvis.

<Image src="/content/images/escaping-dashboard-trap/jarvis-ironman.webp" alt="Iron Man interacting with Jarvis holographic interface" />


I ditched my blogging platform


A few years ago, I was building a product, moving fast, shipping features daily — until **my test suite became the biggest bottleneck**.

Every small UI change would break my E2E tests. Fixing them quickly became a full-time job.

My test suite, which was supposed to give me confidence, **was doing exactly the opposite.** It was slowing us down, causing false alarms, and requiring constant maintenance.

At one point, I remember merging what I thought was a harmless UI tweak — just moving a button. And **boom** — dozens of tests failed overnight.

I spent hours debugging, only to realize the tests weren’t actually broken. They were just **too fragile** to handle real-world changes.

And that brings us to the root of the problem.

> "Traditional automated tests are too fragile to handle real world products"

So, I knew there must be a better way.

That’s why I built **TestingBee** — an AI-powered tool that rethinks E2E testing from the ground up. No more brittle selectors. No more constant maintenance. No more time wasted writing test scripts.

---

## How does TestingBee.io work?

My tool handles the entire job of automated testing for you, without any micromanagement needed on your part. Instead of writing tests, you simply define broad goals that you want a user to be able to accomplish.

You don’t do this through code, but through simple explanations of end-user experiences. So an individual test will look something like this:
<Image src='/content/images/2025/02/Screenshot-2025-02-10-at-10.45.36-AM.png' alt='' width='lg' />
This means you define test instructions in **pure english**. And my AI determines the code needed to accomplish that test automatically.

---

## What this means for is the Future of E2E Testing

I built **TestingBee** to solve the exact problems that frustrated me and countless other developers. Here’s how I believe this will change E2E testing:

#### 1. No More Flaky Tests

Since TestingBee understands intent rather than relying on brittle selectors, your tests **don’t break every time you tweak the UI**.

#### 2. Faster Development, Fewer Bottlenecks

No more spending hours fixing tests. No more waiting on QA to manually write test cases. **Just ship faster with confidence.**

#### 3. Testing for Everyone (Not Just Developers)

PMs, designers, and even support teams can write tests in plain English. No need to know JavaScript or deal with code at all.

---
<Image src='/content/images/2025/02/Screenshot-2025-02-13-at-12.35.19-PM.png' alt='' />
## How to get Early Access (for free)

I built **TestingBee** because I was tired of fighting my test suite. If you’re frustrated with this as-well, then I’d love to get you early access **for no charge**.

This is a self-funded startup and I want to have frequent communication with customers so if you want to provide feedback and direction I won’t charge you until it meets all your needs.

For now, the app is working so feel free to try it out: [testingbee.io](https://testingbee.io)

Introducing TestingBee.io!!!


I've been using Obsidian for my note-taking workflow, and I want to share an overview of how I use it and why it's incredibly helpful—especially when combined with AI.

## What is Obsidian?

**Obsidian** is a powerful knowledge management app that stores notes as plain markdown files on your local machine. Unlike cloud-based note apps, you own your data completely. 

What makes Obsidian special is its ability to link notes together, creating a "second brain" of interconnected thoughts and ideas. 

It's highly customizable with plugins and has become popular among developers, researchers, and anyone who takes their note-taking seriously.

## My Note-Taking Philosophy

![Daily note example in Obsidian](/content/ai-blog/02/obsidian-daily-note.png)


I mainly use Obsidian's **daily notes** feature—a plugin that automatically creates a new note for each day with the current date as the title. 

This approach aligns perfectly with how I naturally take notes. I prefer to scratch things down quickly—like writing on a scratch pad—without worrying too much about organization in the moment. 

My goal is to capture all the context while it's still fresh.

### Keeping It Simple

I've never been a big note-taker, and this minimalist approach works really well for me. 

When I'm making a to-do list, I prefer smaller, actionable items rather than long descriptions for each task. Simple bullet points are all I need to stay productive.

## The Daily Notes Workflow

With the daily notes plugin enabled, I use `CMD+D` to automatically jump to today's note, and I write everything there. 

Every meeting note, every todo item, every random thought—it all goes into that day's note. I almost never create a dedicated document for something unless it's a project I plan to work on over the course of many days. 

This keeps my workflow fast and friction-free.

The beauty of this system is its simplicity: one note per day, timestamped automatically, and I never have to think about where to put something or what to name it.


## The Problems with Unstructured Note-Taking

![Unstructured note-taking example in Obsidian](/content/ai-blog/02/obsidian-unstructured-example.png)

As you can see, unstructured notes are easy to write. But they're a mess.

While this free-form approach works great for capturing thoughts in the moment, it does come with two significant challenges:

**A. Discoverability**: It's very hard to find things again because you're not thinking consciously about organization when you write the notes down. 

What folder should you look in? What did you even title it?

**B. Limited Context**: Individual notes are often brief and lack enough context to be easily searchable through traditional keyword search methods. 

If you wrote "call Sarah about project," three months later you might not remember which project or even which Sarah.

## Where AI Becomes Essential

This is where AI transforms the entire system. Daily notes work exceptionally well with AI because they add a **timestamp** to everything by default. 

If I want to find something I wrote down from a meeting last week, I can look through those seven daily notes—or better yet, have AI search through those seven notes for me with natural language queries like "what did I discuss about the API redesign last week?"

## The Power of Temporal Context

The timestamp functionality is key because it adds crucial metadata that I don't need to manage manually. 

I usually have at least a vague sense of *when* I wrote something down, even if I don't remember *what* I called it. 

The automatic timestamp gives AI a powerful organizing principle to work with when searching and connecting ideas across time.

## My AI-Enhanced Setup

I use AI to organize my daily notes intelligently and search through them semantically. 

Instead of remembering exact keywords, I can ask questions in natural language and AI understands the context and intent behind my query.

I also use the **OmniSearch** plugin as part of this setup, which provides powerful search capabilities that work beautifully alongside AI assistance. It indexes all my notes and makes them instantly searchable with smart ranking.

## The Best of Both Worlds

This combination of unstructured capture with AI-powered organization gives me the best of both worlds: the freedom to write naturally without friction or overthinking structure, and the ability to find and connect information later with minimal effort. 

I can be messy during capture and let AI handle the organization when I need to retrieve information. 

It's like having a personal librarian who automatically catalogs everything I write, even when I'm too lazy to do it myself.


Integrating AI with Obsidian – how I make notes easy


For the past month, I’ve been building a new SaaS product, and today I’m excited to share a sneak peek of it with you!

This is particularly exciting for me, as I haven't launched a paid side project since [Engine](https://engine.so). And although I’ve built things between then and now, none have sparked my excitement enough to bring them to market.

So what makes this product different?

I look for a few things when I build a side project. I want to build a product that is B2B, SaaS, and solves a problem I personally experience. I also want to build something that's feasible to build as a solo developer. And, I want to build something thats easily "pivotable", meaning most of the code can be reused if there's actually a different problem I need to solve.

It's hard to find something that checks those boxes, but this product does.

I decided to build this product after working in the startup world these past two years. During this time, I kept witnessing a consistent problem over and over. And it's a problem that I've also experienced frequently at [Engine](https://engine.so) and [Skiwise](https://skiwise-app.com).

And the problem is this: products break – but, testing is costly. For startups, achieving both development speed and product stability can seem essentially impossible.

## The status quo

Currently, the way to prevent products from breaking is by writing automated tests. These tests define the steps needed to do a task in your product, and run automatically when you deploy changes.

For example, an automated test that verifies an "Edit profile" form is working might look like this:

```tsx
import { test, expect } from '@playwright/test';

test('allows user to edit profile and save changes', async ({ page }) => {
  await page.goto('https://yourapp.com/profile/edit');

  await page.fill('input[name="name"]', 'John Doe');
  await page.fill('input[name="email"]', 'john.doe@example.com');

  await page.click('button:has-text("Save Changes")');

  const successMessage = await page.locator('text=Profile updated successfully');
  await expect(successMessage).toBeVisible();
});
```

Apps can have hundreds or even thousands of these tests and they all get run before every new update is deployed. Awesome!

But wait... Do you notice something with the test above? What if we update our app and rename the "Save Changes" button? Or add a 3rd input to the edit profile form? Or move the edit profile page elsewhere?

This is the root problem with automated testing. They will test your functionality, but they're extremely brittle to changes. This makes it difficult to have complete test coverage while also pushing new features as fast as a startup needs to. 

The other problem with automated testing is they are time consuming to write. This is a simple example, but commonly your tests are much more complicated. And again, multiply this work 100 times over.

Essentially, automated testing code follows an efficiency graph like so:
<Image src='/content/images/2025/01/Screenshot-2025-01-16-at-6.56.22-PM.png' alt='' />
As you can see, adding more tests increases your confidence that your app works, but also hinders your development speed at the same time.

## The problem

For most companies – the fact they have to write and maintain automated tests isn't a problem. The value of testing outways the cost towards productivity. That's because typically a new feature is never as valuable as your existing ones.

But, for startups this typically isn't true.

A startup exists to solve problems for their customers. A product is the proposed solution. Tests ensure the solution keeps functioning as intended. But here’s the bigger question: what if your product isn’t the right solution to begin with?

Some argue that you should always test your product rigorously, but I believe testing should come with a purpose. That purpose being to ensure your product keeps solving the problem for your customer.

If the goal of a test is to ensure your product continues solving the problem, shouldn’t the first priority be validating that your product is solving the problem in the first place?

Shouldn't you ensure that it’s a viable business before focusing on its technical reliability with testing?

Most startup founders would agree with me, therefore, you hear this common phrase around the startup world a lot:

> "Move fast and break things" - Mark Zuckerberg

But, I believe we can do even better than this mantra.

## Move fast and don't break things

And that brings us to the solution I've been building for the past month. I built a tool that automatically tests if your product is fully functional, and does it without the overhead of traditional automated tests.

My tool handles the entire job of automated testing for you, without any micromanagement needed on your part. Instead of writing tests, you simply define broad goals that you want a user to be able to accomplish.

You don't do this through code, but through simple explanations of end-user experiences. So your testing suite will look something like this:
<Image src='/content/images/2025/01/Screenshot-2025-01-16-at-5.51.13-PM.png' alt='' />
Through these broad goals – AI will walk through your site and generate the specific tests you need automatically. Essentially writing your entire automated testing suite for you.

Then, on any code change, we will run those tests against your product to ensure your code is still functioning exactly as it was before.

## But, what if a test fails?

Unlike traditional tests that only have specific instructions, our approach includes both the specific instructions and a broader goal for each test. This means a test might fail on a specific detail, but still meet the broader goal.

For example, if the goal is “a user should be able to edit their profile,” deploying a code change that renames the “Save Changes” button to “Save” would cause a specific test to fail. However, from the user’s perspective, this product is still functioning perfectly.

And truly, this test shouldn't fail. You want your tests to ensure that your product is functional. But, in the real world tests almost always fail from a product change that doesn't break the user experience.

Here’s where we shine: we can determine if your product is broken or if it's just a code change that means you need to update your test. And if it's the latter, we'll heal your test automatically with just the press of a button.

So, for the example above, we'll update the specific instructions to check for a "Save" button instead of a "Save changes" button, re-run the test, then save it to be updated moving forwards.

No more pushing code changes simply to update your testing code.

Another advantage of this is that we remove the false alerts that you would otherwise get frequently. Since we can identify when a test is a product breakage and not just a product change, those high priority alerts mean something!

I'll be launching soon, there's still functionality to add but I have the core working and I'm excited to share it!

Anyways that's all, thanks!


I'm working on a new product :)


This is just a brain dump of how I program my weightlifting.

This isn't really a guide or strategy for how to get optimal results. There's plenty of those guides out there. 

Personally, I feel like the difference between "good" programming and science-backed "optimal" programming is not as significant as people might imagine. Like 1% significant.

At the end of the day, like anything, consistency is what truly matters. So, this is how I've programamed my workouts to allow me to be consistent on good days, bad days, and everything in-between.

## Identify Goals

Goals will be different for everyone. But it's important to shape your workouts around your goals at the time. I'll ask myself questions like:

- How much time do I have per week to train?
- Where does lifting fit in my priorities? Above other sports?
- What's my end goal?

In my case, I have conflicts on two days each week, but can train the other 4 to 5 days with regular consistency.

In regards to my priorities: I'm currently also running. This is to train for the winter nordic ski season, but since that is still many months away it's a lower priority than my lifting.

And my goal is to look better, be more athletic, have a block of time in my week where I can listen to music & think, and see my brother at the gym.

With all this in mind, it's now time to figure out the training program. And the goals will impact how you program things. For example, if running was my priority instead of lifting, I might decide to only lift 1 or 2 days per week. 

So consider your priorities as you read further.

## Training Split

First, it's time to decide on a training split. When you lift heavy weights you break down your muscles and need to give them time to recover before you work them again. This recovery process takes a minimum of 1 day.

That's why training splits exist. They determine your strategy for training certain muscle groups and giving them optimal time to recover.

Here are the most common training splits:

**Full body**
<Image src='/content/images/2024/05/Screenshot-2024-05-12-at-9.17.23-PM.png' alt='' />
**Upper/Lower**
<Image src='/content/images/2024/05/Screenshot-2024-05-12-at-9.17.46-PM.png' alt='' />
**Push/Pull/Legs**
<Image src='/content/images/2024/05/Screenshot-2024-05-12-at-9.18.00-PM.png' alt='' />
I currently train using a **full body split**. Which means I train my entire body, then take a rest day, then full body, rest, every other day. There's many reasons I do this but the main one is this: 

*Flexibility.*

The gym is important to me, but so is the rest of my life. And last-minute conflicts come up all the time. I can't emphasize this enough. I have lifting as a high priority, but I still find myself frequently needing to move workouts around.

But, that flexibility is exactly the reason I love a full body splits. This split has the highest ratio of rest days to training days. This means that even if I have to "miss" a day in the gym it's not a problem.

There's always an ability to move rest days around and not impact your progress.

I try to be as consistent as possible going to the gym. I schedule my workouts on Monday, Wednesday and Friday. But, even then I still need to move things around a lot. Take a look at my log for my last month of lifting:
<Image src='/content/images/2024/05/Screenshot-2024-05-12-at-9.40.36-PM.png' alt='' />
 As you can see from this chart, it's extremely common for me to miss a workout. And this is almost always due to things outside my control.

If I was doing one of these other splits, it might be 3 or more days before I can train that muscle group again.

But, full body training means I can miss workouts no problem. I just take my 2-day rest day early or later in the week, then get right back on track.

Also, if I'm going somewhere for a weekend I can schedule around that easily. I can train on Thursday, take a rest on Friday and Saturday, then train again on Sunday. No missed workouts needed.

## Exercise Selection

When it comes to exercise selection, I have two categories of exercises. One is main exercises, and the other is assistance exercises.

The difference between these two is primarily regarding how much focus/effort I put towards the exercise.

**Main exercises - **Compound movement. Usually 5-12 reps. Try to increase weight or reps every workout. Need usually a certain song & lots of focus to succeed at the lift. Needs 2-4 minutes of rest between sets. 3 sets each.

**Assistance exercises -** Typically an isolation movement. Usually 8-15 reps. Don't focus on increasing the weight. 1-3 minutes of rest between sets. I usually superset these to save time. 2 or 3 sets each.

### Main Exercises

For my full body training split, I select 1 compound exercise in each of these 3 categories and those become my 3 main exercises. I always have 3 main exercises:

**Legs** - ex. Squats, Deadlift, Front Squats, Lunges

**Push** - ex. Bench, Incline Bench, Overhead Press

**Pull** - ex. Pullups, Dumbell Row, Cable Row, Chest-Supported Row

I personally do: Squat, Bench, & Dumbell Row. And I'll switch up these main exercises every 2 months or so. For example, I switched from flat bench to incline bench a couple months ago.

Also, sometimes I'll keep an exercise around for longer if I enjoy it still. Squats, for example, I've done every single workout since I started training.

### Assistance Exercises

These are usually selected to make up for a body part that could be targeted well enough in the main exercises. Typically this is the arms, shoulders, hamstrings, calves, forearms, and abs.

The exercises I typically do here include bicep curls, tricep extensions, romanian deadlifts, and side lateral raises.

I treat these as fully optional. If I feel great I'll do them, if not I'll skip them, do some of them, or do less sets.

It's important to note that even if you skip these you're still working these muscles with the main exercises. A bench press will inevitably use your triceps. A row will inevitably use your biceps. So, I treat these as extra credit. If I skip them, no problem!

I'll swap the exercises every month or so. For example, swapping cable tricep pushdowns for overhead tricep extensions.

## Progression Scheme

The next important point is progression scheme. I think it's really important to go in and do the same lifts week to week and actively try to improve at them.

I do something called double progression which sounds complicated but really it just means increasing the number of repetitions within a rep range, then increasing the weight once you hit the top of that rep range.

So for a program where I'm trying to squat 3 sets for 6-8 reps, my workouts might look like this:

[monday] 3x6 Squats @ 100lbs

[wednesday] 3x8 Squats @100lbs

[friday] 3x6 Squats @ 105lbs

As you can see, I added weight when I hit the top of the rep range on my first set. I find that a rep range of 3 reps (ex. 6-8, 8-10, 10-12) and an increase of 5lbs is optimal. 

Generally if I can do 8 reps of 100lbs that's around equal in difficulty to 6 reps of 105lbs.

I also track these lifts in [KeyLifts](https://www.keylifts.com/), and I love looking back at the graph to see how much stronger I become over time.

When programming my assistance exercises, I'll also have a rep range. But I'll increase weight more based on how I'm feeling.

## Program Template

So that's basically how I program my lifts. Here is an example program I would run: 

    Main Exercises
    
    3x6-8 Squat
    3x6-8 Bench
    3x10-12 Dumbell Row
    
    Accessory Exercises
    
    2x10-12 Bicep Curl w/ Superset: 2x10-12 Tricep Extension
    2x10-12 Romanian Deadlift w/ Superset: 2x10-12 Lateral Raise

This workout will take between 30-90 minutes. The assistance exercises are always optional, so sometimes if I'm time constrained I will skip them.

I tend to skip them about 30% of the time for a variety of reasons. Sometimes I'm meeting with friends, or I want to go for a run, or I'm just hungry and want to go eat.

The main exercises alone usually take 45 minutes. I'll take my time and try to rest fully and push the sets hard. But, these can be done faster if I'm in a time crunch. I'll just need to lower the weight for sets 2 and 3 so I don't need to rest as long.

## 33/33/33 Rule

One point that I want to emphasize is how important it is to have a minimum viable workout. What I mean by that, is you need a workout that you can complete even on your worst days.

I generally like to think of that as 33/33/33 Rule.

I find that:

33% of the time I feel **great**. I'm strong, the music has me amped, I'm excited to be in the gym, I'm loving life.

33% of the time I feel **okay**. I feel fine, but it's not a particularly exciting workout. Just another day at the office. 

33% of the time I feel **horrible**. I feel weak, stressed, sad, overwhelmed or maybe a combination.

I optimize my training so that I can do it in any of these 3 moods. If I'm feeling great, I do all the assistance exercises. I might even add a 3rd set to them. And maybe run afterwards.

But, if I feel bad I'll just do the 3 main exercises and go home. And that's still a winning day, because my measure for success is defined as simply getting those 3 main lifts done.

It also helps when I'm feeling bad and considering not going to the gym. It's motivating to know that a successful workout takes only 30 minutes. I can convince myself to go if it's only 30 minutes.

And occasionally a surprising phenomenon happens. I'll go to the gym on a day I don't want to and I'll end up having an okay or even a great workout! In fact, this happens almost 50% of the time. So, workouts can be a superpower that can flip my entire day around.

And, one final point here:

Your minimum viable workout doesn't need to include going to the gym at all. It can be a 15 minute workout of bodyweight squats, pushups & situps.

At the moment lifting is high enough priority that I'll go almost every time, but in the future that might not be the case. For example, in the fall I plan to prioritize my running and cardio training.

At that point, my plan is to set up a home gym with dumbells to reduce the friction. So there's lots of flexibility.

Okay, that's the brain dump.

Bye!



Picture yourself and a hundred other souls stranded on a remote island. You wake up and jump right into the daily grind of hunting, fishing, and cooking. It's simply your way of life.

But, one day, as you struggle to catch elusive fish, a spark of ingenuity ignites within you. So, you venture back to your secret cave.

You grab some sticks, flint, and rope, and begin fashioning a tool to revolutionize your survival. Some time passes, and finally, you've finished it. 

You've created a bow!
<Image src='/content/images/2023/09/aaa2.webp' alt='' />
Excited about your invention, you proudly march back to camp and unveil it to your fellow islanders. Their initial intrigue quickly turns to skepticism as they trial your creation. 

"Sorry, this makes no sense to us, we don't want to use this," they declare. 

Defeat hangs in the air, casting a shadow over your ambitions. But, the sun sets, and when it rises again you have a new idea. So, you return to your makeshift workshop. This time, you grab a longer stick and a bigger piece of flint, and in the afternoon you craft something new again: a spear! 
<Image src='/content/images/2023/09/aaa.webp' alt='' />
A new weapon that connects you to your primal instincts, a tool with the potential to change the game. As you test it out, the satisfaction of a successful catch courses through your veins.

Eager to share your newfound discovery, you rush back to camp. To your astonishment, you find your fellow survivors waist-deep in the water, with a pile of fish laid out on shore.

"What's going on here?" you inquire.

"Oh, this morning Jax made us these poles for fishing. They work really well, we've caught hundreds of fish already," they respond nonchalantly.
<Image src='/content/images/2023/09/pole.webp' alt='' />
Disheartened, you retreat to your cave, grappling with mixed emotions.

---

### Back to the present

Over the past year, my focus on startups has taken a bit of a backseat. I used to believe it was due to a fear of failure. Or, possibly I felt burn't out and simply needed a break. And, it wasn't until recently that I realized this isn't the case.

*I don't mind failing.*

Just like the island story, I don't mind it if the group doesn't like my bow. If I have to go back to the drawing board again and make something better, then that's what I'll do. That's what I strive to do regardless. 

*So, what has been holding me back from diving into a new startup venture?*

Well, I've realized the crux of my hesitation lies in my aversion to competition. I find it challenging to navigate the negative emotions that accompany the competitive landscape of innovation. It's disheartening to witness other products surpass yours in features, gain more traction, or appear more polished. 

And in the world of entrepreneurship, it's impossible to ignore the competition. As an entrepreneur, staying informed about the competitive landscape is part of the job.

So, that makes things extra challenging for me.

My primary drive in creating things has always been the same. I want to manifest my vision in the world, to craft something exceptional. However, to do that there's challenges that come with exposing one's heart to a fiercely competitive world.

Copycat products will emerge. Some copycats will emerge and grow even faster than you will. Somebody might call your product the copycat. The fact is, 

> There is a product or person in the world that is better than you. Always.

<Image src='https://media.tenor.com/Z3jBRjNIWCoAAAAC/kanye-west-but-im-the-best.gif' alt='But...But I&#39;M The Best' />

And, as a first step, I think I need to internalize and accept that fact. Jax might've made the fishing rod for the whole village, but do I accept defeat at that point? Or, do I go back to the drawing board same as I did before?

I need to learn how to follow my own creative vision, rather than the world around me. Instead of viewing competition as a hindrance, I should reframe it as a source of motivation and inspiration. If a competitor is growing faster than me, I should figure out why. Instead of feeling jealous I should feel curious.

Likewise, it will be important to build a support network of like-minded individuals and mentors who've been in this position before. Everyone, even those at the apex of their field, have felt this feeling before. So advice or support shouldn't be hard to find.

Finally, I want to set myself clear goals. I want to create objectives that flip the game from being me vs. them to being me vs. me. By measuring success against myself, I can maintain that sense of fulfillment regardless of external factors. To do this, I plan to put up a weekly revenue chart. I want to keep my focus on Spencer Today vs. Spencer Yesterday, regardless of the state of the competition.

In conclusion, this is something I've been thinking about lately. I don't have the solutions, and likely it will take me a lot more time to find the solutions, but I felt like I needed to jot these feelings down. If you're also an entrepeneur who has felt similar, what works for you?


Feelings and Competition


Last week I woke up to an email from my friend and fellow bootstrapper, [Tyler Dane](https://www.youtube.com/@tylerdane-com/featured) inviting me to join him and others on a 15-day productivity challenge.
<Image src='/content/images/2023/08/Xnapper-2023-08-15-21.28.01-1.png' alt='' />
The premise is simple: For 15 days, spend 30 minutes a day being productive towards your chosen goal. To make it easier, we're doing this challenge with an accountability group of 15 people and we're sharing our progress in a Discord group.

The problem is – this really isn't an optimal time for me to do a challenge like this. The rest of my week is busy. And, my weekend is busy. And, next week is busy. You get the point. But, Tyler addresses this well in his invite email:
<Image src='/content/images/2023/08/Xnapper-2023-08-15-21.28.58.png' alt='' caption='Quote by Tyler Dane from the 15-Day Challenge invitation email' />
And, this is true. Life is always busy. And, while things may seem busy, I believe the act of being too busy to do something really just boils down to prioritization. If you're not able to make something a priority, that's fine. But, if building a SaaS product is a higher priority than some other things in my life, then I need to re-evaluate my priorities.

So it forces me to look deeper. Am I really too busy? Do I really not have 30 minutes a day to work on a product? And, the answer is no. I do have the time.

## What's stopping me from creating?

The truth is – what's stopping me is fear. 

Every time I've launched something in the past, I feel like there was a month or two of adrenaline that pushed me through the initial fear of launching a new product. 

With Skiwise, I was pushed forwards because it was November and the skiing season was about to begin. I physically had to launch the product in the next month or risk waiting a year. And, that motivation worked, [since I built and launched the MVP in 30 days]({GHOST_URL}/tech/development-journey-of-skiwise/). 

Likewise, when building Engine.so I was also time constrained. I had a limited amount of time to launch my product before starting my first post-graduation full-time job.

So, I ask myself:

💭 How do I create this sense of "time scarcity" today?

I think a challenge like this is the best way. I've written about [how to regain productivity as a bootstrapper]({GHOST_URL}/blog/productivity-advice-for-bootstrappers/) in the past. I believe the best way to do that is to build a small project in public. Exactly as this challenge suggests.

## What's the plan?
<Image src='/content/images/2023/08/Xnapper-2023-08-15-21.31.27.png' alt='' />
I'm going to build a Chrome extension that hooks into Gmail and auto-populates your email reply field.

I had this idea because I frequently use email to communicate with customers at Engine. Sometimes customers have purchasing questions, billing issues, or feature requests, and currently, my flow is annoying.

Currently, I have a repository of answer templates in Notion that I copy/paste into Gmail then fill them out to respond to a customer. But, what if this process could be smoother?

Instead of copying a template like this:
<Image src='/content/images/2023/08/Xnapper-2023-08-15-21.32.29.png' alt='' />
What if I have a button in Gmail that can populate my reply automatically with this template? And better yet, what if it can even fill out some of the fields in the template automatically using AI and the context of the email thread? 

That's what I'm planning to build in the next 15 days.

## Cheers 🎉 to shipping new things!

I feel like the idea stage is an easy place to get stuck when building a business. My brain is really good at filtering bad ideas. Almost too good. So good that I rarely give decent ideas the benefit of the doubt.

I'm hoping to clear the distractions and just focus on shipping the next 15 days. I know it's likely that what I build in these 15 days won't be a success. There's probably an existing product that does it better. But, building it will do the following for me regardless:

(a) Solve a pain point in my current workflow

(b) Get me in the **habit** of shipping software

(c) Give me a product to iterate from when developing my next SaaS business

And at this stage, the multiplier from these things will contribute 100x more towards success than the multiplier from a better idea.

---

Anyways, you'll hear from me again at the end of the 15 days! 

And, if you're reading this and considering doing something similar, take this as a sign that you should start this challenge yourself. Count this moment as your day 1. Don't start next week, don't start tomorrow, start right now. Do your first 30 minutes, and create something extraordinary!


Today I Start a 15-Day Productivity Challenge


Guys I'm gonna be honest, I think I'm at the beginning of becoming an "old man" in tech.

What I mean by that, is that I've become more opinionated and resistant to change than I used to be in the past.

Two years ago, when I built things my opinions on that tech stack changed every 2 months. One day I'd like CSS-modules and the next day I'd ditch it for styled-components. But today, my decision making regarding tech has remained pretty consistent.

I like to think this is because I've found a local-maxima where my productivity is peaked. But am I truly at the peak?

<Image src='/content/images/2023/01/mountain-01-1.png' alt='' />

And this is hard for me to grasp. Is the speed of innovation in the tech world slowing down? Is my personal growth slowing down? Or is this just a natural thing that happens as people become mature in an industry?

I'd like to think it's the third thing. 

I remember 4 years ago when I was first learning React. I picked up basic React quickly, but quickly ran up against the question: What should I use to do state management?

And there's a lot of options out there. So, since they were all new to me I tried them all. And my learning path over the next couple months went something like this:

<Image src='/content/images/2023/01/pathway-01-1.png' alt='' />

Each time, I ripped out the old framework, plugged in the new one and evaluated how I liked it.

But today, this process would look much different. See, I have more *general tech* background knowledge. I know, for example, thatI can't move fast enough with Redux. It doesn't matter how popular the framework is.

Additionally, back then I was evaluating every piece of tech against what I knew. And since I knew very few alternatives, every piece of tech seemed great.

But, today? I already have alternatives that I *really love*. So to convince me to ditch my current setup, you have to really sell me.

That doesn't mean I have no pain points. I have *many*. But, if you fix a pain point and introduce 5 more, that's a net loss.

---

With the preamble out of the way, let's dive into things. I'm gonna break down this article into the 4 main components of software and describe what I'm using today and what I want to try in 2023.

## Frontend

At this point, I feel my front end stack is pretty solid. I move quickly with it, and now have years of boilerplate and bug-squashing experience to push me even faster.

**Next.js –5⭐** – Absolutely no plans to stop using this in 2023 and beyond. Amazing! And they've got such a compelling future roadmap.

**TailwindCSS – 5⭐** – I'm a massive fan of Tailwind. I've probably gotten 100 hours of my life back thanks to Tailwind.

**Chakra UI – 5⭐** – Some might argue a UI Library with Tailwind is redundant. And I tend to agree, however... I've wasted so much time designing the perfect interface for a button component. My conclusion?

Designing reusable UI components is damn challenging. Maybe you build a button, but what if you want that button to be representable with an `<a>` tag? Or what if you want an `isLoading` prop to show a spinner over the button? What if you want to change the spinner?

Every time to make an API change you possible break 100's of areas in your app where this reusable component is used. As a result, I want to leave this job up to the professionals.

And Chakra, in contrast to the 10 other UI libraries I've tried, absolutely crushes it with their API. Plus, their components look great and need no aftermarket editing to fit my design goals so that's a win-win.

> As much as I love [@tailwindcss](https://twitter.com/tailwindcss?ref_src=twsrc%5Etfw), recently I&#39;m kinda loving the out-of-the-box defaults from [@chakra_ui](https://twitter.com/chakra_ui?ref_src=twsrc%5Etfw).  It started with buttons, form inputs, modals, but I&#39;m slowly loving the text component, heading, etc. 
> 
> I&#39;d still crown tailwind as 👑 king for layout. [pic.twitter.com/tIXN0HD8yH](https://t.co/tIXN0HD8yH)
> &mdash; Spencer 😄 (@spencerpauly) [August 17, 2022](https://twitter.com/spencerpauly/status/1559940420033024000?ref_src=twsrc%5Etfw)

**React-Hook-Form – 4⭐** – Honestly, RHF is perfect but I spend a lot of time managing forms. It makes me wonder, is there a better solution?

**Apollo Client – 4⭐**– Again, perfect for what it is. But, still data fetching + updating is very manual and I bet it can be automated.

**Graphql Code Generator – 4⭐** – Solid, but debugging is a pain and I'd like to see this functionality integrated directly into Next.js.

**Unstated-Next – 5⭐** – This is my state management solution. It's essentially just React Context with a cleaner API. I still love it!

**Luxon – 3⭐** – Switched from moment.js and Luxon works well. Is it the best? Idk. Is it good enough? Absolutely.

**React-Icons – 5⭐** – Absolutely. Essential. Why limit yourself to one icon library? This is a no-brainer and my only wish is that there was **more** icon libraries added to it.

## Backend

**GraphQL – 5⭐** – A good CRUD GraphQL is basically the #1 time-saver I have when building applications. It gives type-safety from backend to frontend and makes fetching data so much easier.

**Hasura – 5⭐** – I LOVE Hasura. Still. My only gripe is that their UI is missing 20 or so quality-of-life features. But, Hasura more than makes up for it with the time savings.

**PostgreSQL – 5⭐** – I'm not very opinionated on which relational database I use, but I do love Postgres. I don't think I'll ever go back to a NoSQL database like MongoDB or Firebase. My brain things in tables. And that fits relational data.

**Serverless.com Framework – 3⭐** – Serverless is really great. And their web UI is very intuitive for getting insights on your API's health. I do wonder though if Serverless is overkill. I think a simple express server would fit my needs just as well and be easier to manage. Might make a switch in 2023.

**AWS Lambda – 3⭐** – I deploy my Serverless code to AWS Lambda. It's definitely the best of the given options, but again I think I'd just prefer an express server in a docker container.

## Infrastructure

**TurboRepo – 4⭐** – This has been a new addition at the end of 2022. I'm building something greenfield and I've been using TurboRepo to manage my monorepo. It's been great! 

I have three shared packages: `shared-modules`, `config`, and `types` and I lift data into these if I use them across multiple parts of my codebase. Then, for apps I have a `dashboard`, `api` and `hasura` app. 

With `npm run dev` it will build the packages, then build each app in the correct order including start a docker server with the database. And, like magic, everything just works. 

I'll admit, it's still buggy. If I rename the wrong directory TurboRepo will occasionally fail with 0 errors. Why? No idea. I also find it messy sometimes to see all the junk in the terminal from all my apps at once, but overall I'm optimistic it will improve.

**Docker – 5⭐** – I'd love to have everything running in docker containers in the future. It makes things feel much cleaner and gives me more confidence when the time comes to deploy my code. Dockerizing things will be an ongoing effort in 2023.

**Heroku, Vercel, DigitalOcean, Netlify – 1⭐** – Honestly, this stuff has turned into a mess for me. I don't even know where some things are hosted. Skiwise has the frontend served through Netlify, API on google cloud functions, backend on DigitalOcean, and database is ???? (I truly don't know). Engine has the frontend on Vercel, backend & database on Heroku, and APIs on AWS.

This is a mess, and it needs to change in 2023. I think this will be a big focus of my year. Instead of adding new things, I'll be focusing on minimizing my dependencies. Do I actually need serverless? No? Great, then let's toss that on a simple express server in a docker container and cut out all that proprietary code.

If I can end 2023 with everything hosted on AWS or Heroku for backend. I'll be **very** happy. At least getting everything Dockerized would be a great start.

## APIs

**Stripe – 5⭐** – I use stripe for payments for my SaaS products. Great product. Especially since the introduction of [Stripe payment links](https://stripe.com/en-nl/payments/payment-links).

**Algolia – 2⭐** – I'm not a fan of Algolia anymore. It's been running me a huge bill and I feel the idea of essentially duplicating all your data to another database just to make it "searchable" seems ancient to me. 

It's fine for large companies, but as a solo developer it's just a lot of work to maintain.

I want to find an alternative that plugs directly into Postgres and works automatically for certain fields/tables. I'd be fine with less performance, or a slower time to updating search results as a trade-off.

**Slack – 5⭐** – I love slack. I send all my user feedback, user events, error logs, notifications, etc through Slack. It's essentially the beating heart of my solo business. No plans to replace this anytime soon.

<Image src='/content/images/2023/01/slack-01.png' alt='' />

**Airtable – 5⭐** – I currently use Airtable as the database essentially for [NotionIntegrations](https://notionintegrations.com). And I use Airtable Forms + manual approval to add new items to the database. This is huge! And has huge potential for the future. In fact, if they could just figure out how to add Typescript types I'd use it for every single MVP.

## Developer Experience

**VSCode – 5⭐** – Absolutely essential. Love it.

**Trello – 5⭐** – My productivity is directly correlated with higher trello usage. Full stop. And I haven't seen a cleaner UI that does what Trello does so I'm sticking with it.

**Notion – 2⭐** – I lost my love for Notion in 2022. The reason being? It's just so slow. It's so slow! It's so slow that I actively avoid hunting around multiple pages to find content. Not to mention the search is very poor as-well. This means I just toss everything in a single `Scratchpad` document. However, this negates the value that Notion provides.

Also, because Notion is so slow I don't even bother using it for notes on my phone. Instead, I use Bear and then lose track of my notes across the 2 platforms.

In 2023, I plan to try every alternative under the sun and move off Notion completely. It's bitter sweet, but I feel like the product isn't going a direction I agree with anymore, and the competition is catching up fast.

**Macbook – 5⭐** – I run a base model 16" 2019 Macbook Pro. At $2400 MSRP it wasn't cheap, but worth every dollar for me. I plan to use this thing until it dies. Then, I'll buy another 16" Macbook. Great laptop. Plus, the screen is so big I don't need external monitors anymore. No external keyboard either. I just need my laptop, airpods, and a dream!

## Marketing

**Landing Page **➡️** Unicorn Platform – 5⭐** - I run all my sites on Unicorn Platform. I occasionally try alternatives, but always come back to Unicorn Platform since it strikes a great balance of flexiblity & ease-of-use. I don't plan to change that in 2023 until something really surprises me.

**Blogging **➡️** Ghost CMS - 5⭐** - I run both my blog sites on Ghost. It's expensive ($250/year), but it's the only writing experience I've ever truly enjoyed. Plus, I think the end results look beautiful and that's important to me. No plans to leave.

## Tech I wanna try in 2023

**Cloudflare workers –** I know I just emphasized that I wanted to lessen my dependency on proprietary technology. That being said, I really do want to play with cloudflare workers. I've seen many use-cases where these have seemed amazing at solving small widget-esque backend tasks. I think it would be something worth exploring further.

**OpenAI –** I've played with AI a bit last year. Since doing that, I'm now 100% bullish on the technology. I use chatGPT daily at this point for various things and I get 100's of business ideas a day from the things AI can do nowadays. I plan to spend a lot of time playing with this technology in 2023.

**Prisma2 –** Prisma plays essentially the same role as Hasura. Except, while Hasura is more GUI-based, Prisma is entirely through code. I like the code approach more, so I'm curious what the future holds for it. I originally wanted to use Prisma instead of Hasura, but at the time Prisma2 was missing valuable features I needed. Now, those features seem to be implemented so I plan to revisit.

**tRPC –** tRPC has me interested. I don't know much about it, but it's something I want to explore. We'll see how deeply I can explore this in 2023.

**Express –** I want to switch off serverless and go as-simple-as-possible. If there's a framework that can manage API authorization, error handling, logging, etc for me, I'm down. I think express (with enough setup) can do this, so I'm excited to try!


Tech I'm learning in 2023


I'm currently sitting in a coffee shop in Copenhagen. It's one of my last bits of travel before returning to the U.S. A victory lap in a sense.

And it feels like a victory lap.

<Image
	src='/content/images/2022/12/AF1QipMMuPD8cxhl0OJsTCyTbfa9rC3K5QkYk9dOsyeF-s1255-k-no.jpeg'
	width='md'
	alt='Victory lap moment in Copenhagen'
/>

The past 5 months have been a movie. With highs, lows, and everything in-between. It was a journey from start to finish and it never stopped being interesting.

## June 2022

My friends and I lay leisurely on the floor of my buddy's apartment in California. We're talking life, cracking jokes, and I'm thinking "hmmm... should I pull the trigger on this move to Europe"?

<Image
	src='/content/images/2022/12/IMG_1736.JPG'
	width='md'
	alt='Friends relaxing on apartment floor in California'
/>

It's something I've been considering. I don't know if the logistics will work out, but I know the timing would be good. I want to do it. But, I doubt myself. Europe is a far way from home. And there's endless decisions I can make about what to do next with my life. It could be Europe. Finding a new job. Just going all-in on my side businesses.

I had been interviewing to jobs for weeks. Even got some offers. But, they always failed the gut test.

I always left the interview thinking, "man... this just seems like another step backwards from my goals". And looking back, I think my gut was totally correct.

But, this Europe idea was different. It passed the gut test. And I knew, good or bad, it would give me a binary response. I'd either love it or hate it. And that's what I wanted. I wanted to go so far outside of my comfort zone that it'd be obvious where my comfort zone actually was.

So I booked the housing.

## August 2022

I touch down in Luxembourg. Boom. That's it. No going back now. Well, I suppose I can go back. But, at this point it's like bye-bye to $5000 if I do. So full steam ahead.

And it's a good feeling. I'm completely on my own path. The sun is shining and I'm stretching my legs before hopping on the bus from the airport. I look across the street and see a girl with a traveler's backpack on. It's filled with patches. NYC. Yellowstone. Madrid. Paris. Iceland. Rome.

For some reason that eased the tension. I'd never seen a backpacker like that in Minnesota. But they're here in Europe. And it's got me excited.

<Image
	src='/content/images/2022/12/IMG_2105.JPG'
	width='md'
	alt='European travel scene that got me excited'
/>

Now, if I could do it over again I wouldn't have started my trip in Luxembourg. As an American, it felt like everything was novel in Luxembourg. Everything from language, to their transit systems was totally different.

And for those reasons, those first two days were pretty stressful. Knowing you're on the other side of the earth from all your resources. Plus, walking around and hearing every language except English is pretty daunting.

And, the main thing I noticed from this period is how everyone looked so relaxed. People were laughing, running, arguing. It was just another day for everyone. I certainly didn't relate, but I envied that feeling.

Then, on day 3 I made a friend. It was really transformative. We'd be chatting and walking through the street and I realized I had become one of those people that I was watching the day before. I was the comfortable local.

I'd walk past areas that previously seemed crowded and chaotic, but now just felt normal. And after that moment I really never got stressed like that again. It was great.

💭

Okay, I think there's many ways to know who the locals are, but, here's my favorite.

If you're taking the metro and know which end of the station you'll be exiting on at your destination station and position yourself to be on the train car closest to that exit, you're a local.

## November 2022

This is the moment where reality hit me. Up to this point I'd been on multiple trips out of Amsterdam. Trips to London, Cologne, Brussels, northern Italy and more. Minnesota felt like a lifetime ago.

But, this was also a little over half way through my planned time in Europe. And, as much as I valued my time here, I felt like I got nothing out of it.

I was gonna return to the U.S. with no job and no money. I had many good memories, but I was still gonna be many steps behind then when I left.

Now, before I moved to Europe, I had considered all the story arcs that could take place. Maybe I'd love it and stay permanently. Maybe I'd hate it and want to leave right away.

With everything I considered, there was various good and bad outcomes. Going home jobless was not one of the good outcomes.

I'll also add, I had a lot of personal growth in this time. I knew that I genuinely wanted to get a job again. I wanted that stability and stress.

I loved working for myself, but my businesses didn't need me the entire 8 hours a day.

So I started a job hunt.

## December 2022

After what felt like million rounds of interviewing, I finally settled on a role I liked. Not only one one that I liked, but one that I was _excited_ for.

I always felt like a job that could play double-duty be teaching me skills and techniques that would be useful to my own ventures someday would be the ideal.

Issue is that those jobs are rare. And usually they're so demanding of your time from you that, while you learn a lot, you won't be able to put those skills into action.

So I accepted. And, booked my final europe trip to Copenhagen. The same trip that I'm writing this post from.

## Reflection

It's crazy. In a span of 5 months I went from stable job, to jobless, to jobless in Europe, to jobless and broke in Europe, to jobless and broke during a recession in Europe, to great new job in Europe, and now I go back to the U.S.

I feel like my life has been one of these memes. Never let 'em know your next move. And who knows what's next from here. I think I have a good idea what my next year will look like, but beyond that who knows.


Final days in Europe


SaaS dashboards, like everything in life, are a compromise. They’re a constant battle between functionality and ease-of-use. And, like most compromises, they typically do a bad job at both things.

I’ve identified these mistakes and distilled them into one great article for those looking to dramatically improve the customer metrics through their dashboard. So if you’re interested, read on…

## Mistake #1: Welcoming new users with… a blank login screen
<Image src='https://miro.medium.com/max/1400/1*dIdY2vdKQctamOLOzl7Aqg.png' alt='' width='md' />
Imagine, for a second, that your dashboard is a beautiful river that your hawaiian-shirt-wearing, pina-colota-drinking prospects are flowing down on their journey to become a customer.

As the prospect is sipping their drink and loving life, there will inevitably be a moment where they first experience friction.

For many apps, this moment is when they need to sign up and create an account. This moment of friction is essentially like telling your customer they need to portage over 100 yards of forest and hop back into the river on the other side.

**Aka: It’s painful.**

The problem, however, isn’t just in the act of authentication itself. It’s in the position we place this in the user flow. Greeting new users with a login screen might be essential, but can we give the user a taste of the value proposition before we make them sign in?

There’s many ways to fix this. The simplest would be embedding your sign-in form within the page. This allows the user to see the navigation and get a good feel for what they’re signing into.

## Good
<Image src='https://miro.medium.com/max/1400/1*dIdY2vdKQctamOLOzl7Aqg.png' alt='' width='md' />
## Better
<Image src='https://miro.medium.com/max/1400/1*r_MjVQJyLdSFJIaPW9Sa6Q.png' alt='' width='md' />
But can we do even better? With this solution, the visible left navigation gives us a sense of direction. But, since the background behind the auth popup is blank it feels like opening a door to walk into an empty room.

Let’s make this more effective. This time, we’ll give the users a sneak peek of what’s behind the door before they enter.

You can create this effect by adding a combination of blur + partially-opaque black overlay to a “skeleton” version of your dashboard page. The result should look something like this:

## Best
<Image src='https://miro.medium.com/max/1400/1*KDS9rtw305rGJUNe4ZzHVQ.png' alt='' width='md' />
This is great because it emphasizes that the solution is right in front of them. They just need to log in and access it. Plus, this gives the user a couple seconds to familiarize themselves with your dashboard layout before interacting with it — making it less daunting.

## Mistake #2: Building out complicated onboarding “walkthroughs”
<Image src='https://miro.medium.com/max/1400/1*Ssw_eb1Krgm6KR7zeFCATA.png' alt='' width='md' />
But, wait? Don’t onboarding walkthroughs help conversions?

The answer is: Yes. But, not the way most people do them.

See, most businesses make the same mistake here as they do with authentication. They tend to put the cart before the horse.

These walkthroughs, while helpful, do very little to guide a user because the user doesn’t have the context yet to fully benefit from them. It’s like teaching a 5th grader calculus.

You’ll know you have this problem when you see that a large percentage of your users are opting to skip the walkthrough.

To fix this, trim down your complicated walkthrough experience. Break it into smaller chunks that can be given piecewise. As they dive deeper, they unlock more walkthroughs similar to a video game.

Another tip: display your onboarding walkthroughs after a short delay. Only 5 seconds or so. This way the user gets a chance to see, feel, and interact with the page before being shown the happy path.

For another great solution, look at a company like Retool. Retool created a dedicated “Learn” tab for customers to seek out tutorials as they need them.
<Image src='https://miro.medium.com/max/1400/1*pMF27WkINh5ZvMc7fr6TIg.png' alt='' width='md' />
The “Learn” tab means walkthrough content is always accessible in the future. Plus, for a more complicated product (such as Retool’s), it offers great expandability as new features are implemented.

## Mistake #3: Having “promo codes” in the checkout experience
<Image src='https://miro.medium.com/max/1400/1*fifo3QBgtByLcNxVsY3axw.png' alt='' width='md' />
This is another common, but sometimes costly, mistake. Think about it, you’ve been using an app for a while and you’re finally ready to move to a pain plan.

You’ve accepted the price

you’ve gone to the checkout page

You’ve entered your credit card

…and you see a text field for “Promo Code”. What’s the first action you’re going to take?

> You’re going to navigate away from the checkout window and search google for **“AppName Promo Code”**!

Now, why would you want to push your bottom-of-funnel back to google? There’s a risk here that your competitors could buy out this keyword and target your customers to bring them to their solution instead.

Or, it could just lead to the prospect delaying their purchase because now they’re not too sure if they’re getting a good deal. Finally, your best customers aren’t going to care about a discount code anyways. 10% or 20% off won’t matter to them, so don’t even present it as an option.

Here’s a better alternative to promo code fields: remove them entirely. Instead, keep the functionality by generating custom checkout links with the promo-code pre-applied. Then, share those links instead of the code. This way, you can use these links for affiliates, or discounts, but not confuse your “normal path” customers.

## Mistake #4: Allowing customization too early
<Image src='https://miro.medium.com/max/1400/1*ACVI-35U7Qf-xR-a9rdJkw.png' alt='' width='md' />
Ultimately, customization is the goal of any SaaS dashboard. Think about it, if your SaaS didn’t need customization it wouldn’t be a SaaS. It would just be a service.

Therefore, it’s important that you balance too-few-features with too-many-customizations. Customization might be great for your current customers. They know your tool already and extra features won’t be distracting. But, for new customer it raises the knowledge barrier to entry.

One easy solution: Create a clear onboarding flow that only introduces the essential features. Then, have the full dashboard experience with all the customization available later.

## Mistake #5: Not supplementing your dashboard with smart behavioral email
<Image src='https://miro.medium.com/max/1400/1*yd6J5exVO2JhMkjTUG0MQg.png' alt='' width='md' />
How long will your new trial spend on your dashboard on their first visit? A minute? 5 minutes? 20 minutes? No matter how long they spend, they’ll always navigate away.

That’s why behavioral email is so important. Behavioral email is a type of automated email sent in response to an action (or lack of action) by a user. This can be used to incite the user to continue to the next step in their onboarding flow.

With smart behavioral email, you can create an email flow that tracks where the user is in their “Minimum Path to Awesome” process, and gives them guidance on moving to the next step.

Has someone just created an account but not done anything?

> **Send them an email reinforcing the pain point your product solves and inviting them to run a simple test to see if the tool works for them.**

Has someone created an account and tried a couple simple tests, but not fully committed?

> **Send them an email inviting them to a 1-on-1 call to discuss their specific use-case. Also show off how others are using your tool to benefit their businesses.**

Has someone used your tool to solve their problem, but hasn’t upgraded to a paid plan yet?

> **Send them an email reiterating the value they’ve already gotten from your tool. Then, invite them to upgrade to the paid tier and focus on the extra value that can be provided at that level.**

Why is behavioral email so valuable? Because it’s smart.

It essentially answers the user’s questions before they even ask it, because you can track events to figure out exactly where a user got stuck while using your tool.

There’s many great ways to implement this with [Drip](https://drip.com/), [UserList](https://userlist.com/) or other tools. Alternatively, you can implement your own. This is a feature we’ve built with great success at [Pwego](https://pwego.com/).

## Mistake #6: Failing to create a comfortable “home” in the dashboard
<Image src='https://miro.medium.com/max/1400/1*c3YLdBF7_u8Q3_U1EFZIJw.jpeg' alt='' width='md' />
You have to remember that every page of your dashboard has a specific “weight” to it. We **feel** this weight as humans, even though it’s a bit hard to quantify.

These weights exist in real world spaces too. If you arrive in your house, the kitchen, living room, spare closet, and bedroom will all have different weights to them.

This should be taken into account when building your dashboard. A common issue businesses fall into, is treating all pages as-if they have the same weight. This isn’t intuitive to a user, because it creates decision fatigue whenever they want to find something.

Imagine you see the following pages in a dashboard:

1. “Forms”
2. “Analytics”
3. “Users”
4. “Automations”

Does it seem like there is a clear “home”?

Ideally, the goal would be to have a clear “home” page that has a definitively stronger weight to it in the user’s eyes. You can do this by adding a tab named “Home”, “Dashboard” or “Create” and emphasizing it as the homepage. This makes it a very clear entry-point and helps users find the most important things quickly.

## Mistake #7: Not watching your customers use your app!
<Image src='https://miro.medium.com/max/1400/1*nepBW0eC1YXINeWtntR2Ig.jpeg' alt='' width='md' />
Ultimately, this is the most important mistake on this list. All the other common mistakes were found from one thing:** watching customers onboard**.

A great way to do this is set-up onboarding calls with new users where you simply watch them as they sign-up and note where they get confused. You’ll find many things that you once thought were intuitive actually aren’t.

One time, I found that a user couldn’t figure out what to do because they needed to scroll down to submit the sign-up flow and create an account. That was intuitive to me, but not to all customers.

Setting up onboarding calls is great, but another alternative you can try is something like [Microsoft Clarity](https://clarity.microsoft.com/) or [Hotjar](https://www.hotjar.com/). These tools anonymize and record the screens of users as they interact with your dashboard. Think of it as beefed-up google analytics. Plus, they’re completely free. So worth the try.


7 Common SaaS Dashboard Mistakes — How to Fix


Exactly one month ago, I quit my job, sold my things, and booked a flight to Europe. The destination? My dream city of Amsterdam.

This was motivated by many things, but ultimately it came down to three main factors: freedom of location, freedom of time, and freedom from things.

I wanted the ability to live in my human-centric dream city, to spend my time working on my own passions, and to do this while I still had the flexibility in my life to make this change.

And, I must say, in just one short month, this experience has already fundamentally changed who I am.

No, seriously. I'm not kidding. And this isn't just some whimsical rom-com about "finding myself in Paris". It's real.

A month ago, If you had asked me "Spencer, what's your goal in life", the answer would've been simple: Freedom. My goal was to have the freedom to spend 100% of my day creating things I'm passionate about. And to have have freedoms in other areas of my life as-well.

**Freedom of location –** to not be tied down to one city in this world, but be able to live and work wherever I feel like it. 

**Freedom of time –** I wanted the freedom to spend my time as I chose. To be able to decide "I want to work on X today" and do exactly that. To work on my own businesses with my time rather than working for others.

**Freedom from "things" –**I wanted freedom from things things that "own" me. For example a house, or a car payment, or a fancy piece of furniture. All these things you must maintain, make payments towards, and give up other freedoms (ex. freedom of location) to attain.

And, just as any core belief, this fed a lot into my decision making. For example, when I started my first job out of school I didn't join the company health insurance plan. I stayed on my parent's plan. I did this so I'd have the freedom to leave my job and retain health insurance.

Another example, I didn't buy any nice furniture when I moved into my first apartment. I bought everything used. This was done with the intention that I could sell everything at the drop of a hat if I wanted to.

Additionally, I've never been in favor of owning a house. I felt like this would tie me down to one location and add a hefty monthly subscription to my life that limited my future choices. I wanted the ability to be flexible with where and how I live in the future.

These are just some examples, but I could list more. The takeaway, however, is this: a lot of my goals revolved around flexibility and freedom. And after Europe? It's quite the contrary. 

## So, how did Europe change this core belief?

Okay, so I think the question that must be asked first is this: 

> Why would someone want freedom? In general?

And hey, I know freedom is a popular desire cause 'Merica was literally built on the concept. The freedom of speech, freedom of religion, freedom of assembly. You wouldn't get people dropping everything, hopping on boats, and sailing to unknown lands unless these freedoms were important to them.

And freedoms at a society-wide level make sense. It's the freedom for each individual to make their own decisions. But, what do these same freedoms mean on a personal level? 

The freedom of location is nice on a society level. Let people move where they'd like to within their country. But, on a personal level is this same freedom still valuable to you? Do you want to move around?

Personally, I didn't know if these freedoms were valuable to me. That's why I sought the freedom of location so badly. Because at the end of the day, personal freedoms are simply the freedom to defer making a choice.

But as a goal, freedom is a bit useless. That's because freedom itself isn't really a goal, it's more of a meta-goal. It's the ability to change goals at any time in the future.

And I learned that pretty quickly when I landed in Europe. 

I learned that the goal of being able to work at any location is great. But, it's only valuable if you genuinely want to travel everywhere. Not just, "I want to *be able* to travel everywhere", but "*I want to travel everywhere*". 

You see the difference? Wanting the freedom to be able to make a decision isn't a goal. It's simply the act of not knowing the goal yet, but not wanting to shut any doors.

So, I reflect on my situation here in Europe. I have the most freedom I've ever had. I have the freedom of location. I can go anywhere in Europe or the US. I have the freedom of time. I don't work a 9-5 job anymore, so my day is mine to construct. I have the freedom from things. I live out of a backpack, so the ability to go anywhere isn't really limited by what I own. I even have the freedom of money, since I can ramp up and down freelancing at my leisure.

However, through receiving this "full freedom", I realized something. There's quite a few of these freedoms that I don't really care for.

You see, people are different. One person might want the freedom to travel and that's all they care about. Another might want want to earn more money and is willing to give up some time to do that. And, another might want want time freedom above all else and is willing to give up money and other benefits to have that.

It's actually kind of interesting when you think about it that way. Each person can brew their own stew of freedoms that they value.

I've met many people abroad. I've met girls who work at a coffee shop 9 months a year primarily to save enough to spend the summer traveling. I've met programmers who work in the mornings as a digital nomad. And I've met people who quit their job in a similar manor to me, simply to travel and live abroad.

And everyone is optimizing towards their own preferences. It's pretty amazing!

## What I learned 4,000 miles from home

With that in mind, gaining all these freedoms has truly made me realize which ones I value. I thought I'd value them all, but you always have to give up something. And I feel I understand myself better now.

### Freedom of Location

Firstly, the freedom of location. So far I've traveled to Luxembourg, Germany, Belgium, and the Netherlands. I have plans to visit the U.K, Italy, Spain, Portugal, Switzerland, France, Greece, etc. I truly have freedom of location.

The problem is, I like to travel but I don't want to do it full-time. In fact, I'd argue most people, even those who love to travel, would agree with me on this point.

Luckily, I knew this about myself so I planned this with a home base in Amsterdam. But the question remains, is this "location independence" truly a freedom that is important to me?

Honestly... no.

I'm think this deserves a separate article, but the summary is this: Amsterdam is my dream city. It truly is. However I'd compare that statement to be akin to someone saying "the U.S. is my dream country". It's a valid statement, but there's so much variability in the quality-of-life across the U.S. And likewise there's so many differences in the quality-of-life across different parts of Amsterdam. So while Amsterdam is my dream city, what I'm really looking for is my dream *neighborhood.*

And I can honestly say that my dream neighborhood is Uptown, Minneapolis. Uptown is essentially the Brooklyn of Minneapolis. Trendy, young, extremely walkable, popular neighborhood.

<Image src='/content/images/2022/09/Screen-Shot-2022-09-07-at-6.12.07-PM.png' alt='' />

And Uptown truly has it all. My favorite takeout restaurants, five amazing grocery stores, barber shops, great restaurants, nice bars, multiple gyms, a dedicated bike freeway, the chain of lakes – all within a short 10 minute walk. 

<Image src='/content/images/2022/12/green2-1.jpeg' alt='' />

Contrast this to the area I live in Amsterdam. There's still close grocery stores, and excellent biking, and many takeout restaurants. But I like everything just a little bit less. The grocery stores aren't quite as nice, takeout places aren't quite as tasty, and bike trails aren't quite as leisurely etc.

And, while one of my major gripes with Minneapolis is the car dependency, it kind of didn't matter when I lived in Uptown. I worked remote and exclusively used my car when visiting friends or going to the gym. My neighborhood was walkable, so my "city" and lifestyle was walkable. So, although Amsterdam as a city absolutely dominates Minneapolis on almost every metric I care about – bike, rail, and pedestrian infrastructure – it almost doesn't matter. The neighborhood is what matters.

Now sure, I've only been in Amsterdam for a little bit, and there's many neighborhoods I've yet to explore. There's no doubt I'd find my 10/10 slice of Amsterdam. But, the question is: if Uptown as a neighborhood already scores a 10/10, would I rather choose the 10/10 neighborhood near to my family and friends or the one that's 4,000 miles away?

### Freedom of time

Secondly, let's talk about freedom of time. And, this realm has seen some huge changes for me. To start, my bootstrapped businesses are *still* my central focus in life. And, before Europe if you asked me "why" I build them, my answer would include a lot, but would likely focus around freedom. 

Building these sustainable cash-machines would give me the freedom to spend more of my time building these sustainable cash machines. An infinite loop essentially. They'd also give me the freedom to earn an income entirely dependent on my abilities. The freedom to work wherever and whenever I wanted. And, the freedom to build with the technology that I actually want to use.

And, if you asked me if I ever want to work a day job my answer would be "hell no" primarily because it directly contradicts against those goals. Fixed tasks, fixed pay, fixed times, fixed location, and fixed technology.

However, now if you asked me if I ever want to work a day job again my answer would be...

> "actually... yeah" 

How could my answer to this question ever be "yes"? Am I really giving up on my self-funded business aspirations and choosing to work as an employee?

And, while on the surface that might be what it looks like, it's actually quite the opposite. You see, previously I saw my day job fought in direct opposition to my startup. It was the thing taking all the time, energy, and focus away from my passion. And, limiting me from getting the freedom I wanted so badly.

But I've had a shift in perspective on this. You see, when the goal of my startup is to make enough money such that I can live with the freedoms that I desire, it's easy to understand why I'd be mad at the day job. Not only does the day job not have the freedoms I desire, but it also makes it harder to build the startup to create the freedoms I desire.

But, take away the desire for freedom. What is the goal of building the startup now? Well, actually it's very clear – the goal is to build it because that's what I want to do. It's not really more sophisticated than that. The goal isn't to use the startup as some sort of fat piggy bank to fund my lifestyle, it's simply to build it **because**I want to build it**.

And this is why I feel more driven and passionate about creating things now. It's because I'm not trying to build the startup to "free" myself. I'm just building it because that's what I love. So, if I can get a career that allows me the 2-3 hours a day around it to build my startup, I'd be happy. I don't need to be living full-time off the income from my business to be "successful" – I just need the time and energy to spend some of my day working on it.

And inevitably, with consistent effort over time it will reach financial success. I'm 100% confident in that. But, I no longer want to feel like a failure while I haven't reached that point.

I hope that makes sense.

## So, what will this change?

Well, I'm glad I made this leap to learn these things about myself. I've learned the select 2 or 3 things that I truly value. I value having a couple hours a day to build and grow my businesses. I value living near friends. I value living near family. I value having my home gym. I value walkability, but don't need the entire city to be walkable. I value nice coffee. And, I value my weekly volleyball games.

Additionally, I value making a steady income. Not because some outside force is pressuring me to, but because if I can do that while simultaneously getting my 2-3 hours to work each day, then that's a win-win!

So, I'll return to the U.S. in 3 months. When I do, here's my plan:

1. Move back to Uptown – After living in my "dream city" I've realized I really had almost everything already at my finger tips. And it was hard to realize that until I moved away.
2. Get a new job – Being independent is nice, but I don't require 14+ hours a day to work on my startup right now. And someday I will, but in the meantime if I can just have a block of time to work from 7am-10am, I'll be happy :).
3. Get back in my home gym. I miss that place :).
4. Get back to my espresso machine. I miss my coffee more than I'd like to admit.
5. Travel more! I don't need complete location independence, but I still love traveling. However, three 10-day trips a year is my ideal amount.

<Image src='/content/images/2022/09/Screen-Shot-2022-09-08-at-11.11.27-AM.png' caption='View of Minneapolis from Uptown' alt='' />


My first month in Europe


As a developer, I think two of the most challenging things in software are (a) naming things and (b) figuring out best practices. Both of these things have many ways of accomplishing the same goal, so it's hard to know which way is recommended. 

That's why I decided to make this cheat-sheet. It's a set of best practices for naming things in React. Double whammy!



*✌️ Note:* Does your application already have patterns you enjoy? Great! That's the end goal of this article! If you're not satisfied, however, read on.

## 🚀 How to name anything in React

Components deal with two types of data: **props** and **state**. **Props** get passed into a component from the function parameters and **state** gets created within the component's runtime.

Both props and state can contain two types of data. They can contain **events** and **values**. An easy way to distinguish between these two is that **events = functions** and **values = variables**. Take this component for example:

```jsx
function Book({ title, description, author, onOpen, onClose }) { ... }
```

Can you identify which props are values and which are events?

`title`, `description`, and `author` are **values.**

`onOpen`, and `onClose` are **events.**



🚀 Pro tip: **values** always flow *down* the React DOM tree, and **events** always bubble *up* the tree.

## Best practices for naming "data"

Now that you understand the different between data and events, let's talk about naming conventions.

Here's the general advice:

**Boolean values** should include a prefix like `is`, `has`, `can`, etc.
- ✅ `isVisible`, `hasWatermark`, `canBeProtected`

**String values** can use descriptive names without special prefixes.
- ✅ `title`, `description`, `username`

**Number values** can use descriptive names without special prefixes.
- ✅ `age`, `contentSize`, `totalCount`

**Array values** should be plural to indicate they contain multiple items.
- ✅ `books`, `items`, `activeLocations`

## Best practices for naming "events"

Events have more specific best practices for their naming conventions. That's because you want them to be differentiated from data. Here's the 4 golden rules when naming events:

### 1. Use a prefix to indicate action

Here's an example search component:

```tsx
function searchbar({ search }) { ... }
```

Now answer this question: Is this search prop an event or is it data? 

If it was an event, it would be called like `search('search term')` to get a result. If it is data, it would be the search term itself (ex. `console.log(search) // 'search term'`). I'd argue, because of how we named this parameter, it's not clear whether it's an event or data.

Therefore, you should always use a prefix for events. Example: `onSearch`, `handleSearch`, `triggerSearch`, `executeSearch` etc.

✌️ Note: This rule can be broken. Sometimes it's more intuitive to simply call the prop `search`. It takes a judgement call sometimes.

### 2. Follow React's patterns

HTML has good practices built in. Try to follow them when you can. For example, HTML has events for things such as `onclick`, `onchange`, `onselect` , [etc](https://www.w3schools.com/tags/ref_eventattributes.asp). React renames these to `onClick`, `onChange`, `onSelect`.

Try to follow these as-well. If you want an event to trigger when your component is clicked, don't name it `triggerClickEvent` or `onClicked` or `onSelected`. Just name it either `onClick` to match react, or if it needs more specifics you can name add a specifier like `onItemClick`, `onBookClick`, `onProfileClick`.

### 3. Use present tense

Notice how none of HTML/react's event naming is past-tense? That's the correct way to do things. The event is happening in the present, so it should be named like that.

❌ `onItemSelected` => ✅ `onItemSelect`

❌ `onInputChanged` => ✅ `onInputChange`

❌ `onResponseTriggered` => ✅ `onResponseTrigger`

### 4. Use PascalCase

This is already common in the JavaScript ecosystem, but I thought I'd mention it anyways.

❌ `oninputchange` => ✅ `onInputChange`

---

## 🔥Bonus 🔥: Naming custom hooks

Here's how to properly name the custom hook, and how to format the response data.

### Naming the custom hook

Once again, here's the general rules:

1. Start with `use`
2. Use present tense
3. Use pascalCase

✅ `useQueryLookup`

✅ `useColorPicker`

### Naming the return value of a custom hook

Generally hooks can either return data as a single value, an array, or an object. Here's when to use all three:

**Single value format**

🔥 `const user = useAuth()`

A single value should be used when the user is only ever going to read 1 piece of data out of the hook. Typically, this is used for hooks that get their data initially from a `useEffect(() => \{ ... \}, [])` call. Or hooks where the data is passed in through a context provider.

**Array value format**

🔥 `const [books, setBooks] = useLibrary();`

Lots of react's default hooks use this array response format. This is great for hooks where the response is essentially in [`data`, `event`] format. If you need more events consider using object format.

**Object value format**

🔥 `const { isOpen, onToggle, onOpen, onClose } = useModal();`

Lots of custom hooks use the object format. It lets you have a larger API surface and then the consumer of the hook doesn't need to bring in every field if they don't want to.

---

## 🔥Bonus (round 2) 🔥: Naming Form Components

Form components get a specific mention because they're another area where people commonly make mistakes. Again, this is open to interpretation so if your app has a different design pattern, that's okay! This is simply the naming convention I've seen work best, so it's what I recommend.

Firstly, what's a form component? It's the kind of component that would be used in a form in your app. Here's some great examples from popular UI libraries:

**Material UI – `<Select />`**

```jsx
<Select
    id="demo-simple-select"
    label="Age"
    value={age}
    onChange={handleChange}
>
    ...
</Select>
```

**Chakra UI – `<Input />`**

```jsx
<Input value={value} onChange={handleChange} />
```

**Ant UI – `<Switch />`**

```tsx
<Switch checked={isChecked} onChange={onChange} />
```

As you can see, they all have slightly different API's, but they do have one thing in common:

> They follow the naming convention of the component they're emulating. 

That's my tip for those creating form components. If a component is going to emulate a text input component, make the controlling props be `onChange` and `value`. If it's going to emulate a checkbox (ex. anything that is true/false and can be flipped), give it a `checked` and `onChange` prop.

Want the full list?[ Click here for a list of the built-in HTML form components](https://www.w3schools.com/html/html_form_elements.asp). Try to emulate their API features if you make a similar component as then it will be intuitive for your component consumers.


Best practices for naming hooks & props in React


This week has been extremely stressful for me. I made a tweet last week about moving:

<Tweet 
	author="Spencer"
	handle="spencerpauly" 
	date="July 24, 2022"
	url="https://twitter.com/spencerpauly/status/1551324602764337153?ref_src=twsrc%5Etfw"
>
	Unpopular opinion: I like the process of moving. 
	
	It's like the real-life version of code refactoring and I like the simplification I get after doing it.
</Tweet>

And... spoiler alert: *I no longer like moving.*

The move alone wasn't the issue. But, little did I know it would be the first of numerous stressors this week.And that's how things work sometimes. You'll have a productive, focused, stress-free week swiftly followed by a week of pure chaos and anarchy.

So, guess where I got the idea for this blog post?

## Stress

Stress. Every founder faces it. And it's a difficult thing to pin down. It can come out of nowhere. It can slowly brew on the horizon. It can be both at once. But, I do believe it can be managed. 

It's like everything else founders face. The first time you face it, it's very scary, it makes you want to quit, but you tackle it and learn from it. The next time, you take a second, create a plan, and start moving towards that plan. Suddenly, it's not so scary.

But, this week the stress was very much unexpected. This is what my most stressful day felt like:

> **beep! beep! beep!**
> 
> It's 6am. The alarm clock is blaring.
> 
> **beep! beep! beep!**
> 
> You're jolted awake.
> 
> **beep! beep! beep!**
> 
> You run across the room.
> 
> **beep! beep! beep!**
> 
> You swiftly hit "stop".
> 
> ...waiting...
> 
> ...waiting..
> 
> peace :)
> 
> But stress doesn't go away that easily. Stress doesn't simply turn off. Stress can only be snoozed. 
> 
> And so you continue your day. And just when you're least expecting it...
> 
> **beep! beep! beep!**
> 
> The cycle continues.

Since my week felt like this, I decided to write down things I thought might help. I grabbed some ideas from the internet, and some from my own head. Then, I tried them. Cause why not?

This is my review:

### ❤️ Breathing

This was recommended everywhere. It didn't work for me. I'm not sure why it didn't work. I'm also not sure why it would've worked. But worth a try as it only takes a couple minutes.

### 💛 Going on a walk

This is my typical stress-reduction method. Sometimes it works, sometimes it doesn't. When it doesn't work, I've found it's because it creates too much space for me to overthink. This week, it didn't work.

### 💚 Working out

I didn't work out for a week. Partly because I was already doing a lot of driving while moving. And partly because I didn't have my normal habits in place to trigger me to workout. Usually, I try to be consistent about doing my training. I can't tell if the stress caused me to stop working out or if me stopping my workouts caused the stress. Either way, I forced myself to go this week. And it worked!

### 💚 Giving up control

A lot of my stress this week was actually out of my control. In [a previous article](/blog/connections-for-bootstrappers/), I wrote about one benefit of being a bootstrapper. It's the fact that so much of the process can be in your control. I also wrote about how that can be a negative. This week, it was a negative. I wasn't experienced enough at giving up control.

So, I wrote down the things that were stressing me out. Then, I wrote down the actions I could take. Then, I did those actions. Finally, I checked the list and saw there were no more actions I could take. Once I knew that, and had written proof, I went down multiple stress levels. I absolutely recommend that others try doing the same.

### 💚 Seeing friends

Sometimes pure distraction can be a solution as-well. Especially if the stress is outside of your control. What's a good source of distraction? friends.

🚀 Note: I also tried non-social distractions. They didn't work. Partly because afterwards I'd not only feel stressed, but also unproductive. 0/10.

### 💚 Simply... waiting

In my scenario, simply giving it time turned out to help. I tried to think up endless "what-ifs" and "disaster-scenario solutions", but I realized I need to take a step back first. 

If it's out of my control, I shouldn't spend my time thinking 3 steps ahead. It's like chess. Any number of moves might be played. But, it's not my turn. And, although it's useful to think even when it's not your turn, it's not useful to overthink. It's better to save your mental energy. Let the other person play their move, and then craft a response.

### 💚 Writing

Oddly enough, I drafted this blog post during that stressful day. It gave me a canvas to think onto and a distraction that yielded productivity. I'd recommend it!

## Got other tips?

So that's it. These are the  is what helped me this week. Got things that you do when you're stressed? [Tweet me](https://twitter.com/spencerpauly). As always I'll keep the article updated with evergreen tips from others.


Some tips for founders to destress


There's a lot of great advice online to build better software businesses. The common wisdom includes "start *marketing before you start building*", "*build in public*", "*validate your business idea*", and more. And don't get me wrong, this is great advice!

But, I'm going to argue these tips aren't beneficial unless you're already in the habit of shipping product. They're optimizations to a process that you need to have a firm handle on already.

But how do you get started shipping products?

The key is to build the habit. Your brain acts like a muscle and it tends to gravitate towards doing the same things you're currently doing. So if you want to build the habit of shipping, you need to change things up.

Here is a strategy I use to break out of a productivity slump. It’s just one tool among many that I use to build back the habit of shipping software. Got your own tips as-well? I would love to hear them! [Share them with me on twitter](https://twitter.com/SpencerPauly).

> My Solution: Do a 1-day super hackathon

Let me preface by saying this – this is not your typical hackathon. Typically, a hackathon simply involves spending a day programming to create something new. This hackathon will do that too, but it’ll go one step further. During this hackathon you’ll also get into the habit of going from idea to MVP quickly, building in public, limiting scope, and actually launching product.

I belive these skills combined are more valuable for bootstrappers than simply coding.

## The secret sauce: What should you build?

Figuring out what to build can be difficult. For this 1-day super hackathon, I provide a simple solution: Build a free tool in your niche.

Building free tools is a extremely powerful. They can create early traction and idea validation which will serve you effectively for future paid offerings. They're also quick to build and launch. Plus, if you already have a paid tool that you're running, it can be a great engineering-as-marketing activity to bring in more traction.

As bootstrappers, I think we naturally gravitate towards writing code. Yet, sometimes it's easy to get into analysis-paralysis where you lose the habit of programming every day. Between all the activities an entrepreneur has to do, this is understandable. But here's where the benefits of building a free tool really shine through.

**Free tools can be killer for SEO and lead generation.**

Take a look at [Maybe](https://maybe.co/), they have an entire "tools" tab on their landing page with free tools. Same with [hubspot](https://www.hubspot.com/resources/tool). And, [ahrefs](https://ahrefs.com/free-seo-tools). Some of these businesses are built entirely around creating value with their free tools. Plus, tools rank well in google. It's like writing a blog post, but you get to write code instead!

**2. Free tools are a great way to validate a business idea.**

I've found it's hard to get people on a call to validate a business idea. But, there's a secret sauce to getting let in the door. Validate yourself to them first, and they'll help you validate your business. If you build a free tool for accountants, you instantly have much more credibility when you reach out.

> "Hi, I'm Bob and I make tools for accountants (such as this one). I know you're an expert in the field, so I'm reaching out to see if you could provide some insights into day-to-day problems so it could guide future tools."

**3. Free tools are *quick* to build.**

Free tools shouldn't need auth, or a database (beyond [airtable](https://airtable.com/)), or a monorepo, etc. If you're an experienced developer, it's easy to launch these tools quickly. If you're still learning, even better! Building and launching free tools is a phenominal way to walk yourself into the world of launching software.

**4. Free tools can be "launched"**

This is the ultimate hack to building free tools. They can be launched on ProductHunt, IndieHackers, twitter, etc. And if they provide value, it's a great way to get early traction. Compared to launching a paid product, people won't be as critical of a free tool. And if it provides value, you'll start building a loyal audience.

Let me provide an example. I run a paid addon tool for Notion called Engine.so. But, before I built it, I built a free site called [notionintegrations.com](https://notionintegrations.com/). This site now ranks #3 for the keyword "Notion integrations" and gives traction that I can direct towards Engine if I want to. Also, an early version of the site featured a search bar. I used this to collect data and discover what integrations users wanted to see.

This was key because it let me get a head start on marketing before I ever started coding Engine. It was also a tool I could show to consultants in the space and say “Hey, am I missing any tools on here? Is there other integrations your clients have been requesting”?

## How to effectively execute your hackathon

Now that you know what you're planning to build, it's time to learn how to execute this hackathon effectively. The key separating your hackathon from a traditonal hackathon is that you don't want to be working in a vacuum.

It might feel weird, but it's important to get in the habit of **sharing** your products, not just building them. Here's how I recommend you do this.

### Pre-hackathon

Before you start, draft an [Indiehackers](https://indiehackers.com/) post sharing your hackathon plans. Invite others to offer suggestions for what they'd like to see. And share that you'll be offering a play-by-play of the progress on your twitter.

Additionally, and this is very important, get a landing page up for your tool!

Start marketing it. This should be your concrete goal: "Before I start building I want to get a link to this landing page existing in at least 10 places on the internet".

 Use easy channels such as reddit, facebook groups, indiehackers, hacker news, relevant forums, blog posts, your personal site, etc. Since your tool isn't released yet, you can share something like this:

> I'm in the final stages of building a 100% free tool for users to accomplish **x**. It will be released in the coming days! I'm giving out early access so if you're interested fill out the form here (link).

Then, your link should simply point to where the tool will exist in the future. This will start generating backlinks. Since it's not built yet, just put a quick form or email capture at that link. This will be really helpful for (1) early traffic, (2) a launch list and (3) relevant feedback.

### During the hackathon

During the hackathon, it's important not to pick your foot off the gas pedal of marketing. Do the following:

1. make a tweet every hour sharing an update. This doesn't always need to be an "acheivement", in fact it's better if it isn't. Stuck on centering a div for 2 hours? Share that. Found a neat little bug that you haven't seen before? Share that too.
2. Go back to those relevant links you made before starting. Did any communities resonate well? Share updates in those communities.

Finally, get to coding! Make sure you set a fixed time limit, but I wouldn't go anything longer than 3 days. The time limit should be short to force you to cut corners and not get too deep into thought. Learning that skill is essential for entrepreneurs as you won't always be able to do things the correct way all the time.

### How to finish your Hackathon

As your final day is winding to a close and your tool is almost ready to publish, pat yourself on the back. Congrats! You’re getting yourself into the habit of shipping. Here's what you do next.

First, get your code out into the world. Put it on a personal website, a github repo, or a Vercel instance and get your tool interactable. Does it look ugly? Feel clunky? That's good. In fact, that’s ideal. Because, you'll probably want to come back tomorrow and polish it up, right? Congrats, you’re getting into the habit of shipping product.

Finally, the next day I encourage you to write a recap of your experience. Make a blog post describing the process and what you learned. Also, share the tool in relevant communities. Share a 2 sentence story about the build process and invite feedback to help you iterate on it more.

As a bonus: You can even execute a ProductHunt launch with your new tool. This could be a whole separate blog post in itself, but it's something worth considering if you think people will draw value from it.

Thanks for reading!

---

On another note, welcome to week 3 of [my bootstrapper articles]({GHOST_URL}/). I’ve been writing these from a neighborhood in Minneapolis called Uptown. It’s the most beautiful place I’ve ever lived. Labelled as the “20-somethings” area of Minneapolis, it boasts the best walkability I’ve ever experienced. I’m gonna miss walking to get food in the morning, riding my bike around the lakes after work, and creating swarms of electric scooters with my friends.

That said, I’ve had multiple doors close in my life: leaving high school, moving to college, leaving college. But, this one feels different. This one is a door that can reopen again. In the first quarter of life you’re “on rails” and can only really experience things once. But, now that’s not the case. I can always move back to Uptown. I can always get the lifestyle back that I enjoy so much. And that’s cool!


Regaining productivity as a bootstrapper


🚀 Product update: 2 new [engine](https://engine.so) customers this week 🚀😄! yay! 

I'm very independent. And I'd argue that if you're building a bootstrapped software business you probably are as-well.  

How do I know that?

Well, think about it! You have no funding, no team, and (likely) no co-founder either. If you need a logo designed, you design it. If you need a landing page built, you build it. And If you need a blog post written, you write it. And, compared to our funded counterparts, money can't do the work for you.

Despite this, our independence is our superpower. The ability to rely on nobody is essentially recession proof. It can't walk out the door someday. It can't run out of budget. And it's not going to cost more with inflation. But, left unchecked, this can become one of your greatest weaknesses.

You see, independence is empowering on the way up, but it's lonely on the way down. And in entrepreneurship it's equally as important to survive the crashes as it is to ride the growth.

This week, I had three important moments teach me this lesson.

---

### Friday

Last Friday, I went to a cabin with some friends. We get there and start working on our respective jobs. I took the day to work on [Engine](https://engine.so). At one point, I read aloud a draft of my blog post. After hearing it, one friend said, "Wow, that's really good you should post that to LinkedIn".

And so I did.

This is something I wanted to do, but I was too afraid to. It's scary putting yourself out there. And even more scary doing it in-front of people you know. However, it doesn't take much to overcome fear. And in this case, all it took was one sentence from one friend. 

Find that friend. And, maybe more importantly, be that friend for the people around you.

### Monday

On Monday, I got coffee with a friend of mine who's also [bootstrapping an app](https://www.compasscalendar.app/). He's been working full-time on his app for many months and we had some really good deep chats about that experience.

What's it like working on things all day? How do you pay the bills? What stresses you out? 

And through this conversation I learned a lot. Not just the A,B,C,D bullet-list takeaways. But, the undercurrent of the conversation as-well. There was moments where he'd sigh and I could tell a certain topic was stressful. Or he'd give a look of curiosity when something struck his interest.

This undercurrent is almost non-exists during online interactions. This brings me to my second takeaway this week:

> Meet people in the real world that are traveling on the same mission you are.

### Tuesday

On Tuesday, I met up with two established founders in the bootstrapping scene, [@robwalling](https://twitter.com/robwalling) and [@ColinHirdman](https://twitter.com/ColinHirdman).

We talked about all-things bootstrapping and life. From ways to perform idea validation, to the interesting properties of clear ice-cubes (which being a [zoomer](https://www.urbandictionary.com/define.php?term=Zoomer) I have never heard of before). Now, both these folks were infinitely more successful than myself, but that's a good thing!

It was an opportunity to listen more than I talked. 

To pick someone's brain and not only get suggestions, but get *validated suggestions* in return. If I think of the advice I'd give myself two years ago, I could've been infinitely helpful to myself. There's a value to experience.

And that was my takeaway. Imagine we're all on the same line going towards a similar goal. There's others on the same journey. It can be easy to feel competitive. But, those people aren't better or worse versions of you. They aren't smarter or dumber versions. They're past and future versions.

> So learn from the future versions of yourself, and teach to the past versions.

---

In the end, I learned that, as a solopreneur, it's exponentially more important to foster connections than you might think. It might be even more important to do this as a bootstrapper. Not just for motivation or learning, but for support.

Good friends will push you to do the things you don't naturally want to do. They'll tell you that you're awesome and motive you to go further. And great friends will even tell you when you're doing something wrong.

So, I like to finish these blog posts with **actionable** take-aways for other makers. On the topic of community, I want to give some recommendations.

1. Join every online community for your niche – [DynamiteCircle](https://dynamitecircle.com/join-dc/), [MicroConf Connect](https://microconf.com/connect), [IndieHackers](https://www.indiehackers.com/)
2. Connect in-person with other makers - Find people in the above groups, twitter, or local meetup groups.
3. Feeling down on your business? You might just not have enough support around you. Solve that first.


The importance of connections


Starting something new shouldn't be hard. But, it is. I think Newton's first law explains why this happens.

> An object at rest will remain at rest, and an object in motion will remain in motion.

Of course Newton is talking about motion, but I think it applies to behavior as-well. There's a certain momentum to continuing to do the same thing you have been doing.

If you've been doing nothing, it can be easy to continue that path. And starting something new takes a disproportionate amount of energy. However, If you're already seasoned and consistently doing that thing, habits slowly make it easier to continue over time.

---

This is my first blog post.

Well, not really, as I've written many technical articles before this. But, this is the first that will be more "Official". And, just like anything else, it's hard to start. There's a certain motivation to polish until perfection. To "set a bar" that future articles can live up to.

But, I'm deciding to back away from that. The most important thing isn't that I set a bar of quality. It's that I start a habit of launching. Instead of focusing on the quality of the first post, I need to focus on the consistency of the first 10.

So, welcome to the first of 10.

### Some other thoughts I had about starting things

A huge hobby of mine is listening to unreleased music. For the past couple months I've been listening to old & unreleased Kanye tracks.

When Kanye released his debut album "The College Dropout" in 2004, it sold 441,000 copies in the first week. Debuted at #2 on the US billboard hot 200. And was chalk-full of *bangers* like "Through the Wire", "Slow Jamz", and "All falls down".

It was incredible. And his **first** album, can you believe it!

Except it wasn't his first album. Or first songs. Not even close. He released numerous mixtapes before that. And did years of beat-making before that.

And some songs were good...

But a lot of the songs were... not. 

But, guess what? It doesn't matter how good his firsts were. His legacy isn't great because of his first album.

Likewise, when creating new products I try to take that philosophy to heart. It doesn't matter how good the first version of the product is. It will always improve in v2,3,4 etc.

The whole point of version 1 is to get the ball rolling. To get the inertia started. And start reaping the benefits of consistency.

So, just ship it. And see how it goes 😄.


Firsts shouldn’t be so hard


Redux would've been a fine solution for state management two years ago. But, these days, with how mature the React Context API has become, is it really a good choice anymore?

I'd argue it's not, simply because the alternatives have gotten so good.

Today, I'm going to share one such alternative. This is a design pattern I nickname the "Container" pattern that uses a library called [unstated-next](https://github.com/jamiebuilds/unstated-next). Although, to be fair, the unstated-next library is really just an abstraction on React Context.

But, the real benefits come from the code organization that can come about as a result of this. Today, I'm going to share how to implement this.

---

## What’s the Container Pattern?

The container pattern is a methodology in which instead of having all your global state in one global store, such as Redux, you divide that state into multiple chunks called containers. These chunks are responsible for managing their own state and can be pulled into any functional component in the app, using something similar to the following syntax: 

```tsx
const {user} = Auth.useContainer();
```

This pattern works really well. It divides state into self-managing chunks, rather than having everything intertwined. Each component can simply pull in the chunk of state that it wants to use and is only dependent on a part of your applications state.

Each chunk of state is easy to reason about. They’re simply a custom hooks wired up to context providers — that’s it. The term “Container” really just means “a React Custom Hook and a Context Provider.” So when someone is recommending state management with Hooks and useContext, they’re technically recommending this container pattern.

To use containers you just have to import the Context and use the hook. You don’t technically need any external libraries, however I use a library called [Unstated-Next](https://www.npmjs.com/package/unstated-next) because it gives me some benefits that make this pattern even easier.

---

## What is Unstated-Next?

[Unstated-Next](https://www.npmjs.com/package/unstated-next) is a tiny library that helps us reason about these global containers a little bit easier. This library is **tiny **(like 200 bytes tiny) — for good reason, it basically doesn’t do anything that React’s Context API doesn’t already do.

This library is 100% optional for this design pattern. It just provides some small API improvements that make Context easier to work with. Some of the main benefits include:

- **Type-Checking:** This gives you typescript support out of the box. This was one of my gripes with using the React Context API, so it’s nice to see that unstated-next solves the issue.
- **Error Handling:** If you try to access a container that doesn’t have a Context provider above it in the React DOM tree, it will throw an error. This is a life-saver for debugging.
- **Easier to Think About:** Thinking about contexts can seem abstract at times, but using this library with the mental concept of “containers” is a lot easier.

---

## What Does This Pattern Look Like?

<Image src='https://cdn-images-1.medium.com/max/720/1*cGMKSIcqkYFPQuW6YjE8tg.png' alt='' />

### File structure

When I use this pattern, I put all my containers in a “container” folder at the root of the src directory. I suffix each container with the word “Container” and have all the relevant code in one file.

This already has benefits over something like Redux, where a single responsibility might be divided over three or four files for the actions, reducer, store, selectors etc.

<Image src='https://cdn-images-1.medium.com/max/720/1*7y24LwvXyRg8uSc3htqjBA.png' alt='' />

### The container file

The container is where your slice of state will live. This file contains everything necessary for reading and writing to this part of state. Here’s what a container file may look like for an `AuthContainer`:// The reducer. This would be very similar to your reducer in Redux.

```tsx
// The reducer. This would be very similar to your reducer in Redux.
// This is optional, you can just use useState instead, but this is
// here to show that if you want to use a reducer and do more
// complicated state transitions you can.
function authReducer(state: AuthState, action: Action) {
    {/* ... */}
}
// Custom Hook
function useAuth(initialState: AuthState) {
    const [state, dispatch] = useReducer(authReducer, initialState);
const loginWithGoogle = () => {
      dispatch(loggingIn());
      doGoogleLogin()
          .then(user => dispatch(success(user)))
          .catch(err => dispatch(error(err.message)));
    }
const loginWithEmailPassword = (email, password) => {
      dispatch(loggingIn());
      doEmailPasswordLogin(email, password)
          .then(user => dispatch(success(user)))
          .catch(err => dispatch(error(err.message)));
    }
const logout = () => dispatch(logout());
return { 
      user: state.data,
      isAuthenticating: state.loading,
      error: state.error,
      loginWithGoogle,
      loginWithEmailPassword,
      logout
    };
}
// Create the Container (this can be a Context too)
// You just pass in the custom hook that you want to build the
// container for.
export const Auth = createContainer(useAuth);
```

This is really clean — it’s basically just a custom hook and then that one little line at the bottom to make it a container. When you add that container code at the bottom, it makes this custom hook have the same state, even if used in multiple different components. This is because the `Unstated-Next` containers just use the `Context` API under the hood.

To make that work you first need to add a `Store` to your application which will store all the containers. This might look something like this:

<Image src='https://cdn-images-1.medium.com/max/720/1*bE4jPCLDi7BImyOaPFB-PA.png' alt='' />

Note: I think there could be a better way to manage a `Store` like this. If we could dynamically create this structure based on an array of containers, or something like that, I think that would be a lot cleaner.

Also, if there was a way to make all these load at the same level of the DOM so any container could access any other container, that would be amazing too. Sadly I think that’s a limitation of React.

Put this in the root component, so your root component looks something like this:

```tsx
const App: React.FC = () => {
    return (
      <Store>
          <ReactRouter>
            <AppRoutes>
          </ReactRouter>
      </Store>
    );
}
```

And *voila*! If you did this correctly, you should now be able to go into any of your React components and use this hook like this:const LoginPage: 

```tsx
const LoginPage: React.FC = () => {
    const {
      formLogin, 
      googleLogin, 
      isAuthenticating,
      user
    } = Auth.useContainer();
    useEffect(() => {
      if (user) {
          history.push('/home');
      }
    }, [user]);
    
    return (
      <div>
          <button onClick={() => googleLogin()}>
            Login with Google
          </button>
          ...
      </div>
    );
}
```

If you did everything right, following this pattern should work! If you did something wrong `Unstated-Next` might throw an error that says that the container’s provider hasn’t been created. But that’s good because it’s an explicit error message for a bug that would be really difficult to track down if you were using the basic React Context!

---

### Why Not Use Redux?

Redux is great for state management at a large scale. It’s the tried-and-tested way to manage state for large applications. However, for the vast majority of applications out there, Redux is the wrong place to start. It’s *very* boilerplate heavy and probabbly won’t give you many benefits unless you already know you need it.

So I’m offering this pattern as an alternative.

The main benefit you get from this pattern is that it makes more sense from a developer’s perspective. Redux takes your state and pulls it away from the view layer. I’d argue that a better way to manage state would be to colocate it with the view layer that uses it.

*This is why React Hooks exist.*

You can already see things moving towards this methodology with the movement of other pieces of state out of things like Redux and into hooks:

- **Local state** => useState / useReducer
- **API state** => [React-Query](https://github.com/tannerlinsley/react-query) / [useSWR](https://github.com/vercel/swr) / [Apollo](https://www.apollographql.com/docs/react/)
- **Form state** => [React Hook Form](https://react-hook-form.com/)

So, it makes sense that the global state also be built to fit well into a hook ecosystem.

*The majority of my state management is done by various hook libraries, so it makes sense that my global state management also be hook-centric.*

The container pattern implements this idea. It offers the majority of the functionality as Redux at a fraction of the time-cost and is designed with hook-centric development in mind.

For any small-medium sized-project, this pattern is a no-brainer for me. For a larger project, it depends on the use-case.

Here are some comparisons between the container pattern and Redux:

#### The Container pattern has the following benefits:

- Less boilerplate than something like Redux.
- Uses the native Context API under the hood.
- You can learn the API in 10 minutes if you know `useState`, `useContext` and Custom Hooks.
- Only uses one tiny library, and even that dependency is optional.

#### It also has the following cons:

- No support for middlewares.
- No tool akin to the Redux chrome debugger.
- Containers must be provided in a certain order if they have dependencies on each other.

With this in mind, hopefully, you now have a better idea of what alternatives there are if your use-case doesn’t need something as bulky as Redux.

If you want to employ this pattern but can't quite leave Redux, another alternative would be a using [Redux Toolkit](https://redux-toolkit.js.org/) and a [Redux Ducks Pattern](https://medium.com/@matthew.holman/what-is-redux-ducks-46bcb1ad04b7).

<Image src='https://cdn-images-1.medium.com/max/720/1*H1Gk3KbQQcp86tV0bA0WEQ.png' alt='' />

*Redux Ducks*

This Redux Ducks approach works well if you're building a large application because it uses a container-focused methodology, but still keeps you in the ecosystem of Redux.

---

## Conclusion

That’s the `Container` pattern. If you’re looking at using Redux in an app, I would take a serious look at the cost of doing so to determine if your application actually requires it. I think this pattern is a good place to start regardless, and because it’s so small and modular you can easily migrate it into Redux in the future.

Overall, this pattern has helped me clean up my codebase a lot. It’s also helped me remove state management from my list of pain-points when developing applications.

Let me know what you think — hopefully it will work well in your projects. Enjoy!


Introducing the container pattern – a better alternative to Redux


Let’s entertain a simple scenario for a second:

You’re a solo developer. You have an idea. You tell the idea to your friends. They like the idea. You design a prototype. You spend months on design, code, art, marketing, and then the time comes for you to release it.

You push it out to the world and share it with everyone you know. Then, you get the all too familiar question…

> When is this coming to Android?

So you stop for a minute and think, “hmm… it seems people want this on Android too. What would this actually take to implement”? And so you look it up and discover that:

- You’ll need to learn a new set of steps for deployment
- You’ll need to learn a new UI toolkit
- You’ll need to follow a new set of human interface guidelines
- You’ll need to learn **a new programming language!!!**
- You’ll need to learn how to sync two separate deployments every time you want to add a new feature.
- You’ll need to master the new payment API, and push notification API, and page routing API, and… you get the point.
- In the end: You’ll need to completely rewrite every single line of code from day 0 to today

But, what if there was a solution to this? Well, there is, and it’s called **cross-plaform app development**

# What Is Cross-Platform App Development?

Cross-Platform development is the idea that you can use 1 codebase and deploy it to multiple platforms at once. Usually, this is done by programming your project 1 time in a language like JavaScript, then using a WebView to embed that javascript code into your mobile and desktop apps.

The WebView can basically be thought of as basically a web browser with the borders removed that just shows the content of the page. It will end up looking something like this:
<Image src='https://miro.medium.com/max/1260/1*X8MJwDLDqd6ukC8bUlQmcA.png' alt='' />
By designing an application like this means you only have to write code once, so the productivity gains can be massive. Think about it like this:

If **n** is the number of platforms you support, when you write native code for each of these platforms you’re basically developing at O(n) speed. When you develop using cross-platform technologies, you’re now developing at an O(1) speed since you don’t have to do much more work to make the app for more platform. Now wouldn’t that optimization look impressive in a coding interview?

Okay, so if there’s so much to gain by developing cross-platform apps, why doesn’t everybody do it?

Well, it’s because cross-platform development, just like any technology, doesn’t come without it’s downsides.

# The Downsides of Cross-Platform Apps

When you opt for a cross-platform solution, there’s almost always going to be a tradeoffs in terms of speed, support, and stability versus building a native app for each platform. I think these downsides can be easily overlooked, so here I’m going to list some issues you might come across along the way:

### 1. Cross-Platform Apps are slower

Building a cross-platform app means there’s an added layer of abstraction that your code has to run through. I’d say for most apps this difference is negligible, but it still might come into play.

### 2. Deployment Can Be More Complicated

It’s easier to deploy new features when the codebase for different plaforms is silo’d off from one another. Each platform can have their own launch schedule, testing procedures, and pipelines, but when everything is tied together you have to find a good solution for managing everything.

### 3. Limited Functionality

Most cross-platform solutions have a good repository of libraries for doing native operations. Examples include push notifications, popups, UI-matching etc. This is amazing, but I’ve yet to find a solution that fully encompasses all the possible native functionalities.

This might limit certain apps, but won’t be a problem for most use-cases. If you’re not sure if this will effect you or not, it probably won’t. I’d say 98% of use-cases can be done perfectly well through cross-platform.

So now that you know the drawbacks of cross-plaform apps, lets get into my preferred way of building cross-platform apps.

# Which Cross-Platform Framework Should I Use?

There’s a lot of different solutions for building cross-platform apps. You have quite a few popular solutions such as [React-Native](https://reactnative.dev/), [Cordova](https://cordova.apache.org/), [Ionic](https://ionicframework.com/), [Capacitor](https://capacitorjs.com/), [Flutter](https://flutter.dev/), so the decision isn’t an easy one. I’m not going to discuss the tradeoffs between these in this article, but here’s some good articles that compare the differences between these alternatives:

- [Cross-Platfrm App Frameworks in 2019](https://www.netsolutions.com/insights/cross-platform-app-frameworks-in-2019/) by Amit Manchanda
- [7 Popular Cross-Platform App Development Tools That Will Rule in 2020](https://medium.com/datadriveninvestor/7-popular-cross-platform-app-development-tools-that-will-rule-in-2020-349c80fb51) by Sophia Martin

Instead, today I’m going to talk through the framework that I believe is the best, and why it’s been a pretty amazing stack to work in.

# The Cross-Platform Tech Stack I recommend

At [Pwego](https://pwego.com/), I consistently work with companies to optimize their cross-platform deployments. When asked what tech stack to use, my recommendation is usually the same. This is the reasoning I usually give.

A lot of React developers would opt for something like React-Native. I decided against this because I didn’t want to write any native code at all. I also didn’t want to deal with compatibility issues with other React libraries that I might want to include, so I went with Ionic

Ionic released its version that officially supported React back in October 2019. I was an early adopter to this release, and started using it a month after it’s released. I’ve now been on the technology for 9 months and although it’s had some issues, I think the technology has come a long way. Here’s some of the things I love about Ionic + React:

- It’s deployable to everything. iOS. Android. Electron (desktop). Web. Etc.
- I’ve never had to write any native code.
- I can test my code and develop it in the browser, then when I’m ready to test how it works on mobile, I can build the code and test it directly in XCode/Android Studio
- Ionic is now framework agnostic
- There’s a [repository of ionic react-hooks](https://github.com/capacitor-community/react-hooks) that give you an easy interface for a lot of native capabilities

Here’s a rundown of the other pieces in my cross-platform tech stack.

## Ionic

Ionic is basically a UI kit of different generic components that you can use in your web code to have native-looking features in your app. It offers generic components like an `<IonButton>` that might look like this on iOS:
<Image src='https://miro.medium.com/max/626/1*IaNDFdgKJdMN7273JzZQ1A.png' alt='' />
and this on Android:
<Image src='https://miro.medium.com/max/648/1*reV9EFm7QKNBJWK2Ocf-QQ.png' alt='' />
The difference between these may look small, but it’s meant to make your application look and feel native no matter which device you’re on. I think this has it’s tradeoffs because your UI won’t always be consistent across platforms. For example, on iOS those buttons are slightly bigger which means your UI will look different on both platforms.

This is annoying at first, but over time you’ll learn the oddities of each component and what they look like on each platform, and then it’s much easier to work with them.

I’ll also note that these Ionic components are generic, so they can be used paired with React, Angular, Vue, or even [no framework at all](https://www.joshmorony.com/using-ionic-with-any-framework-or-none-at-all/). This is very powerful because it means you won’t be locked in to a frontend framework as-well if you choose this technology. In my opinion, this is a large benefit over something like React-Native, because it future-proofs the technology much better.

## React

React is the most popular web framework, pulling ahead of angular by a greater margin every single day. I first started pairing Ionic + React in 2019 within a month of Ionic being supported on React. Through this process things have become far more stable, so now I feel comfortable recommending the two technologies together.

## Capacitor

The React code is what will get displayed in the “WebView”, and it will use Ionic components to mimic native the look and feel of native components. Then, Capacitor comes in and acts as the “build step” that will take that web code, bundle it into an app and then toss it into Android Studio or XCode for you to configure further.

## Firebase Cloud Messager

On the backend, I like to use FCM because it gives you the same cross-platform capabilities, except this time it’s with your push notifications. If you didn’t know, android and apple both have their own push notification services. If you want to send out a notification to all your users, you’d have to write the API calls twice to upload that notification for both services.

Using something like FCM, you can have 1 single API to upload push notifications to, and then they’ll get forwarded to all the different notification services for the platforms your users are on.

## Ionic Appflow for CI/CD

I’ll admit, I haven’t use Ionic Appflow yet, but I must say the technology looks attractive. One of the really interesting features to me is their idea of “live deployments”.

Basically the idea here is to let you push new web code to your mobile apps without having to push a new release to the stores. This means you can use their CI/CD platform to just push new frontend code once and have it automatically be update the website and every single user’s app. That’s insanely powerful if you think about it! Not only do you only have to write code once, but you only have to deploy it once too.

If AppFlow was free, I’d give it a try right now because that’s a super attractive service for small development teams.

# Conclusion

In the end, there can be quite a few tradeoffs you’ll have to make with a cross-platform solution, however the downsides can be minimized by choosing a proper tech stack. Using something like capacitor is going to give you a really solid way to embed your web apps into native code. But combine that with a cross-platform CI/CD platform like AppFlow and a nice UI-kit like Ionic and you can end up with a solid app. Enjoy!

Want to bring in expertise to guide your the cross-platform solutions at your company? I run [Pwego](https://pwego.com/), a SaaS & cross-platform consultancy that specializes in exactly that. Let’s get in touch and discuss your use-case!


The ideal tech stack for building cross-platform apps in the modern era


The other day I was converting a JavaScript component to TypeScript and I got tripped up in one specific area: React Context.

Now don’t get me wrong, I’ve used TypeScript a million times before, but for some reason Context was not clicking with me. So I went back to the drawing board, looked up some tutorials, and familiarized myself with Context again.

That said, during this process I found some clean mental models and shortcuts that I found to make understanding React Context *effortless*.

That’s what I’m sharing here today.

## The 3 Parts of React Context — Visualized

I like to think of Context as needing 3 parts. The official docs call these the createContext, producer, and consumer. But, I think it’s easier to think about these using the metaphor of just a normal variable.

### 1. The Context Creator

Think of this as the `let myContext;` of your Context. It’s just creating the Context, but not filling it with any functionality yet.

### 2. The Context Provider

Think of this as the `myContext = [];` of your Context. It fills the already created Context with some sensible default data.

### 3. The Context Consumer

Think of this as the `myContext = [1,2,3];` or `let myData = myContext[0]` . This is where you will manipulate the Context or read its data (hence the name “consumer”).

### But… there’s a problem with these typings.

Since we’re using `undefined` when we create the Context, we’re not getting good types when we go to consume it.

Every time we want to use the Context we have to check if it’s undefined first. This means if we want to use the `addTodo` function, for example, we have to do `myContext ? myContext.addTodo() : null`.

However, this check is kind of odd because if we’re using Context properly it should never be undefined. If the component consuming the Context is under the provider, then the Context will always have the defaults passed in from the provider.

The only reason we need to give it a default type of `undefined` is if the consumer is not a child component of the Provider.

One solution I see a lot is to give more specific field-level defaults like this:

Notice that instead of setting the entire Context to `undefined` by default, we instead plug in sensible defaults for each field. In one sense, this is better because we no longer need to check if it’s undefined when consuming.

That means code like this:

Can become this:

To explain this again using our variable metaphor: Before we were doing `let myContext`, then `myContext = []`. This is bad because you’re changing the type of the Context from `undefined` to an array. Generally you don’t want to change the data type of something after it’s been created.

With this better typing, now we instead do `let myContext = []` right off the bat. I’m sure you can see why this is better.

## But this brings up another issue…

If we make this change, it’ll be easier to consume the Context, but what if you have a component trying to consume the Context that isn’t a child?

This component will now call the `myContext.addTodo()` function, but instead of doing what it expects, it will just silently fail. That’s because the function just looks like this: `() => {}`.

Now you might be thinking: “Well, you could change that function to log something to the console”. And you could. But, what if it’s not a function, but a field instead? How would you log to the console in that case?

So, that doesn’t fix the underlying issue.

The underlying issue is that React is allowing components to consume Context even if they’re not children (although it doesn’t do anything). Also, since React doesn’t explicitly throw an error when this happens, it makes typing things and managing their dependencies a lot harder.

Now personally, I think this is poor design on React’s part.

If a component tries to use a Context, but isn’t a child of that Context it *should* throw an explicit error and crash. That’s because this should only happen because of user error. Either the developer moved the component somewhere it shouldn’t be, or they moved the Context somewhere it shouldn’t be.

With the current way React handles this, you would have no idea that things aren’t working unless you went in functionally tested the component. If it threw an explicit error, you would know instantly when the page is rendered.

This also brings up one last issue:

> Why do I have to explicitly define the types for my Context anyways? Shouldn’t the types be generated automatically based on what’s passed into the Provider?

Boom! If you’re thinking this, you’re right. But sadly, since Contexts are accessible in any component (not just children) you have to provide default values in-case it’s not a child. That’s because one of two scenarios is going to play out. Either:

(a) The Context consumer is a child of the Provider → It will use the data passed into the Provider.

(b) The Context consumer is non a child of the Provider → It will use the default data passed into the `createContext` function.

## So, how do we fix both of these issues?

The nice thing is that we can kill two birds with one stone here. And, the solution is simple:

> If a component tries to consume a Context and isn’t a child of the provider, throw an explicit error.

If you do this, then Contexts can be typed automatically based on the props passed into the provider. That’s because no component will be using the Context outside of the scope of the Provider, so we don’t need to add typings for that use-case.

Additionally, we can now have an explicit guarantee that a component hasn’t been accidentally moved outside of the Context it needs.

So, there ya go. Two birds with one stone!

Implementing this is not difficult either. You can implement this addition on top of the current Context API or use a library. I personally use a library called [unstated-next](https://github.com/jamiebuilds/unstated-next) to implement these changes for me. The library is 40 lines long, and adds proper typing and explicit errors to Context.

If you want to learn more about this library, I actually wrote an [entire article about using unstated-next for state management](https://betterprogramming.pub/the-container-pattern-for-better-state-management-in-react-9351fe4381d1). Otherwise, feel free to use any methods discussed in this article to type your components. They’re all effective solutions, just with tradeoffs and risks that you’ll want to be aware of.


How to type React Context with TypeScript – and why is it so painful?


Ughh… why does form code in React always get so *messy?*

It starts out simple: a `<form>` component, a couple input fields, and a submit button. But soon things get a little more complicated.

You think, “hmmm.. I want some more validation for this zip code field”. So you add a custom workaround that validates the data in the input field.

Then, you think “I want to disable the submit button when the form is submitting”. So you create another custom workaround that keeps track of what’s submitting, and when things are complete, etc.

Then, you think “I want better error handling”. So you add yet *another* workaround.

And over time that simple form balloons into a 400-line long super-component with multiple useEffects, useStates, and custom logic to handle all the edge cases.

Sound familiar?

I’ve had this trouble more times than I’d like to admit. So 6 months ago, I decided to double down and find the solution. I wanted to know:

**What’s the absolute BEST way to manage forms in React so they’re organized, performant, and easy to debug?**

That’s what I’m going to share here today.

## Firstly, a form library — do I need one?

I’ve come at this crossroads before. As a project is small the answer usually starts as “**nah”**, then over time it inevitably sways towards “**please, please yes”**.

So now, I advocate for form management libraries no matter what scale of project. Form libraries usually have a relatively small bundle size and make a world of difference for code organization.

But, I should note: I’ve also seen custom form management work in the past.

The issue is that it’s **really difficult.** It’s possible, but even if you’re successful you’ll usually end up building a similar version of another form library except without all the great documentation.

That’s why I recommend starting your project with a good form library from the get-go. So that brings us to the next question.

## What’s the best form library?

This decision making process could be a whole other article in itself. But, I want to focus on concrete design patterns today, so I’m only going to give a high-level overview of the landscape.

### The Plethora of Form Management Libraries

The landscape for form management libraries in React is huge. But, luckily it’s concentrated among only a few popular libraries. Some of the most popular are: [react-hook-form](https://react-hook-form.com/), [formik](https://formik.org/), [redux form](https://redux-form.com/8.3.0/), and [react-final-form](https://github.com/final-form/react-final-form).

Here’s a breakdown of their popularity, with Formik as the most popular and react-hook-form chasing close on their heals.
<Image src='https://cdn-images-1.medium.com/max/1440/1*CVVQ7Z7BU7LemIglM1J-1w.png' alt='' width='md' caption="Popularity graph of different react form libraries" />
As I already mentioned, I’m not going to be deeply comparing these solutions in this article. But, if you want a great article comparing these, check out [this great post comparing these libraries from Retool](https://retool.com/blog/choosing-a-react-form-library/).

---

With that said, the two form libraries that I consider to be an excellent choice are **Formik** and **React-Hook-Form**.

Both provide hook-centric form management and have great documentation, active devs, and a healthy user base.

However, between these two, I tend to lean towards **React-Hook-Form** andI’ll explain why below.

## Why React-Hook-Form?

React-hook-form (RHF) is great because it prioritizes hooks to manage your form state (hence the name). This makes it fast, flexible, and a breeze to work with if you’re already using hooks.

Among it’s various benefits, one advantage over Formik is that react-hook-form was created exclusively for hooks. This means, although react-hook-form can’t support class components, their docs and best practices are more focused. If you look up articles online, you won’t find a lot of outdated guides with old design patterns. I find this extremely valuable when trying to learn a new library.

They also have numerous other small performance, bundle, and flexibility advantages over the other libraries. Here’s just some examples:
<Image src='https://cdn-images-1.medium.com/max/1440/1*fT3ofoRiB7_gD7RI2cx81Q.png' alt='' width='md' />
That’s why I chose React-Hook-Form. However, if your codebase uses a lot of class components you might be better off going with Formik as it’ll be easier to integrate into your components.

## The design pattern: The 3 Layer Approach
<Image src='https://cdn-images-1.medium.com/max/1440/1*ZxD1tzlPz8k_iVKkKeQvUg.png' alt='' width='md' caption="The 3 layer approach (visualized)" />
The basic premise of the 3 layer approach is to take a complicated form component and split it into three parts.

Each part will be its own react component and will focus on one responsibility of the form (see: [SOLID](https://medium.com/@ipapikas/solid-series-1-5-single-responsibility-principle-5a93f235f0c4)). Each part will also be named with a suffix (Apollo, Logic or View), which will make it easier to find.

Here’s an overview of what each component does:

#### Apollo Component
This component handles strictly the network requests for your form (aka. fetching the initial data for the form, and submitting the final data to your backend). It’s named “Apollo” because I typically use [Apollo](https://www.apollographql.com/) to talk to my GraphQL backend. Feel free to use a more relevant suffix such as: “API”, “Network”, or “Fetch” if you prefer.

#### Logic Component
This handles the logic for the form. This is the component where you’ll define the shape of the form, default values, and validation.

#### View Component
This component renders the view of the form. It’s meant to be a stateless component. However, I usually allow view-related state in this component such as an *isOpen* toggle for an expandable section of the form or something similar.

## The 3 Layer Pattern Further Explained

This chart shows how the data will flow between these three layers to create an organized form structure. Start at the `Apollo.tsx` file and follow the arrows to read how the data will flow through the components.
<Image src='https://cdn-images-1.medium.com/max/1440/1*h_06i48SIOHU-B-cPne5mw.png' alt='' width='md' caption="Data flow for the 3 layers" />
Let’s dive a little further into each of these components. I use TypeScript in this example, because it will help give a good look into the different types of data being passed around.

Also, here is the finished codebase. If you’re a hands-on learner feel free to play around yourself as you read.

### CreateUserApollo.tsx Explained

The Apollo component is responsible for fetching form data over the wire. Here’s what it looks like.

There’s a couple things I want to point out about this component.

First of all, notice how the data fetched from the database is transformed before being passed down into the default values of `<CreateUserLogic />`. This is important, because in general it’s a good idea not to trust data fetched from over the wire. If you don’t do this it can go wrong in one of three ways.

(a) You can end up fetching too many fields from the API. This means your form will have more defaults than it needs. This can add clutter to your form and problems when we get to validation.

(b) This also safeguards against bad defaults (ex. `undefined`). Instead of trusting the backend, it’s a good idea to provide sensible defaults, such as the empty string, just in-case.

(c) It’s more robust. Notice how the `user` field from the API is transformed into the `username` field before being passed down to the form? This is useful for other fields too. Ex. parsing a string timestamp from the backend into a Date object for the form.

The second thing I want to point out is regarding the handleSubmit function. This function takes the submitted form data, transforms it into JSON for the API, and **returns** an async function for updating the database with the result.

Returning the async function is important. You’ll see this a bit later, but essentially it allows you to await the API response in your CreateUserLogic component which means you can know what the submission status of the form currently is.

### CreateUserLogic.tsx Explained

The goal of this component is simple: set up the form with the default values, pass the form down to the view layer, then handle submitting the form to the parent component when the submit button is pressed.

The main thing I want to point out here is the handleSubmit function. You’ll remember that the Apollo component had a handleSubmit function too. Why do you need two of them?

The reason is to keep our three layers modular. The handleSubmit in this component lets you make state changes after a successful submission of the form. It doesn’t care **how** that data is submitted, it just cares about when it completes.

Trust me, I’ve tried doing it other ways and eventually you’ll realize this way is the cleanest. It lets you keep each layer from needing to care about what’s happening in the other layers and instead simply focusing on what they care about.

In this example, we reset the form after submitting. But, you can just as easily use this to route to a different page, show a success toast, close a modal, etc. This design pattern leaves it up in the air, which is good.

Also, it’s important that you either await or return the onSubmit(data) function. If you don’t, everything will still work but react-hook-form won’t know when you’ve completed the submission process and won’t properly handle the `isSubmitting` state of the form.

### CreateUserView.tsx Explained

Finally we have the simplest component. This one simply renders out your form fields. Since you’ve done all the hard work in the layers above this component can be pretty simple.

This is great because in a large form this will usually be your biggest component. Additionally, this component only handles the “look” of the form and won’t deal with any logic. This is great because now you can easily hand this file off to a designer and the designer won’t need to care about how the form works, they only have to worry about how it **looks**. Which is great!

## The benefits of this pattern

Ok, so I mentioned at the beginning of the article all my pain points when building forms. Not only does this structure solve all of those, it also has some other inherit benefits as-well.

#### 1.  ✅ Built in type checking and validation for every step of your form

If you noticed, the logic component contains per-field validation, and every step of this process has strong typescript typings. This makes it very hard to mess up and much easier to debug.

#### 2. 🔍 Easy to find where things happens

Do you have an issue submitting data to the backend? It’s likely in the *Apollo**component*. Issue with the default value of a field? *Logic component*. Issue with the “look” your form? *View component*. Super easy!

#### 3. 💨 Automated testing is a breeze

This is a commonly under-looked benefit of this pattern. But, if you notice, you can test the functionality of a form by passing props to the Logic components directly. There is no need to mock your backend at all since you can test all the functionality by bypassing the Apollo component entirely.

#### 4. 🎁 Forms become *much* more composable

This means you can mix and match different layers to have the form behave differently. You can have different Apollo components submit form data in a different way (ex. editing vs. creating a document). Or vice versa, you can reuse an Apollo component for different forms to submit different data to the same backend services. Really cool!

#### 5. 👥 Easy to Divide-And-Conquer for Teams

This structure lends itself well to working with a team. Your designer can work on the View layer, while the backend person can work on the Apollo component. Then, you can easily meet in the middle at the Logic component and get your new feature launched twice as fast!

## And that’s the design pattern!

As you can see, by combining a good form library with a good design pattern can make messy form code a thing of the past. It allows for easier collaboration, cleaner development, and faster debugging. What’s not to like?

If you have any further questions or improvements, reach out!


The Best Design Pattern for Managing Forms in React


Progressive Web Apps (PWA’s) are becoming more widespread every day and when you see their benefits it’s easy to understand why.

PWA’s are proven to bring about higher customer engagement, higher customer retention, and increased conversion rates to your web app.

## So, what are PWA’s?

To put it simply, PWA’s are basically phone and desktop apps that are built with web technologies and downloaded through the browser.

**This is crazy powerful.**

Think about it: You no longer will have to deal with app store approvals, separate code-bases, different deployment methods and everything else that comes along with native apps.

Instead, you build a PWA once using web technologies and deploy it to the web. This might look a little something like Starbuck’s PWA:
<Image src='https://miro.medium.com/max/700/1*YxWMZR1ZESKCwR4wwz4QlA.png' alt='' />
If you notice, both of these things are actually the same app. The difference is that one is a website that is accessed through a browser, and the other is a PWA which, once downloaded, the user will access just like they access any other app or desktop application.

## How is a PWA different from a native mobile app?

PWA’s are different from native mobile apps because they never go through an app store. PWA’s are “downloaded” directly from a website and the contents of the app basically is just the contents of that website except it’s not within a browser, but rather is a standalone experience.

Native apps take a lot of development time to create. If you want to build a native app for android and iOS that will take 2 development frameworks, 2 programming languages, 2 deployment pipelines etc.

Progressive Web Apps, on the other hand, are built using the same technology as your website. In fact, if you already have a website built you can convert it into a PWA without too much effort.

This is awesome because you don’t have to write a new app to deliver a native mobile experience to your users.

## How does a PWA work?

Modern PWA’s have 3 components to them. These components combined make the PWA possible. They are:

1. **HTTPs** (SSL) — PWA’s can only work on secured connections. If your site already uses https, then you’re all set for this step.
2. **Service Worker** — The service worker deals with caching and handling the network requests for your PWA. This lets it function properly as a standalone app.
3. **Manifest.json** — This JSON file simply contains configuration information detailing how your PWA should display. This can include the logo, app name, description, splash page etc

## How Do I Setup a PWA?

I’ll be writing a blog post soon to describe the setup process for a PWA. For now, the implementation is heavily specific to your existing codebase, what tools you’re building with, and whether or not you already have a service worker. For now, a good resource to learn more about this process can be found here: [https://web.dev/progressive-web-apps/](https://web.dev/progressive-web-apps/).

Thanks for reading! I’ll be writing many more articles related to PWA’s in the future. Have a nice day!


Progressive Web Apps — the future of mobile?


Skiwise is an app I’ve been developing with the goal of connecting cross country skiers with a network of their peers to share knowledge around trail conditions, social events, weather changes, and more. Originally beginning in November 2019, I’ve been working on this project for almost 700 hours total over the course of 9 months.

I’m writing this article today to go through the whole development journey to date, and look at what sort of hurdles and challenges I had to overcome through the process. I hope this article serves to give some inspiration and direction to other developers looking to start similar projects.

Enjoy the read. Thanks!

# The Origin

Skiwise was born in November of 2019. At this time I had just finished up redoing my personal website ([https://spencerpauly.com](https://spencerpauly.com)) and was now sitting in-between projects. If you’re anything like me then you know that being in-between projects is the **worst.** It means you wake up and have no tasks that you look forward to doing that day. That sucks.

I tried to start a couple projects, but nothing really held my interest past a few days. This forced me to sit down and re-evaluate what I really wanted out of my next project. Here’s the main takeaway I learned during this time:

I learned that I didn’t want to make any more “personal projects”. I was sick of making stuff that would only I would use. Although I learned a lot of skills by doing these, I never found them fulfilling once I completed them.

I wanted other people to see what I built.

I wanted other people to say “Hey! That’s so cool! But it would be even cooler if you added _____!”.

I wanted other people to get value out of my project.

But what I really wanted was…

> I wanted other people to have the same amount of passion towards my project as I had.

So I was done making personal projects. This time, I was gonna make something for other people. Therefore, I wrote down the three core requirements that my next project needed to have…

### 1. Passion

It absolutely needed to be something I was passionate about. I wanted to know I wouldcontinue the project to completion. It had to be something so sticky I couldn't help but  finish.

### 2. User-Driven

It had to be something that people would use. I wanted feedback, questions, bugs, scale issues, and everything else that comes with developing for humans.

### 3. Marketable

It had to be something where my marketing strategy would be more than “google ads”. I wanted it to be something I could share with my friends and people around me and know they would be interested.

With these requirements in mind, I gave these inputs to my girlfriend and, being the idea-generation machine that she is, she took these inputs and churned out the best idea I’d ever gotten: **Skiwise.**

## The early days

Within minutes of getting the idea for Skiwise I began prototyping. When I say it was within minutes, I mean it was within **minutes.**

Here’s the first draft of Skiwise prototyped on my statistics worksheet during class while we were supposed to be working on problems:
<Image src='https://miro.medium.com/max/1400/1*omhBoouu4hx0I2y8UIG9iw.png' alt='' width='md' caption="The professor walked around to glance at people’s papers. She saw my worksheet and gave me a glare, I just said “Yeah I’ll get it done by the deadline don’t worry”. I’m not sure if I ever got it done." />
The basic premise of Skiwise at first was to be a sort of vertical social-network for cross country skiers. There’s numerous websites for cross country skiers to share information, but nothing is really leveraging what’s possible in 2020. I wanted to create 1 place where skiers can do all their relevant activities like viewing trail conditions, race results, news, etc.

With this goal in mind, I knew all those features would be challenging so I started with the feature I that I considered to be most important of these: trail reports.

Trail reports became the focus of the project, so 3 days after creating the paper prototype I developed the first software prototype of Skiwise:
<Image src='https://miro.medium.com/max/938/1*m2IpV0ta5Aj7oMV0W5oHBQ.png' width='md' alt='' />
This prototype still had a looooong way to go.

It might look alright on the surface, but trust me there was nothing going on behind the scenes. The search bar wasn’t functional, the text for each of the trails was hard-coded, and the other pages displayed at the bottom bring you to nowhere. I mean, dang, I hadn’t started **any work** on building out the backend yet!

This started a month-long push to bring this prototype to functionality. I hit a lot of snags during this time such as [managing local state](https://medium.com/@spencerpauly/the-container-pattern-for-better-state-management-in-react-9351fe4381d1), [building out the backend](https://medium.com/swlh/why-i-switched-away-from-google-firestore-and-will-never-go-back-e34cafb733b), dealing with deployment to different platforms, and many more issues, but eventually I got it working.

The app worked, but this initial release made a lot of compromises.

For example, although the app was built with React, Ionic, Capacitor and other web technologies, I was only able to successfully deploy this version to the iOS store. I also had no way of managing different environments for development and production, so this resulted in me crashing production numerous times while adding features throughout the winter.

Despite this, I had a goal to get the app released before the ski season and I had hit that deadline.

## The initial release to the app store

Skiwise was released on January 1, 2020, just 5 weeks after that paper prototype. In hindsight, this release was probably way before the app was stable. However, since cross country skiing is a seasonal sport, I had to get this project out there while it was still relevant.

It’s also important to note that I’m a firm believer in [the lean startup methodology](https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898). One of the most emphasized points in that philosophy is to get your product in-front of users ASAP. **They even recommend as quickly as 2 weeks sometimes!**

But that rushed release date meant I didn’t get very positive feedback from users:
<Image src='https://miro.medium.com/max/1260/1*Gfr_LkyMOzyZOoDNluD_OQ.png' alt='' />
Here’s where I learned some of the most important lessons on the whole project. I learned that negative feedback, while sometimes harsh, is actually kind of awesome. You see, since I only spent 5 weeks on the project, this feedback didn’t hurt me personally. I was just as well aware of the flaws as the users were, but now I knew which flaws were most important to the users.

> As a developer, I’m always aware that there’s a million improvements that can be made, but knowing **which **improvements are highest priority is the million dollar question.

This switched my philosophy on development. Now I focus on letting the users choose what I build and where the app goes. This makes me nothing more than a transparent cog in the machine that takes ideas and converts them into features, then listens to the feedback and repeats the process.

## Gathering user feedback

The app did alright through the ski season, but I knew the summer was the time when I would actually be able to improve it. Therefore, when the snow started melting I decided it was time to gather some concrete user-feedback. To get this feedback [I released a year-end survey](https://docs.google.com/forms/d/1pXuXMhqORlG9icr-wH9CiCPuTug7RssX_bVs0AIeoGY/edit?usp=drive_web) that asked users a variety of questions to help me direct my development effort during the off-season.

Here’s what I learned from that:

#### 1. I was building for the wrong platform. Oops!
<Image src='https://miro.medium.com/max/1400/1*ePYe0ZvltxXyyQ6flb55Uw.png' alt='' width='md' />
Skiwise 1.0 was only released to iOS. It was built using 100% web-technologies, so it could’ve been released to Android and web as-well if I wanted, I just only considered releasing to iOS since I don’t own an android device.

This survey helped me realize that I was leaving a big portion of my market out of the app, and for next year I needed to focus on providing a version for all users.

#### 2. The only feature that EVERYBODY wanted was trail reports
<Image src='https://miro.medium.com/max/1400/1*vZvGb0LoCro7I154DYDEoQ.png' alt='' width='md' />
I did a survey asking how valuable people thought each feature would be. I gave users 11 features to rate on 1–5 based on importance.

The results showed that **basically everybody found trail reports to be extremely important**, and although people also ranked other features as important, nothing came close to trail reports.

This was nice to hear, since it meant I could shave down my project scope immensely. As a solo developer, you should always be optimizing for doing the least amount of work with the most amount of payoff.

Instead of trying to make a trail reports + race results + events + a social network + a news app for skiers, I decided to focus on only making a the best trail report app in existence. As the saying goes:

> “It’s better to do one thing well than ten things poorly.”

This gave me a very concrete direction during the summer.

#### 3. 80% of skiers only ski at trails within 30 minutes of them
<Image src='https://miro.medium.com/max/1400/1*3Pcpkw1_gDKsXxYBCHF-iA.png' alt='' width='md' />
This statistic made a big impact on me. If you scroll up and view the UI for the original prototype of Skiwise, you’ll notice that I have each trail system as a “card”. A user can then “subscribe” to follow a trail’s card which can be clicked to view trail reports for that trail.

That UI is okay, but this statistic made me think:

> If almost everyone is only skiing at trails within 30 minutes of them, why not just show information for nearby trails by default?

This realization was reflected in the decision to make a map-focused main screen so I can display the same information, but in a more relevant and visual way than before.

## The results of user feedback

This is the before and after of Skiwise after analyzing data from all the feedback gathered by users:
<Image src='https://miro.medium.com/max/1400/1*zy6uOIJqiYyCeqoY1s_9ZA.png' alt='' width='md' caption='Skiwise 2/10/2020 (left), Skiwise 9/13/2020 (right)' />
Here’s some things to note:

1. No more bottom tabs.

Skiwise was going to **focus** on trail reports. This meant that bottom bar was just a distraction. This was also a good move because I was now able to replace that bottom bar with ads without taking away an annoying amount of screen real-estate.

2. Trails are now displayed on a map.

This makes sense. If you only want trail reports for trails within 30 minutes of you, a map gives you that functionality out of the box.

Plus: If you want to go hunt for other trails, you can also search it or pan the map around. It’s a user experience win-win.

3. Skiwise is now iOS, Android & Web.

After realizing iOS only included 1/3 of my userbase, I decided to now support all three platforms. This addition has been really well-regarded by the users so far.

4. Trail Report creation is now front-and-center.

See that button in the bottom right? Users can use that button to submit trail reports. This lowers the barrier-to-entry for making trail reports which means more trail reports, and more value for other skiers.

## Skiwise today and beyond

This brings us to today where I’m excited to announce that this week Skiwise has been released for iOS, Android, and Web!:

- [Skiwise — For Nordic Skiers on App Store](https://apps.apple.com/us/app/skiwise-for-nordic-skiers/id1491659436)
- [Skiwise — For Cross Country Skiers on Google Play Store](https://play.google.com/store/apps/details?id=com.skiwise.app)
- [Skiwise App Live on Web](https://www.skiwise-app.com/)

This is the culmination of close to 700 hours of development time and I’m super proud of the end product. I’ve been able to fix virtually every single issue with the previous version of the app and add numerous big features on top of that.

**Is the project anywhere near done?** No. It never will be, but it’s come a long way and will hopefully have even more growth in the future. As of writing this Skiwise has:

- 450+ ski trails in our database, and growing every day!
- 500+ registered users, even before snow fall!
- 68 integrations with ski trails across the midwest for auto-posting trail reports from their groomers
- 500 instagram followers and an email list of 110 passionate skiers

Hopefully Skiwise can continue to grow in the future and add more features as I figure out more and more cool things that are possible.


The 9 Month Solo Development Journey of Skiwise


As we approach late August, the time is coming for college classes to kick off again. Whether your school is online or in-person, I believe there’s a handful of things you can do to make this year a success. This article is a collection of tips for computer science majors to help them have a successful year. This information has been curated from my four years of learning at university, along with various pieces of advice from other students, graduates, and professors.

---

## 1. You Don’t Need to Know How to Program Yet

***And here’s proof!***

Trust me, you don’t need to know how to program going into a CS degree. Hell, the degree wouldn’t exist if everyone was expected to come in knowing what they are doing already. Want proof of that? Here’s Exhibit A:
[https://github.com/spencerpauly/bubble-sort/blob/master/main.cpp](https://github.com/spencerpauly/bubble-sort/blob/master/main.cpp)

This is my first personal project, that I made halfway through my freshman year. It’s a super simple sorting program — like 100 lines of code simple. But at the time I was super proud of it and thought I’d discovered some amazing new algorithm. The reason I’m sharing this is that the fact that I was proud enough of this tiny project to put it on Github should show how little I knew going into my CS degree!

Now, just over three years later, I have a mobile app launched on the app store and have done various other medium-sized projects over the past two years. The path from bubble sort to app store can be a hard one, but trust me it’s attainable. School will do a good job of teaching you the basics, so don’t worry about how much you know going into the major. After you learn the fundamentals, it’s up to you to gain more knowledge before you graduate. The rest of these tips aim to help you do that.

---

## 2. Ride the Wave to Mastery
<Image src='https://cdn-images-1.medium.com/max/1440/1*9ZbCv6O3Sr7x6d3lt3uNRA.png' alt='' width='md' />
If you’re like me, you constantly feel like you’re in one of these two camps as you embark on your journey. Although it’s pretty awesome to feel like a god all the time, it’s not practical and you’re bound to get stuck over and over again.

I like to think of this paradigm as just *riding the wave* to mastery. You have to ride the ups and downs, but what you’ll find is the general long-term trend will be an upward slope to mastery as you learn more things.

My advice here would be to not get discouraged during the hard parts of the learning process. It takes a long time to learn these skills, so just relax and ride the wave.

---

## 3. Learn in Public

This is a concept I’m trying to do more and more. It’s the idea that whenever you’re learning something new you should do it in a public context. So, if you’re developing an app, build it in a way where others can follow your journey. You can do this by posting a weekly blog on medium or dev.to, posting a daily update on Twitter, or even making a YouTube channel and sharing your learnings there.

This has two benefits:

1. Employers *love* this. Companies know that no intern is going to be a master of their craft and that’s not what they’re looking for. Companies are looking for someone who’s good at learning, good at communicating, and passionate about what they do. There’s no better way to demonstrate these qualities than having a repository of your thoughts and saying “Look — this is everything I’ve learned this past year.”
2. This will make you a better learner. Having a set time each week where you sit down and reflect on what you learned, and then sharing that with the world, helps you solidify that knowledge. It’s also very motivating to see other people engaged in the problems you’re working — it can give you the drive to keep going.

---

## 4. You Need a Personal Website

This is key. If you’re going to learn in public it’s a good idea to make a personal website that can give people one central place to view all the cool things you’re up to. This is also a great programming project, because it’s something that you can make as simple or as complicated as you want and once you finish it you can easily share it with the world.

*Bonus Tip: Don’t be a perfectionist when building your website. I’ve redone my website three times in three years and plan to redo it again in the near future. It’s more important to have a website than to have a perfect one.*

*I have some classmates who built theirs with plain HTML and it works great! I have professors whose websites are made in plain HTML. If you don’t have an interest in design, making it minimal and purely functional is a great path to take.*

---

## 5. Make Use of Student Perks!

Take advantage of all your student discounts! You can ride these discounts far and probably never have to pay for any cloud-hosting before you graduate. You can find these deals everywhere, but my favorite place to view student perks is [Github Student Developer Pack](https://education.github.com/pack). Some of my favorite deals from this:

- [$100 of AWS Credits for Cloud Services](https://aws.amazon.com/education/awseducate/)
- [Free GitHub Pro While a Student](https://education.github.com/pack)
- [Free Year of a NameCheap .me Domain Name](https://education.github.com/pack)
- [$50 of Free DigitalOcean Cloud Hosting](https://www.digitalocean.com/github-students/)
- [$200 of Free MongoDB Atlas Credits](https://www.mongodb.com/students)

---

## 6. Learn the Difference Between the Three Types of Computer Science Classes

The computer science major has three different types of classes. It’s important to know the difference between these because some of these areas may not be as interesting to you and that’s OK.

#### 1. Algorithm courses (for example: discrete math, finite automata, data structures)

These classes are what people are talking about when they say computer science has a lot of math in it. These classes are similar to math classes and teach you more about the theoretical side of computer science. They’ll teach you how to develop algorithms, how to write proofs, data structures, and more. If you love these classes they can be a path towards grad school, a PHD, teaching, or research fields.

#### 2. Hardware/low-level courses (for example: operating systems, computer networks, computer architecture)

These classes teach you what’s going on internally in a computer. You’ll learn things like CPU scheduling, networking, assembly programming, operating systems, and permissions. If you like these classes, this can lead you into a career doing computer engineering, robotics, or OS design.

#### 3. Programming courses (for example: software analysis and design, software engineering)

These courses will teach you how to write software. In these classes, you’ll learn object-oriented design, design patterns, databases, front end design, Git, project management, and more. If you like these classes, they can lead to a career in web design, game development, back end engineering, software engineering, and more. There are too many options to list.

All of these classes are important. You’ll find that the concepts of one will tie into another, so pay attention to everything. You might first be introduced to a hypothetical concept in your algorithms class (like big-O notation), then later see it cropping up in a programming class (For determining the best way to structure your SQL query). That’s typical and it’s the reason all these classes exist.

> *Bonus Tip: Don’t load up your schedule with too many of onetype of class in the same semester or you might get overwhelmed with too much of the same type of workload. This depends on the specific class, but it’s generally a good rule to follow.*

---

## 7. Complete Projects and Labs Early

Some courses can be *very* project-based. Each of my programming-focused courses had about eight labs and five or six projects of varying difficulty. This can be super stressful if you leave them to the last couple of days, especially considering you probably don’t know what you’re doing.

It helps to develop a pattern. I eventually got a pattern down of trying to complete projects the weekend before they were due — this helped a lot. This gives you the ability to step away and refresh your brain, then come back and tackle a problem later. I still do this today!

---

## 8. Learn the Command-Line
<Image src='https://cdn-images-1.medium.com/max/1440/1*ETG7ERNQg7pYz2aM1BAzqA.png' alt='' width='md' />
Mastering the Unix command-line is one of the most practical skills you can learn in college. You should learn how to create, edit and delete files, navigate directories, move files around, edit documents with vim, and shell into other computers. This might not seem like the most important thing to learn at the time, especially if you’re thinking “No but I don’t need a command-line for X”, but the fact is that everyone will need the command line to use Git repositories, ssh into your production environment, etc. It’s unavoidable.

---

## 9. Build a “Capstone Project” Each Semester

This has been my favorite way to work on my programming skills. After each semester when I’m on Christmas or summer break I’ll build a “Capstone Project” that solidifies everything I learned. This is a great way to stay in the habit of programming, build your resume, and build something that you actually want to use!

One of my favorites of these projects is my Spotify web app that lets me view my most listened-to tracks and artists:
<Image src='https://cdn-images-1.medium.com/max/1440/1*nHYTqQQhqdKcKS4IaK-25Q.png' alt='' width='md' caption='My Spotify Web App' />

Doing projects you’re interested in will mean you want to finish it. So my recommendation is to build something that *you* want to use. Even if it already exists, that doesn’t matter — just build what you would use.

---

## 10. Internships are Attainable

The job environment might be changing due to COVID, but trust me there will still be internships available. The key is to know where to find them and how to have the skills they’re looking for in candidates. If you do the other items on this list, such as learning in public, having a personal website, and building capstone projects, you’ll be an attractive intern no matter what year you are.

Here are some other tips I have for getting internships:

- Get out of the mindset that you’re not prepared for an internship. Everyone is still learning through college so let the companies be the judge of if you’re prepared or not — don’t make that decision for them.
- There are always internship opportunities popping up. I started applications around October last year and got an internship in November. Some students started even earlier. The summer before that I got my internship during finals week right before summer. New opportunities are popping up all the time, so constantly be on the lookout throughout the school year.
- Use state-funded internship boards if available. If you live in Minnesota, [https://scitechmn.org/](https://scitechmn.org/) is a great resource that I recommend. Local internship boards have a smaller competition pool and give you a more personal application process than something like Indeed.

---

### Thanks for Reading!

I hope you found this valuable. If you have any more tips please share them in the comments!


10 Non-Traditional Hacks for Incoming Computer Science Students


Google Firestore is Google’s propriety NoSQL Document-Based Database. Paired with the rest of the Firebase suite such as Cloud Functions, Firebase Auth and Firebase Storage this can look like a pretty attractive tech stack for startups or solo-developers looking to get an app up and running quickly.

This is exactly what I thought 9 months ago when choosing a tech stack for my mobile app. Firestore had some advantages that I was attracted to. It had a generous free tier, an auto-scaling NoSQL data model, and some sweet integrations with the other Firebase services. If you feel like you’re in this happy bubble with this technology now, here’s a word of advice…

**Make sure you’re aware of the downsides of Firestore.**

# The Three Big Reasons I Won’t Use Firestore Again
<Image src='https://miro.medium.com/max/922/1*rJUEljk7lNweBW1xYJ4llg.png' alt='' />
## 1. Proprietary Database

We’ve all heard the term “vendor lock-in”. Well, Firestore is the epitome of this idea. If you think this won’t be an issue because your product is simple or small, I’ll tell you right now that even with the simplest apps Firestore’s vendor lock-in creeps up. I experienced this when trying to do the simple task of a deploying a DEV and a PROD version of the database. This is a huge challenge with Firestore.

The first hurdle you run into is the fact that you can’t have multiple Firestore databases associated with a project. Therefore you have to create separate project-dev and project-prod projects. This isn’t too hard initially, and is probably a good design pattern in general, but now your development experience gets 2x as complex. Now you have to decide if you want each project to have a separate Firebase Auth, and what about cloud functions, or storage buckets, etc? And there’s no tools to automate any of this deployment, so if you want to just “copy over” your database data and functions and auth users to production, you have to do that manually. And even then, some of these operations can be done through the firebase CLI, but the more important ones like migrating data can’t be.

Assuming you get production and development environments setup, now you have 20 other issues that crop up. How do you do automated backups? How do you export data from one database to another in an automated way to refresh staging servers? How can you get a local version of this database running to test with? The answer to all these questions is that… it’s complicated. These more complicated use cases are hard to do because this database isn’t open source, so there’s no community around it making tools for these things.

Some of these issues aren’t unique to Firestore, but simply to any proprietary database vendor. This is why I’ll never choose a proprietary database again. There’s times to try out the latest and greatest thing, but when it comes to the integrity, security, and accessibility of your company’s most important asset (your data), I’d say 10 times out of 10 that it’s a better choice to use a solution that’s been battle-tested on open source.
<Image src='https://miro.medium.com/max/1260/1*qu4Fg1JKBNNeldmuIKCGxA.png' alt='' />
## 2. Firestore Optimizes for themselves. NOT you.

This part really annoyed me while using Firestore. It’s the fact that Firestore has two features that are consistently at ends with each other.

1. ***Firestore charges per document when you read/write to the database.***
2. ***Firestore’s querying abilities are very primitive, so more complicated filtering, sorting, or merging of data MUST be done client-side.***

This deadly combination means that if you have to do a more complicated query (which is almost unavoidable), you will need to **overfetch** the data, and then filter it in a Cloud Function or on the client-side before using it. This isn’t just wasteful on networking bandwidth and client-side processing time, but because of Firestore’s payment strategy it ends up costing you more money as-well. The biggest result I’ve seen from this is that

> It results in my database collections and available querying operations defining what features I implement into my product, rather than my customers deciding it.

Now I’m going to play devil’s advocate for a second because I understand why Firestore is setup this way. It’s because Firestore is built for one purpose. It’s built to make it **very difficult for you to write a bad query**. Almost every possible query you can make to Firestore is of O(1) complexity. This is great because it means your database processing time is short and clients are getting results very quickly. But…

Did you catch that?

Firestore is built to make processing cheap on the server-side. But guess what? You pay per document so whether a query takes 1ms or 100ms doesn’t matter to your wallet. This means that Firestore is optimizing to make **their** costs cheaper. Not yours. And since you have to overfetch data and manually filter it on the client side you actually end up with a more expensive and slower query overall. This is why I moved away from Firestore. After seeing that this was their business model, it proved to me that there’s no way I want to try to scale with this product.
<Image src='https://miro.medium.com/max/1260/1*mzf3gWnrIggMlDpClnjexw.png' alt='' />

## 3. A NoSQL Database Likely Isn’t Right For You

One thing that initially attracted me to Firestore was it’s NoSQL data model. There’s other options for NoSQL such as MongoDB or AWS DynamoDB, but Firestore provided a really nice auto-scaling out-of-the-box solution for me that I liked right away. Until I didn’t like it anymore.

You see, most data for the typical web or mobile application is going to be highly relational. A typical application will probably have users, as-well as things that relate to the users in some way. And these things likely relate to other things as-well. Etc, etc. And they might be viewed in a list, or indexed, or queried to see all the things that a user has created. For managing these basic use-cases, Firestore is okay, but once it gets more complicated Firestore breaks down.

The NoSQL solution to these problems includes things like data duplication, fan-out writes, etc. These principles take more development time to implement than having a SQL database to begin with. If you’re looking towards Firestore as a solution, you’re probably looking for something that saves development time, because that’s Firebase’s selling point, but Firestore is more akin to taking on time-debt that you have to pay off later. To illustrate some really painful hurdles I had to develop around I’ll give some quick examples from my project:

1. Users can create reviews. A user’s profile picture and username is attached to each review they create. This is needed because the frontend views a list of reviews. If we have to fetch all the reviews then make a second query for each review to get the user profile picture and username, then that 1 query now becomes N+1 queries. This is called the [N+1 problem](https://medium.com/@bretdoucette/n-1-queries-and-how-to-avoid-them-a12f02345be5). Then a user changes their name. Now you have to code a cloud function that notices that change and dynamically searches through every report (could be millions) and changes that user’s display name on each one that their old name is on. This is a lot of programming for something that in a SQL database would be a feature out-of-the-box.
2. Users need to choose a username when they sign up. I want to make sure two users don’t have the same username (ignoring capitalization). The solution to this problem in a Firestore NoSQL way? I had to add a lowercaseUsername field to every single user. When a user wants to change their username, it converts it to lowercase, then queries if it exists already and if not it changes their username. This is a total pain if your app is in production already, because backfilling every user document to add a lowercaseUsername field requires development time to write a single-use function to execute this migration. I found I had to backfill data all the time and eventually it just got too hard to work with.
3. Users can follow Trails. Trails can have multiple Users following them. This creates a many-to-many relationship between these objects. Managing this in Firestore was beyond tedious. It’s somewhat straightforward when you only have to think about creating data, but then you have to deal with updating and deleting it too creates a ton of complexity.

As you can see, there’s so many situations where a NoSQL database screws you up and causes a lot of development time-sink. SQL databases are very scalable and powerful now that they will serve your needs much better. And guess what? If you want the best of both worlds you can use BOTH. Put your relational database in a SQL database, and put your non-relational data (like the millions of live chat messages for example) in a NoSQL database and get the benefits of both with the tradeoffs of neither.

# Is Firestore Right for You?

I still like a couple things about Firestore. Their client SDK that managed client-side offline-support was convenient, and for querying simple data that’s non-relational in nature I would still **consider **it. But unless I know my project has a fixed completion date and won’t run into any of the limitations mentioned above, I can’t recommend it.

# So What’s The Alternative to Firestore?

If you’re like me and you enjoy getting the nested JSON response from your database, then you should consider using GraphQL. I switched to GraphQL paired with a SQL Database and found it to be the perfect balance where I get everything I liked from before in terms of easy querying, but then I still can query the database directly if I want to do something more involved. I also found that speed was still comparable, and I can add read-replicas if my database begins to slow down as it scales.

For other use cases, here are my recommendations:

If you want something that’s just an easy bucket to put data into then consider checking out something like Contentful: [https://www.contentful.com/](https://www.contentful.com/)

If you want something that gives you an easy-to-use open-source UI to make CRUD API’s on top of an open-source Postgres database, consider GraphQL with Hasura + Postgres: [https://hasura.io/](https://hasura.io/)

If you want a SQL database where you don’t have to deal with data duplication, but also don’t want to use GraphQL or manage database scaling, consider AWS Aurora: [https://aws.amazon.com/rds/aurora/](https://aws.amazon.com/rds/aurora/)


Why I Switched Away From Google Firestore – and don't regret it


Deno is a Javascript / TypeScript runtime looking to take the place of Node.js as the status quo. It boasts a wide slew of features and has a lot of hype around the project with almost 68,000 stars on Github:

<Image src='https://cdn-images-1.medium.com/max/1440/1*6xbphF6rGnRGUCDKY5C2Dw.png' alt='' width='md' caption='https://github.com/denoland/deno' />

With so many great features, the question to ask is:
> Why didn’t Deno take off when it released it’s official version 1.0?

This article looks to dive into that question.

## So, what’s Deno?

Deno is a secure JavaScript and TypeScript runtime created by Ryan Dahl (who’s also the original creator of Node.js). It was created [to fix some of the oversights made when first designing Node.js](https://www.youtube.com/watch?v=M3BM9TB-8yA) back in 2009. In my opinion this motivation makes a lot of sense because I’m sure every programmer would love to get a chance to rewrite their 10 year old code.

In this case, Deno boasts quite a few features over Node.js:

- Deno is secure by default. Access to the file system, network, or environment has to be opt-in
- Deno was built for TypeScript out of the box
- External files are explicitly referenced by a URL. No package.json.
- Import statements include file extensions (.ts,.tsx,.js,.json)
- Built-in dependency inspector and file formatter utilities
- [And more…](https://deno.land/)

And with these features in its arsenal combined with an enormous amount of developer hype, Deno had its official 1.0 release in May 2020.

And then…

*Crickets.*

## Why Didn’t Deno Take Off?

Deno looked like it had all the ingredients for success. It had a massive following, a solid batch of features, an experienced creator, and more, but it didn’t really have the growth everyone expected. Why is that?

I think it’s best to look at it from a business perspective. See, most of us forget that building open source software is really no different than building software for users. The standard economic principles of supply and demand still play a large role.

When someone is creating a new open source project, they’re typically going to be competing with something that already exists. With that in mind, you have to consider not only how good your new project is, but also what it looks like compared to what’s already available.

In Deno’s case, what was already available was Node.js, and while Node.js might have its flaws, it’s still very capable of doing its job. Now, if Deno came out with a blow-away feature that Node.js would never be able to replicate, that might change the game. But it didn’t.

Deno only really sported “minor features” from a users perspective. It had a cleaner codebase, used up-to-date best-practices, and had better security, but those things are really only “features” to a user, not a product in themselves. You could make an email client exactly like Gmail except it has better security and a 50% speed improvement, but users still wouldn’t switch to it because even the tiny amount of time it takes to create a new bookmark wouldn’t be worth it.

So that’s strike 1 against Deno: It has quite a few nice-to-have features, but there’s nothing standout that inspires users to switch away from Node.js.

The other major strike against Deno is that it doesn’t support NPM packages. If Deno were able to support NPM packages, that would change the game for them. Deno supporting NPM packages would make them much less of a “separate email client”, and more like a better wrapper around the current client.

Supporting NPM packages would greatly reduce the barrier to entry. It would act as a good stepping stone for users to migrate their projects and libraries towards Deno.

Think of it as similar to TypeScript’s “strict-mode”. For users with a huge codebase of JavaScript, jumping directly into TypeScript would cripple your productivity for weeks while you sort through all the error messages. Because TypeScript has the ability to disable strict mode, it can act as a stepping stone for users to slowly migrate over to pure TypeScript. This gives them a much lower barrier to entry, and in turn has [helped TypeScript rip away market share from JavaScript in recent years](http://pypl.github.io/PYPL.html).

---

## What’s the Takeaway?

I think this an interesting case-study that exemplifies a larger methodology in business. The takeaway is that if you’re going to release a new product into the market, you have to make sure it’s something where the upside is so great that it overcomes the resistance from people switching from the status quo.

In Deno’s case they had the initial allure, but when it came down to it Deno was really only offering a collection of small “fixes” at the price of losing the whole NPM ecosystem that Node.js had cultivated and this tipped the scales for them.

---

## Where does Deno go from here?

Well, they have a decision to make. They can either work on adding backwards compatibility to Node.js libraries, or they can increase their offering to make the compulsion to switch just that much more enticing. I personally think backwards compatibility is the way to go, and I think if that was added it would drastically alter the future of the project.

Either way, best of luck to the deno team and I hope the best technology wins in the end. I hope you enjoyed the article, thanks.
