Skye Freeman

How I'm using LLM's via Emacs

2026-04-15T04:20:25Z

The advent of LLM's and the subsequent explosion of developer tools for interfacing with them has made being an Emacs user better than ever. Since Emacs can be molded into whatever you want it to be, the latest agentic tooling can be grafted into Emacs and integrated into your workflow with little ceremony.

I've experimented with a number of LLM + Emacs integrations over the past 3 years. First, starting out with ChatGPT usage through chatgpt-shell, then moving on to the claude-code Emacs package. I eventually built out my own terminal based setup by firing up agents through vterm.

Now, I've consolidated down to two lean configurations based on the Emacs packages agent-shell and gptel.

agent-shell

The agent-shell Emacs package has become my daily driver for most workflows. It's a major mode for interfacing with terminal based agent interfaces. agent-shell supports all the major model providers and versions, and abstracts away enough of the differences so that swapping between them is as simple as configuring an API key.

My preferred method of configuration is via "use-package", here's a lean example configuration:

(use-package agent-shell
    :ensure t
    :vc (:url "https://github.com/xenodium/agent-shell" :rev :newest)
    :ensure-system-package
    ((claude . "brew install claude-code")
     (claude-agent-acp . "npm install -g @zed-industries/claude-agent-acp")
     (codex . "brew install codex")
     (codex-agent-acp . "npm install -g @zed-industries/codex-acp")
    )
    :custom
    ((agent-shell-anthropic-authentication
      (agent-shell-anthropic-make-authentication
       :api-key (string-trim
                 (shell-command-to-string "$SHELL --login -c 'echo $ANTHROPIC_API_KEY'"))))

     (agent-shell-openai-authentication
      (agent-shell-openai-make-authentication
       :api-key (string-trim
                 (shell-command-to-string "$SHELL --login -c 'echo $OPENAI_API_KEY'"))))
                 
     (agent-shell-anthropic-claude-acp-command
      '("claude-agent-acp" "--dangerously-skip-permissions"))
     )
    :bind (:map agent-shell-mode-map
                ("C-<tab>" . nil)))

This config handles API key integrations for both Codex and Claude Code, and ensures external dependencies are installed on the system. This little tidbit:

(agent-shell-anthropic-claude-acp-command
      '("claude-agent-acp" "--dangerously-skip-permissions"))

overrides the default "claude-agent-acp" command to include the "--dangerously-skip-permissions flag" when starting the agent.

Start a new session with the interactive function "M-x agent-shell", you're then prompted to choose between the following supported model providers:

Claude Code
Codex
Auggie
Copilot
Cursor
Droid
Gemini CLI
Goose
Mistral Vibe
OpenCode
Pi
Qwen Code

agent-shell buffers are name-spaced using a string format of the current directory and model name. For example, starting a Claude Code session while located in the folder "~/dev/skyefreeman.com", will result in a new agent-shell buffer named: "Claude Code Agent @ skyefreeman.com". This means that switching between concurrent sessions is the same as swapping between Emacs buffers using one of the many built-in buffer switching functions:

M-x switch-to-buffer
M-x counsel-switch-buffer

Since spinning up new agents has become so common in my workflow, I've bound starting a new agent to the coveted "Command-return" key combo, which starts a new session with one keystroke:

(global-set-key (kbd "<s-return>") 
      'agent-shell-anthropic-start-claude-code)

gptel

gptel is another generic interface to LLM's, but with a very different interaction style when compared with agent-shell. At its core, it's a huge library of functions and integrations for building LLM's into your Emacs workflow.

While most other LLM integrations prescribe to a "chat style" user interface, gptel instead is designed to be as free form as possible, enabling querying a model using any text within Emacs, and allowing responses to be redirected to whichever buffer you want. This enables a tight integration with Emacs.

For my use cases, I typically utilize the built-in "M-x gptel" function, which I have hooked up to automatically pop open an org file with Gemini pre-configured. The whole buffer then becomes my chat interface. Here's what this looks like in practice:

Querying Gemini using gtpel

Sending text to a model can be invoked using the interactive function "M-x gptel-send" Which is bound to "C-c return", while gptel-mode is active.

I usually use these sessions for quick look ups, documentation, or one off requests that don't require access to the filesystem or repo. It's fast, efficient, cheap, and enables quick iteration that can be easily saved or archived, given it's all just text within the confines of Emacs.

Here's what a simple gptel configuration looks like, again with use-package:

(use-package gptel
  :ensure t
  :vc (:url "https://github.com/karthink/gptel" :rev :newest)
  :custom
  (gptel-api-key
   (string-trim
    (shell-command-to-string "$SHELL --login -c 'echo $OPENAI_API_KEY'")))
  :config
  
  (setq gptel-backend (gptel-make-gemini "Gemini"
                        :key (string-trim
                              (shell-command-to-string "$SHELL --login -c 'echo $GEMINI_API_KEY'"))
                        :stream t))
  (setq gptel-model 'gemini-2.5-flash))

Similar to agent-shell, I've bound the creation of new gptel buffers to a global hotkey. The only difference is that I prefer to have these be sub-windows that I call "drawers". These drawers can be popped open and closed quickly as needed with a single key stroke:

(defun create-drawer-window (buffer-name &optional focus height mode)
  (split-window-vertically (if height height -10))
  (other-window 1)
  (let ((buf (switch-to-buffer buffer-name)))
    (if (not focus) (other-window -1))
    (with-current-buffer buf
      (if mode
          (funcall mode)))
    buf))

(defun skye/toggle-gptel-drawer ()
  (interactive)
  (let ((buffer (gptel "*gpt*")))
    (if (string-equal (buffer-name buffer) (buffer-name (current-buffer)))
	(delete-window)
      (create-drawer-window (buffer-name buffer) t -20))))

(global-set-key (kbd "<M-return>") 'skye/toggle-gptel-drawer)

Summary

I'm happy with this streamlined setup so far. It's changed a lot over the past year, but the combination of agent-shell and gptel provides a level of customization that is absolutely required as an Emacs user.

Journal Entry

2026-04-14T17:38:48Z

Sitting on the porch in the Berkshires, it's 1pm. Pluto is laying out on the coffee table, tired after two days of hiking. Ran 10 miles this morning, Up our driveway, along the main road, down to the farm and back. Stopped to say hello to the guard dog next to the chicken coop. He's all grown up now.

Going to take my father out for lunch shortly, we'll probably find a place to get veggie burgers. Going to make a point to not drink anything (doing a full detox). Last day in the woods before I head back to the city.

Trying to organize all of my thoughts. Yesterday, I added an "Ideas" database column and corresponding page on the website. My thinking is this: I have a decade of random thoughts, ideas, and questions spread out amongst my computer, phone, and notebooks. Ideas for apps, businesses, software tools, automations, things to learn. Some of them I tackle eventually, but most I rarely revisit.

What I want is to centralize all of these fragmented thoughts, categorize them, and figure out a systematic way to turn these thoughts into action.

For now, the ideas index is sparse. It will be free form, and might not always make sense to others. But I plan to add a tagging system to group ideas into clusters to find patterns on which ideas I consistently revisit. Then, I'll add a way to label whether an idea was "acted upon" (I.E, a URL to the output of that idea: a blog post, software package, or other).

Journal Entry

2026-04-14T04:11:54Z

Sitting on the couch outside on the porch in the Berkshires. Nicer outside today, mid 60's, cloudy, a little windy. Looking out upon the meadow, birds chirping. It's 4pm.

Just returned from a 45 minute hike with Pluto. He jumped in the stream, laid down in the mud, and chased sticks. It was peaceful.

This morning I took my father to breakfast. French Toast with a side of Scrambled Eggs, and a Cappuccino. We chatted for an hour about his living situation, his health. It's nice to have some time with him, albeit brief.

Watching a loved one age is both a privilege and a heart-wrenching ordeal. On the one hand, we're lucky to be alive, to have each other, to have made it this far. To have our limbs, minds, hearts and souls. But on the other, enough time has passed that the relationship has changed. The realities of deteriorating health and mental state are apparent in every interaction. What was once simple is now difficult, and the mind resists that some doors in life are now closed forever.

Journal Entry

2026-04-12T17:27:01Z

Sitting in the living room in the Berkshires, in the chair by the fireplace. Ran 9 miles this morning after waking up at 7:30am, groggy and tired. Trying to dial my circadian clock back to a normal cadence. My sleep schedule has gotten completely untethered from the norm. Re-inserting some level of discipline, isolating in the woods for a moment from social pressures and city life is helping so far.

Went to the general store for brunch (breakfast burrito, lemon bundt cake, latte). Ate while reading This Is For Everyone, by Tim Berners-Lee. It's fascinating to hear a blow-by-blow recount of the founding days of the World Wide Web. Currently at the part where Tim recalls the creation of the "Cookie" at Netscape, which originally solved the problem of individual web pages lacking a cohesive memory system (this of course, turned into a tool used by advertisers for tracking). Would recommend the book so far.

Trying to enjoy my last week of funemployment before I start a new job (I'm very excited! But more on that later). I'm focusing on breathing, stretching, and practicing gratitude. My primary goal right is to spend as much time as possible outside, listening to the sounds of life without headphones on, reconnecting with my thoughts unencumbered by noise and outside influence.

I'm going to be doing some thinking and writing today, hike in the afternoon with Pluto, then playing guitar in the evening. Maybe I'll learn to play a new song.

Journal Entry

2026-04-11T21:58:55Z

Sitting in the kitchen in the Berkshires. Looking out upon the meadow. Coffee and granola, 11:30 am. It's cold and windy today, albeit sunny. Pluto is sitting by the front door eagerly awaiting Julia (she is not on the way). Listening to Rubber Soul. Even when it's pre-bloom in Spring, it's beautiful here. Tranquil, quiet. Room to think.

Last night I downloaded Transcribe!, a program for music listening and transcription that is widely recommended. Picked out the bass and melody to the song "Return to Hot Chicken", which seemed like a good place to start. The inspiration for this was this post by Jake Worth last week. In summary:

Find a song you like (start out on the easy side). You'll need a downloaded file, no streaming.
Drag the song into Transcribe! which includes tools for slowing down and looping sections of the track. Use the built-in tone generator to help find the notes.
Work through each section of the song, listening closely and experimenting with your guitar to find each note on the fretboard. Figure out what the guitar player is doing, but also find the bass notes, the rhythm section, even the vocal melodies.
Write it all down in a tab, by hand.
After you have enough of the sections of the song down, put the song into a playlist called "Guitar Practice". This is now part of your repertoire of songs to practice to!

What I love about this practice methodology is that it's practical. The barrier to entry is this: Find the first note of the song. Then the next, then the next. Continue until you have the whole piece accounted for. This trains your ear, your knowledge of the fretboard, and most importantly: it teaches you how to use the guitar to play music.

FlyerFalcon: next steps.

2023-11-10T00:00:00Z

Searching for the largest bang for my buck of what to spend time on next for FlyerFalcon. I’m at a fork in the road, where I could do more product work, or I could create web pages to get more traffic.

My plan was to work through a “features” page (which I finished yesterday), write snippets about everything the product offers, then create subpages that go into more depth about each topic. All in the name of keyword ranking, of course.

On the other hand I could do some product work, which is infinitely more fun, and is sorely needed. While the flyer builder works well enough, it’s got some rough edges. Plus, it desperately needs more flyer template options. The existing options (built for the MVP) are plain white, text only, with tabs + QR Codes.

The typography and layout from these templates are a step up from opening up a word doc and just throwing something together to hang around your neighborhood. Nothing wrong with this approach of course – heck, tons of folks seem to be doing just that to advertise their HandyMan or Moving services in lower Manhattan. It works for the right folks.

This is the exact usecase for FlyerFalcon. Aim to make it as easy to create flyers as writing a Google doc, combined with eye-catching and attractive premade templates for folks with zero interest in designing themselves. For a hyper-focused niche – like paper flyer creation for dog walking service businesses.

Bleh, it’s like I’m talking myself into doing product work. But I’m taking this as a sign that I should be marketing instead, since my engineering brain will always choose “build moar stuf”, over “find customers”, any day of the week. New mantra: When in doubt, just do marketing.

My experience so far with the Phoenix web framework

2023-11-09T00:00:00Z

Yesterday I briefly mention that the first draft of FlyerFalcon’s feature page was done.

Created Image Assets

Picking up from there. Today, I spent several hours with my design cap on creating image assets to place alongside feature containers. They turned out better than I thought they would. Here’s the final product:

FlyerFalcon’s feature page, in all of it’s glory.

To be honest, the first section (flyer templates) stands out like a sore thumb. At some point I’ll swap it out for something better, but I’ll hold off until I have some better looking templates, as “premade flyer templates” are FlyerFalcon’s biggest selling point. I’d like to do it justice.

Fixed Meta Titles

Additionally, I noticed that FlyerFalcon currenly has 300+ duplicate title meta tags, most of which are programmatic SEO pages, but a few were top level pages that are essential for keyword ranking. I spent some extra time making these easier to manage with my HTML templating engine: HEEx: HTML Embedded Elixir.

There was a tiny bit of complexity, given some pages render via HTTP, and others render through a Phoenix LiveView websocket. But generally it was a simple update, ensuring that a :page title variable was set before render. HEEx makes this very straightforward, and relatively seamless accross both HTTP and a LiveView websocket.

Phoenix is all it’s cracked up to be

I’ve generally avoided talking about Phoenix (the Elixir web framework) since I started using it 6 months ago. Partly because I wanted time to explore it and see how it feels building a real world project. In short, it’s pragmatic, productive, and powerful.

I’ve had several starts and stops with various web frameworks over the years. Having spent a little bit of time with Rails, Django and Caveman2 (via the Common Lisp ecosystem), Phoenix is my favorite by far.

It toes that fragile line between “too much magic” and “too barebones”. It gets you started quickly with a fully fledged generator system (I actually wish there were more granular generator options, the existing ones generate a lot of boilerplate), then provides all the bells and whistles for deployment, authentication, routing, dynamic HTML rendering, static asset bundling, out of the box.

But I haven’t mentioned the best part: It’s fully loaded for _real time__ applications, and makes it laughably easy to build web apps with real-time features.

Jumping between serving a web page built with Phoenix LiveView and a traditional HTTP request is inconsequential, and the developer ergonomics of the framework are thoroughly designed to keep your mind on the server.

The ramifications of this I’m still coming to terms with, and can resoundingly say that it makes me far more productive. Heck, I haven’t even discussed how nice of a language Elixir is yet, and the lengths it goes to make parallel computing simple. But that’s for another day.

Frustrations with Modern Computing

2023-11-08T00:00:00Z

The first draft of flyerfalcon.com/features is done. Copy is fine, will probably tinker with it more in the future, but trying not to spin my wheels too much.

Tomorrow I’ll be creating some images to place above feature paragraphs. The existing sections feel bland, and definitely need visuals to help grab attention.

In terms of moral, felt very unproductive today. I’ve noticed steep drops in energy after two intense work days. Wondering whether I need to cut myself off at a certain point on productive days, or if I need to bake in more dedicated rest between long sessions.

Third option, reduce distractions while working. At least 30% of my time while I’m coding or writing is spent procrastinating, usually reading Hacker News or The Times.

Sometimes it sucks that the same device needed to create, is also the most powerful distraction machine that has ever been devised in the known universe. I guess this sums up my love hate relationship with modern computing.

FlyerFalcon: Building feature pages

2023-11-08T00:00:00Z

Earlier today I discussed the short-term content creation plan that I have for FlyerFalcon. My goal is to provide a foundational set of webpages that thoroughly signal what problems are solved and the value of what’s being provided – for both potential customers and search engines.

You see, this is my first foray into search engine optimization and trying to capture known web traffic with a solution to a problem that I hope people will pay for. I’ve found the fish, I just need to build the net.

Today, I got an in-progress aggregate feature page in place, which lists everything that FlyerFalcon does, and for each feature, links to a dedicated page that goes discusses it in depth. This gives me much more real-estate to build more organic keywords, increasing the surface area of terms that I could rank for in search engines.

When hyper-specific search queries like “paper flyer maker with qr codes” show up, I’ll be there, ready and waiting with a page dedicated completely to how FlyerFalcon includes a QR generator as part of the flyer creation process.

Or the phrase “tear off tabs paper flyer”, oh yeah, we got flyer templates for that too, it’ll take 5 seconds to make one.

I’ll finish up that /features page tomorrow, then get started on the /features/* subpages.

FlyerFalcon: A Marketing Plan

2023-11-07T00:00:00Z

A few weeks back, I spoke about a new project that I’ve been working on called FlyerFalcon. I’d like to discuss how I’m thinking about product development these days, and how this new project fits into my overall business architecture.

Why I’m working on FlyerFalcon

So, FlyerFalcon is the first serious “web app” that I’ve built, rather beyond a traditional website. Part of the allure of this project is to learn some new tech (Elixir + Phoenix + LiveView is just so dang cool), and experiment with some things I’ve learned around SEO and capturing web traffic. It’s every bit a bootcamp in marketing as it is for learning Phoenix.

The other part of this project is that it’s not iOS. I’ve built and maintained so many iOS apps over the past 11 years that I just needed a break. I’m not leaving forever, on the contrary Swift Starter Kits just had its best month on record having finally ranked first on Google for the keyword “SwiftUI Starter Kit”. Taking a break from the project has been good I think. Around June of this year I just felt as if I was spinning my wheels on it, having built and rebuilt the kit into a totally different thing 3 times once I had user feedback.

I made a lot of mistakes working on Swift Starter Kits: building a product before validating the idea, thinking about marketing after building a product, etc. Once I started to think about how to actually market it (hot take: “building in public” isn’t an actual marketing strategy), I realized I built a thing that people weren’t really looking for. At least not in the volumes that are needed to be self-sustaining.

Swift Starter Kits Marketing Improvements

To reiterate, I’m not giving up on Swift Starter Kits, it has better sales now than it did 6 months ago, and I’ve learned a ton about marketing in the interim that I’d like to incorporate back into the existing marketing site. Things like:

Slightly rework the landing page copy to tell a better story, and talk to the pain points it solves, rather than the unordered grab bag of features it currently upsells.
Use the positive user feedback as testimonials.
Adding a web page for every feature included with the kit to rank for new SEO terms.
Bring back the Firebase authentication kit that was effectively version 0 and gave away for free (which I subsequently removed in a full pivot to SwiftUI). In hindsite, this kit was a terrific lead generator, and gained more emails in 1 month than I’ve gotten in the 8 months since removing it.
Write an automated email nurturing and sales campaign, targetting users who downloaded the free kit, but haven’t upgraded to the licensed version.

A good week of work on it will pay dividends, I think.

FlyerFalcon’s Short term goals

But, in the meantime I’m not quite ready to shift gears away from FlyerFalcon. It’s up, it’s working, and I’ve spent the last few weeks chipping away at writing pages dedicated to marketing the product. To date, I’ve generated programmatic versions of landing pages for roughly 200 search terms, variants of the default landing page, but tailored to a specific long tail of keywords that show niche buying intent. Additionally, I published ~20 blog posts about “how to create a flyer”, specific to several industry verticals. These are a little “click-baity”, but I’m interested to see whether they result in traffic.

In a similar fashion, I have a pretty long list of articles to get through on my intended site map. These are my immediate focus:

/features/* pages, detailing every individual thing that FlyerFalcon does that provides value.
/alternative-to/* pages, detailing how FlyerFalcon is different than key competitors, and specializes in solving the single problem of “local advertisement using paper flyers”.
/templates/* pages, which will have a dedicated page with images and descriptions for every template FlyerFalcon offers.
/examples/* pages, which will aggregate example output of all generated templates, but for specific use cases.
/how-it-works page, which will give a detailed walk through of how the product functions. Content from this page I’ll reuse on the main landing page.
/flyer-marketing, will be a complete guide on how to effectively market with paper flyers, where to put them, what to avoid, etc.

Perfectionism is a Bootstrapper's Worst Nightmare

2023-11-06T00:00:00Z

I took most of last week off, which was much needed to clear my head. My wife and I walked on a beach, ran our dog around, and dreamed about our future. I always underestimate how useful taking a couple of days off is, to recalibrate and plot a new course of action.

I’ve been feeling pretty burnt out. Not because I don’t love what I do, but because I just care so darn much. In the transition from a “programmer” to a “founder” (both labels that I don’t really think capture what it is that I do) I’ve noticed this specific personality trait the hardest to overcome. Put bluntly, this is perfectionism.

As an employed software developer, stressing those tiny details is generally a good thing. Those nuanced decisions that we make during the construction of software are occasionally the difference between shipping on time, and woefully late.

But, as a bootstrapped founder there are just too many things to do. If we try and do everything perfectly, we’re going to be in for a bad time. If you’re wearing all the hats, and you probably are only truly qualified to wear one, two at the most, then you just need to keep moving. All those details don’t really matter that much.

The reality is that there are several forks in the road at any time, for any decision a bootstrapper must make. Mapping out a marketing strategy, developing a product plan, designing, engineering, measuring.

The grind of planning, building, and most importantly, trying and failing to stay positive, wears on you. The “staying positive” part is key, because let me tell you, there are times that suck, and it’s pretty easy to look over the hedge and see your old colleagues still making a fortune at your previous employer, and thinking to yourself: “why am I doing this again?”.

FlyerFalcon: I started building something new

2023-10-27T00:00:00Z

In August I started building something new. It started as a small side project while learning a new stack (Elixir + Phoenix, more about this another time), but has turned into much more. It’s called FlyerFalcon, and aims to be the easiest way to generate paper business flyers for promoting businesses, services or events – locally.

I haven’t spoken about FlyerFalcon at all so far, mainly because it’s so out of left field for me. Using a new stack, in a field that I have no experience in (local advertising), for customers that I haven’t served before (small businesses). This is why I’m so excited about it – it’s a totally fresh start.

I’ve approached development of this product totally different than past projects. Previously, I let my programmer brain dominate all sources of rhyme or reason when building products. Where possible, following the fun and interesting, and ignoring the boring and mundane. Turns out that the boring and mundane (at least for me) are actually the most essential parts of building a software business.

For FlyerFalcon, the idea came from keyword research. I wanted to formulate a solution to a problem that I had concrete proof that people were searching for. That showed evidence of a long tail of keyword variants that prove niche buying intent, and would provide a consistent avenue of traffic if captured.

Put another way, I’m building FlyerFalcon around a pre-formulated marketing strategy, and testing out data driven approaches to capturing that traffic and converting it into customers.

Wild idea, I know. 12 years in the software industry and I’m just learning about all of this.

Things you shouldn't do when building a startup

2023-07-27T00:00:00Z

Here are some things that you shouldn’t do when building an internet startup:

Completely rebuild your marketing page when you have meaningful web traffic

So yeah, this one is self explanatory. Swift Starter Kits went through several product phases, each time pivoting the product and its messaging to reduce scope and increase focus. The biggest marketing page rework was in March, when search traffic had surpassed thousands of visits per month (small, but a meaningful uptick). This was when I removed Firebase as a dependency and stopped marketing the kit as being a “Firebase enabled iOS starter kit”, instead focusing on subscription revenue tooling and a faster out of the box experience.

Turns out most of the Swift Starter Kits site traffic was looking for a Firebase enabled starter kit, traffic has gone down to the lower hundreds /month as of July.

Change the product’s name

This change was subtle, but around April I went through all of the Swift Starter Kits web pages, and changed every reference of “SwiftStarterKits” to “Swift Starter Kits”. This actually may have been a good move, but time will tell.

My thinking was this: If somebody is searching for the term “SwiftStarterKits” (one word, no spaces), they already know what they are looking for and the domain will rank for this automatically. But changing all URL references over to “Swift Starter Kits” (3 words, with spaces) makes clear the intent that this is an actual query that I’d like to rank for. I want the site to broadcast “hey, if you’re looking for a starter kit for Swift and SwiftUI, you may want what I built”. This was the entire idea around the domain name Swift Starter Kits in the first place.

What’s interesting though, is that while traffic has decreased overall, Swift Starter Kits now ranks in the top three for “Swift Starter Kit” and “Swift Starter Kits”, which it wasn’t before.

Learn about The Long Tail after building a product

Tongue in cheek aside. I read The Long Tail in April, after reading about its insights from patio11’s treasure trove of startup essay’s (seriously, if you’re serious about building internet startups and want to learn about internet marketing, you should start at the beginning of his journey in the early 2010’s and print every blog post onto physical paper, and read until you’re done).

The gist is that I learned about all the things I did wrong in ideating and building the Swift Starter Kits product. I built a product that I assumed somebody out there needed, but had no data to back this up. Then I learned about search keywords, SEO, and finding “Long Tail” keywords to enable focus on niche traffic. Once learning about all of this, I took a step back and thought “shoot, I have a product that doesn’t allow me to generate content for any of these queries”.

Looking around at keywords that are super close to what I had been ranking for, there were much better choices that get a lot more traffic – but would require a slight product rework to ensure I wasn’t lying about what Swift Starter Kits does.

So, the lesson is this: Have a general idea for how a product will fit into search engine queries before hand. Search engine traffic takes months to materialize and underutilizing 100 hours of product work sucks.

Improving my sales funnel with product usage videos

2023-06-07T00:00:00Z

Today I splurged and bought a license for a video recording/editing tool called Screen Studio. It aims to make video creation from content recorded from the desktop, easier. So far, I haven’t been disappointed!

The learning curve was minimal, and after a few attempts at recording a screengrab with properly timed cursor gestures I was able to make something that looked passable.

Why did I spend $89 bucks of my startup money on screen recording software? Because I’ve come to the conclusion that Swift Starter Kits needs proper product usage videos to improve the sales funnel.

Default screen recordings look boring, and I don’t have much video editing experience to make it look tight on a time budget. I see an $89 spend on video recording tools being a good investment, both for time and for increasing the quality of my sales pitch.

After all, why would you part with your hard earned cash without seeing exactly the software you’re buying in action?

Minimizing product scope, focusing on product improvement

2023-06-06T00:00:00Z

It’s been a couple of week since my last update. I’ve had my head down working through an extensive ideation phase for the next Swift Starter Kits release, implementing a far more focused and featured foundation for new apps.

Throughout the process, my thinking has changed about what this project needs to be. The previous two releases each had a different focus, starting with an authentication revamp of the kit using Firebase, to a fully modularized component kit acting as a TestFlight demo and UI test bed.

I’ve since done an about face, ripping out all dependencies and rethinking my strategy.

The first time customer experience of Swift Starter Kits is slow and cumbersome, requiring two large external SDK integrations. Once those are set up, you’ll be dealing with Firebase bloat…forever.

I was sick of it. I want something minimal, without throwing away all the work I’ve done until now.

A few weeks later, the experience is head and shoulders better than it used to be. The kit is now offline first, modular, and focused on native utility experiences. All the authentication, login, signup screens still exist, but users can pull them in as needed when the usecase is right.

The largest conceptual difference to this kit iteration is focus on being “offline first”. I aim to provide a feature complete toolkit that stores data locally, that can be wrapped with API calls as needed. Things are simpler, and focused on integrating individual SwiftUI screens in a cohesive architecture.

Here’s what’s left for this upcoming release:

Updating marketing page copy to reflect the new experience.
Recording product videos (This was long overdue).
Update S3 package download link.

Fixing LCP and reducing vendor dependencies

2023-05-15T00:00:00Z

Between Tears of the Kingdom sessions (which is flippin’ amazing), I managed to get some work done on the Swift Starter Kits landing page.

First, I updated the pricing section layout and colors, making styling a bit more uniform. Raised the price of the Team license, and added a higher tier with paid support + training.

Separately, I learned that my LCP (Largest Contentful Paint) was really really bad on mobile devices. I didn’t know this was a thing, and was potentially hurting search rankings.

Turns out my LCP was slow for two reasons:

A 3rd party JS library was blocking the main thread for ~2 seconds at initial load. I removed this for now (unfortunately, this tool was for support chat, I’ll need to find another provider).
The custom font download from the CDN was blocking initial render. I fixed this by ensuring a default font shows initially, then updates to the main font once it downloads asynchronously. I thought it was doing that already, but oh well.

Back to 100% search indexing health (supposedly), curious how long it will take to increase traffic numbers.

Subscription Starter Kit: Initial App Layout and SwiftUI Navigation

2023-05-09T00:00:00Z

With the planning and ideation done, I’ve set to work on an iOS starter kit that will provide all of the infrastructure needed for a cloud enabled, subscription ready native app with reusable foundational features.

To have a concrete usecase in mind while building this generalized kit, I’ve decided to build a cloud enabled todo list app. Afterwards I’ll work backwards and remove app specific logic and UI, getting the kit ready for your projects.

Starting with building the basic screen structure and navigation controls, this app will have two primary flows, “home” and “settings”. Settings is modally presented via the SFSymbols “gear” icon:

Your browser does not support video playback.

Simple enough.

Next, I threw together some generalized SwiftUI components to mimic the layout of a NavigationLink, ensuring selection logic is untethered to a navigation stack. Here I’ve stubbed out these initial section row inside a SwiftUI List:

Settings list controls for company info and support url’s.

Extending some interactivity to the Settings page, all of the existing cells either trigger a modally presented view, or push a view onto the navigation stack:

Your browser does not support video playback.

Great, first steps out of the way.

Next Steps

Each iteration of Swift Starter Kits has brought focus to the toolkit. Starting with the authentication and Firebase integration last year, I’ve slowly improved and expanded the foundation, making it more robust and generalized. The negative side-effect of this approach was lack of focus, but this product release is going to address this exact problem.

I’ll be focusing next on getting app functionality in place, followed by a bunch more settings, debug, and infrastructure additions.

Subscription Starter Kit: A minimal SwiftUI boilerplate with in-app subscription capabilities

2023-05-05T00:00:00Z

I’ve been thinking a lot about the next step to take for SwiftStarterKits product work. Tons of ideas, but limited time for execution. I want to make sure continuous investment in the product line is time well spent.

Up until now, I’ve written a fair amount of general purpose interface and infrastructure code, but nothing hyper focused on a specific type of app or problem set. In thinking about this more, I’ve slowly pivoted to focusing on building “native app infrastructure for subscription business models”, which is a concrete solution to a concrete problem, although it’s still a “meta” app idea (selling software to help write a specific type of software faster).

Looking around at the mobile app landscape, there’s a massive ecosystem of applications that are focused on solving a single problem extremely well. These apps take heavy inspiration from Apple’s design guidelines (for good reason), and provide their promised value in exchange for an affordable monthly/yearly/lifetime fee. For an indie, this simplified view of consumer facing software is a great place to start carving out your niche.

If I were to build a set of tools for starting an indie app shop, I would need to provide solutions to several problems:

Create a default experience that fully embraces the platform. It makes no sense to build natively unless you strive to provide a great platform native experience.
Reduce time to market of new native app ideas. Building natively for macOS and iOS is a niche skillset that is expensive to hire for, and time consuming to build for.
Provide implementations for essential components. Most infrastructure is redundant between apps.

Maybe you can see where I’m headed with this.

Building a toolchain for problem focused iOS subscription apps

In my last post, I threw together a proof of concept in-app purchase subscription flow using some existing SwiftStarterKits UI and RevenueCat.

Simple enough, but that’s just part one. Expanding from this new point of view, I’m going to be building out a minimal albeit practical foundation for quickly going from “idea to shipped”. Complete with subscription revenue capabilities, analytics, cloud storage, push notifications, onboarding, changelog, localization, accessibility.

Rather then shipping an MVP and working backwards to integrate with the platform, I want to flip it around and provide a deep OS integration from the start. Plus some bells and whistles for building a revenue generating software asset.

Faster project creation with code generation

Also, code generation!

I have several code generation tools that I’ve utilized in the past for personal and professional use. I’ve meant to integrate them into SwiftStarterKits, but I needed the proper selling point to really accentuate it’s value.

When I refer to code generation here, I don’t mean macros or compile time meta programming facilities (at least for now). Instead, I want to make generating a fresh project part of the SwiftStarterKits onboarding experience.

A messy problem right now is that I’m selling just a single giant codebase. There are several starting points, and even a demo integration of all the screens and flows. But the initial experience as a customer is to dig around, get it running, play with it, then decide what to throw away or change.

For most new apps, you’ll probably spend a lot of time deleting or changing the core navigation to ignore certain flows, or turn off compilation for things you don’t need. This experience kind of sucks, and I want to improve it. Provide a massive library of UI’s, components, and data controllers, but default to a minimal starting point. Then pick and choose what you need with help from our docs.

Next Steps

From the view point of “building focused utility apps with a subscription business model”, I can take everything that has been built for SwiftStarterKits up until now, and:

Provide a minimal + practical app foundation with in-app purchase support + all the redundant essentials.
Ship a command line tool with the repo for generating new projects.

This “new project” generation script could take a custom app name or the app type (in this case “SubscriptionKit”), then scaffold a new project without any of the fluff of the existing SwiftStarterKits repo. Customers will still have the full monorepo of SwiftStarterKits code, but it can simultaneously be used as a reference and the basis for this code generation tool.

I’m super excited about this, and can’t wait to use it for my own apps.

SwiftStarterKits' RevenueCat Integration: The Story So Far.

2023-05-03T00:00:00Z

With the first version of the SwiftStarterKits documentation published, I’d like to shift gears to improving the SwiftStarterKits core product. While the existing documentation needs more investment, I simultaneously started marketing product features that don’t currently exist.

Thankfully (?), I haven’t made any new sales since publishing some new marketing copy alongside the documentation, but I do feel a little iffy about making promises that I haven’t delivered on quite yet.

Medium Term Product Goals

I’ve slowly consolidated the original vision for SwiftStarterKits from “starter kits for many types of iOS apps”, to “starter kit for subscription iOS apps”. It’s been a necessary transition for focusing the marketing and product strategy. At the start, it felt that I was trying to build a product for too many people, but in reality wasn’t solving a problem for anybody.

Smaller scope, focused messaging. After a few more product releases I’m itching to build some apps, dog-fooding the SwiftStarterKits toolchain internally.

The medium term plan:

Provide a starting point for in-app subscriptions.
Provide scripted tooling for generating new projects quickly. Currently, creating a new project with SwiftStarterKits and customizing it is cumbersome.

With both of these problems solved, the marketing copy and product will once again be in sync.

Enter, RevenueCat

With just a couple hours of work, I have a generic implementation of RevenueCat integrated, with all the bells and whistles for offline mock transaction testing.

SwiftStarterKits has a working RevenueCat integration!

Why use RevenueCat rather than the native StoreKit? Ease of implementation, cross-platform purchase support, amazing docs, no data lock-in. The common theme for SwiftStarterKits so far has been to fully embrace the native iOS platform, while ensuring that business data is portable. The same goes for using Firebase over CloudKit. If developers are going to build a business on top of SwiftStarterKits, I’d like to leave the option to integrate Web and Android platforms down the road.

Again, I’m bullish on native software experiences as a whole, they simply can’t be matched by cross-platform tech. If you want an incredible experience, you can do no wrong staying as close to the platform as possible. But for solutions to data storage, analytics, authentication, payments, you may as well leave the option to grow alongside your business.

Shipped SwiftStarterKits Documentation

2023-05-01T00:00:00Z

I’ve recently been working on building out a documentation system for SwiftStarterKits, which I write about in detail here and here.

Flash forward a week and the first version of this is shipped! It’s minimal and straight to the point, rendered fully on the server.

The first version of SwiftStarterKits’ documentation has been shipped.

Reiterating my previous discussions on this topic, SwiftStarterKits has been sorely missing guides on using the starter kit and its various integrations. For a developer focused business, documentation is essentially part of the core product. This is a pretty good start I think.

Please write some docs

The layers of complexity to building software cannot be understated, and to write a system that provides a serious add in value there needs to be a certain level of automated support. From experience, developers tend to assume their systems are obvious on the outset, but usually the opposite is true.

No matter how obvious it may seem, 3 things need to be answered about a software system as soon as possible in you docs:

How do I get it? A direct binary install? A package manager command? Do I clone the repo directly?
What is the least amount of knowledge that I need to use it?
What else does this system do? Expand on the core experience, only after basic setup is complete.

Don’t make things too complicate at first, but please, explain what the software does, and how to use it.

Next Steps

Sidebar aside, I plan to expand on these docs in the coming weeks:

Project creation.
Creating new modules.
Integration specific how-to’s (Firebase, RevenueCat, deeplinking, push notifications, etc).
An API reference.

Plus I feel behind on product work, gotta carve out more iOS time this week.