Just a quick one on a mindset that I have been trying to apply to the things that I have been working on, or committing to, in 2024. The concept revolves around two requirements to meet when committing to a project/client/etc. Those two requirements are, the project either has to be interesting, whether that is interesting to work on, an interesting topic, or potentially an interesting technical challenge. Or, alternatively, but not mutually exclusive, would embarking on this project/collaboration/client engagement generate interest (ie. make money/margins) both in the short-term, but also potentially in the long-term or over time.

In a perfect world, the project(s) would both be very interesting, while also providing the potential to earn a healthy level of interest over time. At least, that is my goal with the personal projects that I am working on, and plan to work on in the future.

Another thought that comes out during this episode is some reflection on the debate of working on multiple things, or going all-in on a single project. I am of the mindset that the people going “all-in” on something are potentially leaving money and some optionality on the table when they abandon an existing user base to pursue a new niche customer market that no longer aligns with the initial product offering. A few questions that I have been debating as I hear people weigh-in on this topic are:

• Would potentially maintaining that existing product, while exploring a new target customer with an altered, or new product, really impact the success of the new initiative?
• Would maintaining the existing customers, even if growth is plateaued, allow for you to retain them and the current MRR while supporting the development of the new product?
• If the new initiative is not a success and you potentially want to re-engage with the previous customers that you abandoned, is there even a pathway back to your previous state?

I hope to be able to explore and play with some of these questions as I am building and growing the projects I am working on. And I look forward to sharing those insights and internal debates in future episodes of the show.

To follow along, you can find me at ryanhefner.com, follow me on Twitter @ryanhefner, and keep up with the show on allplay.fm and @allplayfm.

Help yourself, while supporting the show, by trying some of the services that I use, and highly recommend:
Transistor FM
Fathom Analytics

Reflecting on Laravel vs. React debate that went down a few weeks back, got me thinking about Context. Context switching. The context that influences the decisions we make. Really, just about context in general.

My focus has been to try to minimize the amount of context switching that I am doing, which is already difficult while managing multiple clients and trying to focus on my personal stuff. I get into some of those trade offs, along with a few other things that have been popping up that have been requiring additional context switching, resulting in ultimate flow wreckage.

Some references from the show:

• Inception this one to find the tweet that kicked off the Laravel vs. `react-remix` debate
• laravel-pwa / laravel-pwa-demo
• My service that has been getting DDOS’d, Link Cards

To follow along, you can find me at ryanhefner.com, follow me on Twitter @ryanhefner, and keep up with the show on allplay.fm and @allplayfm.

Help yourself, while supporting the show, by trying some of the services that I use, and highly recommend:
Transistor FM
Fathom Analytics

The struggle is real-ish. In this episode I get into the tension I have been feeling as I am in my -1 to 0 phase, trying to figure out which project/product I want to place my energy towards (first), and some of the technical stuff I plan on incorporating in the projects I am planning on taking on.

Some of those core technology areas include:

• Event Sourcing
• Progressive Web Apps (PWAs)
• Push Notifications
• Local-first development
• Embracing the open web
• WebAssembly (WASM)
• Performance

During the portion of the episode where I focus on local-first development, I make reference to a few podcasts that dig into the topic, the Muse Podcast and localfirst.fm.

I will be digging into the actual project that I will be sharing the evolution of on this project, so please subscribe and sign up for the newsletter for updates.

To follow along, you can find me at ryanhefner.com, follow me on Twitter @ryanhefner, and keep up with the show on allplay.fm and @allplayfm.

Help yourself, while supporting the show, by trying some of the services that I use, and highly recommend:
Transistor FM
Fathom Analytics

In this episode I reflect on officially hitting publish on this podcast. The steps that lead up to the release, along with all the excitement and anxiety that builds up before pressing that button.

From creating the cover art, to settling on the format—or lack there of—to writing descriptions, and deciding whether or not to pay the extra $5/month to Transistor for the AI Transcriptions feature vs. rolling my own (note, I just paid the $5, but may explore some other ideas with custom transcripts on the site, since after playing with the different output options it got the brain gears turnings). Basically, all the stuff that went into launching this.

Here are a few additional things that were on that launch list:

• Audio quality (via Adobe Audition + custom presets to make the audio sound better)
• Newsletter sign-up form
• Webhooks to refresh the site when new episodes are published
• Sitemap
• `og:image`’s

Along with some other outstanding stuff that I will be pushing to the site soon:

• Welcome email (for newsletter subscribers)
• Newsletters (sign up so you will start receiving these once they start going out)
• Standardize copy/words for how I reference what this is
• Tweak site metadata and SEO stuff

It definitely feels exciting to start seeing it in the various podcatcher sites and apps, and looking forward to talking about all the other stuff I have in the works. Until next time!

To follow along, you can find me at ryanhefner.com, follow me on Twitter @ryanhefner, and keep up with the show on allplay.fm and @allplayfm.

Help yourself, while supporting the show, by trying some of the services that I use, and highly recommend:
Transistor FM
Fathom Analytics

In this episode I dig into why I decided to build a custom site for this podcast vs. using one of the templated sites that TransistorFM offers. Part of it is based on some of my ideas about utilizing platforms to push traffic back to sites that you own. The other part of it was I just had an idea of what I wanted the site to look like, and how I wanted it to function, and I couldn’t suppress the urge from just building it myself.

I also explain how I plan to add a newsletter to the site as well, and you can sign up for at allplay.fm. I am currently using Resend to capture the subscribers, and will be using them for the newsletter delivery, but have some plans about how I will be doing that in a later episode.

In addition to the site, I get into some thoughts I am having about expanding the reach of the podcast—and really just personal stuff in general—and how potentially replicating that across a number of sites that all point back at the sites you own either help or hurt your own sites performance, or really where do people find it and when do they drop off?

And, I geek out about some of the Web Audio API and Audio Buffer stuff I am using on the site to use for audio playback and will be publishing the library I am using for that at a later time, and will have an episode about that when it happens.

References

• TransistorFM
• Nx
• Contentlayer
• allplay.transistor.fm
• Resend

To follow along, you can find me at ryanhefner.com, follow me on Twitter @ryanhefner, and keep up with the show on allplay.fm and @allplayfm.

Help yourself, while supporting the show, by trying some of the services that I use, and highly recommend:
Transistor FM
Fathom Analytics

tl;dr I am not going to be editing these episodes, so please bare with me.

Although, if you want me to reflect on it a bit more, there’s a reason for making the active choice to not edit these episodes. Part of that decision is based on efficiency, as I work through these episodes I am trying to take all the ideas swirling around in my head and pluck a single one that I can try to break down and pick apart within a quick 10 minutes—maybe a little more, or a little less. I could definitely try to get to that same time constraint by recording a bunch of material and whittling it down to fit the space required, but with that approach I feel like you lose all the nuance on the topic, and you don’t get to hear the gears grind through the topic. Also, recording 30 minutes or an hour of material and trying to edit it neatly into a 10 minute episode that sounds fluid and coherent sounds like a miserable task, that I both don’t have the patience, nor the time to take on.

So, please bare with me if I happen to misspeak or mispronounce a few things from time-to-time. I hope the core ideas ring through and you are still able to take away something. And, along those lines, I go into my OCD approach to listening to albums and podcasts, and recommend that if you do intend on listening to multiple episodes of this podcast, that you should try to do that from the earliest episode and listen until the current/last episode. Just a recommendation, you do you, but from my experience with other episodes, I will probably be referencing either ideas or projects from the past, or may even come up with some made up word that I reference from an earlier show, so listening to them chronologically will probably reduce the confusion level as those pop up.

To follow along, you can find me at ryanhefner.com, follow me on Twitter @ryanhefner, and keep up with the show on allplay.fm and @allplayfm.

Help yourself, while supporting the show, by trying some of the services that I use, and highly recommend:
Transistor FM
Fathom Analytics

CSS and component libraries, where to begin?

Over the years I have used a bunch of different flavors including, css-modules, styled-components, CSS + Sass and a few other things. But, over the last 3 years or so, I have been primarily using ChakraUI, which is a component library that offers a really nice way to setup your theme—based on styled-system—as well as control the styles and defaults of the components they offer, along with being able to build and style your own components, using the same system, all accessible via the main theme configuration.

But, since I am trying to shed the biases of the past, and explore all the new potentially new, hot stuff that could make my life in code potentially better, I decided to explore some of the new stuff that has been spinning out of the ChakraUI world, as well as some thoughts and questions I have about sticking with that world, or going all-in on Tailwind.

References

• CSS modules
• styled-components
• Sass
• PostCSS
• ChakraUI
• styled-system
• Emotion
• Panda CSS
• Ark UI
• Park UI
• Tailwind CSS
• Radix
• shadcn/ui

To follow along, you can find me at ryanhefner.com, follow me on Twitter @ryanhefner, and keep up with the show on allplay.fm and @allplayfm.

Help yourself, while supporting the show, by trying some of the services that I use, and highly recommend:
Transistor FM
Fathom Analytics

On this episodes I dig into getting back into action and picking a stack to base the action on. In the past, I have built my products and prototypes in Laravel, using an SPA—typically built in React—for the majority of stuff, and I go into all the pros, and a few of the cons, I have experienced with that setup along the way.

Well, now the year is 2024 and as easy as it would be go back to that trusty old cocktail of sorts, I want to push myself to explore something new. I go into how I have been structuring my latest work utilizing Nx for the monorepo setup, and primarily using React + Next for the majority of the client apps.

I love the DX surrounding some of these newer hosting platforms, allowing for instant previews of branches that are in the works, and being able to have as many of those up and running, and viewable, while working on a project. That coupled with the fact that I haven't been working on PHP for the last 4+ years and all the changes that have been going on, in both PHP and Laravel, I feel a little behind the curve in that ecosystem, and honestly I really just like working in Javascript and not having to deal with the context switching between PHP and Javascript.

So, with all that said, I am not wasting any more time on the debate and am going to go all-in—at least on this first project—on the all Javascript setup, utilizing Nx to manage the monorepo for the project. React + Next for both the marketing site and app, which will be two separate apps deployed on the same push, utilizing shared libraries within the repo. And, will be trying out NestJS for the API, because—for a number of reasons—I think that is the way to go vs. utilizing API routes via Next to try to accomplish the external API.

References

• Laravel
• Stripe
• Lemon Squeezy
• Paddle
• Laravel Pulse (the one I couldn't think of)
• Laravel Reverb
• Next
• Vercel
• Render
• Netlify
• Laravel Shift
• Nx
• NestJS

To follow along, you can find me at ryanhefner.com, follow me on Twitter @ryanhefner, and keep up with the show on allplay.fm and onTwitter @allplayfm.

Help yourself, while supporting the show, by trying some of the services that I use, and highly recommend:
Transistor FM
Fathom Analytics