little note: GLM 4.7 I'm super impressed with. Feels alot like Sonnet 4 to me... and at $10AUD a month its an absolute steal.

Cron; but gamified

The 'game' asks you to produce various cron expressions using natural language. It's forked from the crontab-guru TUI built with Bubble Tea that helps you understand cron expressions using natural language based on the crontab guru site.

Clone and build the game from here.

git clone https://github.com/samuelstranges/crontab-guru
cd crontab-guru
go build .

# Run game
crontab-guru --test

# Run game in 'hard mode' (no real time preview)
crontab-guru --test --hard

My go to tap tempo has been taptempo.io. It's come in handy on several recording sessions I've been a part of. It's simple, good, works.

However, I wanted an offline only version for when I'm connected to my IEM mixer's Wi-Fi network rather than my home network. This prompted me to create the very originally named tap_tempo. Just a small CLI tool built with Bubble Tea in Go.

I hope it helps somebody!

The killer feature of the Ergonaut One is that it's wireless and has a battery life that can last months at a time.

The Problem

One complaint that I have had with split keyboards is the height of the setup, particularly at more extreme tenting angles; it can feel like you are lifting your arms to use your keyboard at times. Don't get me wrong, tenting is still an improvement over typing flat, but can be improved.

Above: You can tent an arbitrary keyboard to some pretty gnarly angles with a couple of phone stands and a couple of magnetic stickers, but you start raising your arms to the point where its uncomfortable again.

I think I've come up with a pretty unique solution to overcome this.

The Solution

The simple explanation: tie two mobile phone stands together (with a few scrunchies) at their bases, and allow the arms of the stands to hang free on the left and right, utilising a magnetic sticker at the bottom of each keyboard. Now, just place the stands on your legs! From here, tent to taste.

Above: The new and improved phone stand method; comfort your hands can only dream of!

"Typing should like a handshake" ©

More Photos

This is how I use a VPS as a remote homelab to run sensitive compute and projects with Docker, and securely ensure it's recoverable by backing up to S3. It's reproducible using a Docker Compose file, Terraform, and a couple of bash scripts.

Getting The VPS Up

When setting up this project, I first tried going with Digital Ocean, as I've always found their droplets in Sydney reliable. However, when I ran out of RAM with multiple Docker containers running all at once, I thought rather than paying a premium for RAM with Digital Ocean, it was a good opportunity to look for an alternative.

Meet FlowVPS. Prices are fair, set up is straightforward, and the speed is out of this world. I'm not kidding, the latency blew me away; it genuinely feels local. Every other box I’ve SSH’d into has been in Sydney, but this Melbourne based VPS responds like it’s on my desk.

I used stow to import my dotfiles to the machine, and set up brew and zsh on the Ubuntu OS I set up; meaning that in about 10 minutes, I had entirely replicated my MacOS terminal experience remotely on a different operating system. Now if I could only get copy/paste working over SSH...

How I Access My Services

On my laptop, I am able to SSH into the VPS using my public/private keypair I've set up with a user on the VPS box.

I'm running autossh to bind ports from the VPS to my laptop's localhost, meaning the applications work essentially as if they were running on a local Docker container, and automatically connect on login.

This means that you don't need to expose ANY inbound ports on your VPS outside of SSH. I've also heavily restricted the outbound ports for the Docker containers by defining two Docker networks in Docker Compose and setting ufw rules for them:

• br-internet: containers that need external access
• br-isolated: containers that must stay internal

This might seem overkill, but there is a good reason why it might be wise to lock down containers that might want to phone home for telemetry. I used ufw with the following rules to get it going:

# Base rules
sudo ufw allow OpenSSH
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow 'br-internet' (defined in Docker Compose) network (172.18.0.0/16) to access DNS, HTTP/S
sudo ufw route allow in on br-internet out on ens3 from 172.18.0.0/16 to any port 53 proto udp
sudo ufw route allow in on br-internet out on ens3 from 172.18.0.0/16 to any port 53 proto tcp
sudo ufw route allow in on br-internet out on ens3 from 172.18.0.0/16 to any port 80
sudo ufw route allow in on br-internet out on ens3 from 172.18.0.0/16 to any port 443

# Block 'br-isolated' (defined in Docker Compose file) network from internet
sudo ufw route deny in on br-isolated out on ens3 from 172.19.0.0/16 to any

# Allow host access to isolated containers
sudo ufw route allow in on br-isolated to 172.19.0.0/16

What's Running?

Here are the services that are currently up on the box:

• Atuin: The best shell history command (fuzzy, persistent across devices, secure). But my shell history shouldn't be on a foreign server.
• RSS-Bridge: Creates RSS feeds for TikTok and Instagram accounts, so I don't need to buy into the algorithm to follow the few people I need to. This isn't particularly secure, as they use third party bridges to fetch the data, meaning those third parties see what you are accessing on the original service. However, I don't see a reliable way around this, and the overall net positive of avoiding the Instagram cesspool is a net positive.
• FreshRSS: A no nonsense RSS feed fetcher/reader with a clean webapp. I like it cause I can integrate it with newsboat; a great little RSS TUI.
• Firefly III: Personal budgeting management
• ConvertX: I've always felt uncomfortable uploading documents to free document conversion websites, and can't be bothered learning CLI tools and flags
• Mini QR: Relying on a third party to create and decode QR codes is a security vulnerability.
• Baikal: CalDAV/CardDAV for calendar and contacts.
• Stirling PDF: I can't recommend this one due to the aforementioned tracking pixel, but it works well.

Automated Backups

I have set up automated daily backups for data that needs to be persistent (think my Atuin database, RSS feed database, etc). This is using a cronjob that calls a shell script that every morning does the following:

1. Turn off containers with volumes needing backups
2. Mount the volumes on fake containers
3. Tar/copy the volumes to the VPS
4. Turn off the fake containers
5. Use rclone to push the backups to the S3 bucket
6. Turn the real containers back on

The key trick for running this simplified script was to ensure all persistent data was located on Docker volumes, which provides uniformity in how you can backup the data with a simple for loop, rather than considering how each container might need its data backed up. Simplicity wins out here over availability... I don't need to keep my FreshRSS running at 3am in the morning for a few minutes.

How the VPS accesses the bucket is via an IAM user created alongside the S3 bucket using Terraform.

Infrastructure As Code

I've created a Github repo with the Docker Compose file, the terraform file, and a couple of scripts to help you get set up on your own VPS if you wanted to set up your own homelab using a similar system.

Conclusion

If this sounds like too much work, you can get 80% of the benefits with 5% of the effort by spinning up the Docker containers using the docker-compose.yml file on your local machine. This provides all the services, albeit without the flexibility, security, and backup capabilities of what I've outlined in this post.

git clone https://github.com/samuelstranges/public_homelab.git && cd public_homelab

# SET ENVIRONMENT VARIABLES

docker compose up -d

Even as I'm writing this I'm considering other services I can add to my system. It has opened my mind to the benefits of the self hosted mindset. Again, they don't deserve my data, and now, they don't have it.

• Google Keep: too proprietary
• Apple Notes: too walled off
• jrnl: too fragile
• OneNote: too different
• Joplin: too difficult to setup
• Obsidian: too expensive to sync
• Evernote: don't get me started

The note taking system that stuck?

A git repo full of Markdown documents.

Why Markdown + Git?

Honestly? Because it gets out of your way, and lets you just write. Too many modern systems require a lot of buy in from their users before they really get comfortable with their systems; and lock you in, making it difficult to move away when you realise the mistake you've made. Markdown + Git is the opposite.

The 3 F's

It boils down to this; Markdown + Git is:

• Free
• Flexible
• Future Proof

Free

Markdown is an open standard, meaning that there are hundreds of software packages that can view and edit Markdown files, from the humble Notepad everyone loves to hate, to Markdown specific editors like Typora (paid). Basically, as long as the software you use allows you to export in Markdown, you aren't locked into a platform. This means you can jump ship to a different editor at the drop of a hat. This is a great insurance policy for something that you don't want to have to deal with; migrating your notes to a new platform.

Using a Git repo provides version control for your notes, which actually comes in handy more often than you might think. Additionally, using GitHub, Gitlab, or any other cloud hosting service for your Git repo means that you can access your notes on different devices for free.

Flexible

Decoupling the hosting from the editor means you can pick the best tools for your specific use case.

Editor/Viewer

Using a Markdown backed system means you aren't locked in to a specific editor. How you think about and edit documents on your computer is likely very different to how you engage with documents on your mobile. Markdown gives you the best of both worlds by providing nothing more than an open standard. This means any editor can provide a different workflow and set of features that you might need in various contexts.

Examples:

• Mobile: iAWriter, 1Writer
• GUIs: MarkText, iAWriter, Typora
• Terminal: Neovim, Vim

Backend

A Git system might not fulfill your needs in terms of sharability or multi device sync. Additionally, your security senses might baulk at a cloud hosted Git repo. Great! You can plug and play whatever backend system you want.

• Need live syncing between devices?: Dropbox is easy, Syncthing is secure.
• Just need backups?: Use rclone.
• Is version control your thing?: Spin up that git repo.
• Paranoid?: A local folder encrypted with PGP.

You can mix and match too! For a while I was using Dropbox and a Git repo at the same time, but realised that since moving to a dumbphone, I only really access my notes on my primary device, so have since moved to a Git only system (using a private GitHub repo for backups).

Exporting Your Files

Markdown documents can be exported into virtually any file format you might need. Pandoc seems to cover most of the common ones.

Want to start blogging with Markdown? Check out Hugo, Astro, or even my own Project Therese to easily build sites backed by your documents.

Future Proof

Markdown will be here tomorrow, the day after, the year after, and the decade after. There are horror stories of forced migration and software abandonment for proprietary note management systems. For something as simple as writing personal documents, encountering these issues is frankly ridiculous.

Even if all the Markdown editors in the world disappeared tomorrow, Markdown's syntax is so humanly readable that it wouldn't matter. Because YOU are in control of YOUR documents, you won't need to worry about getting locked into a system that's going to shut down.

LLMs and Markdown

LLMs work really well with Markdown syntax, meaning that in the world of agentic AI, it's easy to provide context and instructions using the notes that you've written for yourself.

Looking forward to the near future, when I'm hopefully running a local LLM in a homelab setup, having my personal notes written in Markdown will provide a high quality and easily digestible context that a model will be able to use to problem solve.

Learning Markdown

Markdown is trivial to pick up; you can get a good understanding of the entire syntax within an hour. Even if you mess a thing up or two in your documents, modern linters and Markdown specific software are very forgiving and will help you out.

I'd recommend checking out the Markdown Guide as a first point of call.

Markdown In The Terminal

You're reading this blog, you're probably comfortable with the CLI. If you want a great experience editing Markdown documents in the terminal without any of the headaches, install LazyVim. Tweak as desired. That's it. It does basically everything you might want.

The only plugin I consider 'essential' that doesn't come out of the box is one to help with managing lists/sublists. I'm using autolist at the moment, but there are others that do the same thing just as well...

For an exceptional, but extremely esoteric Neovim Markdown setup, check out Linkarzu's article.

Daily Notes

If you're like me and mentally compartmentalise things by date, setting up a daily template and hooking up a keybind to quickly jump to it can make life a little easier.

local function open_daily_note()
    local dailies_dir = "/Users/user/notes_dir/dailies"
    local template_path = "/Users/user/notes_dir/daily_template.md"

    -- Get today's date in YYYY-MM-DD format
    local today = os.date("%Y-%m-%d")
    local daily_file = dailies_dir .. "/" .. today .. ".md"

    -- Check if file exists, if not copy from template
    local file = io.open(daily_file, "r")
    if not file then
        -- File doesn't exist, copy from template
        local template_file = io.open(template_path, "r")
        if template_file then
            local template_content = template_file:read("*all")
            template_file:close()

            -- Create the new daily file
            local new_file = io.open(daily_file, "w")
            if new_file then
                new_file:write(template_content)
                new_file:close()
            end
        end
    else
        file:close()
    end

    -- Open the file
    vim.cmd("edit " .. daily_file)
end

Useful Shell Aliases

If you live in the terminal, having a few quick shortcuts aliased in your .bashrc/.zshrc can remove friction when you need to quickly jot something down. Here are ones I use daily:

# open daily note (being in notes dir helps ripgrep/fzf search)
alias mt="cd /Users/user/notes_dir/ && $EDITOR -c 'lua open_daily_note()'"

# open my global TODO file
alias md="$EDITOR /Users/user/notes_dir/main_todo.md"

# search current directory for text
alias sg='nvim -c "lua Snacks.picker.grep({ cwd = vim.fn.getcwd() })"'

# create temporary markdown document (zsh needs backslash)
alias scratchpad="nvim /tmp/\$(head -c 16 /dev/urandom | xxd -p).md"

Conclusion

I'll be honest, there are two things that tempt me to move away from Markdown; Typst and Org Mode, for very different reasons.

However, every time I open up my folder and see that my Markdown system has been largely unchanged for over a year, I realise that I've found the right system, because I've stopped thinking about needing to fix it.

In this series, I'd like to share twelve of these tools I've built using AI assisted development to show how building with these tools have not only changed my own personal workflow, but how the mindset shift towards bespoke software could fundamentally change how we view SaaS and custom software.

Moreover, I'd like to show how categorising the AI development process can:

• save development time by working more effectively with LLM tooling
• prevent going down rabbit holes when approaching a problem using the wrong category
• make the iterative development process of developing with AI actually enjoyable
• stopping yourself from yelling at Sonnet to "JUST FIX IT"

Bespoke Software

My new favourite pastime is to read experienced developers complaining about the quality of vibecoded apps on Hacker News, asserting that AI assisted development would never be suitable for 'real' projects. I am of the strong belief that our understanding of a 'real' project is fundamentally changing, from enterprise tools that do a good enough job for thousands of customers, to hyper specific tools that work for small teams or even individuals; a decentralisation of software.

Don't get me wrong, enterprise software will continue to exist, and I sincerely hope no-one will try and roll their own payment processor to sell a bouquet of flowers at a farmer's market. However we are on the precipice of an entire category of software being created: "bespoke software", where non mission critical software is written specifically for an individual or small team's workflow or business' needs. Bespoke software prioritises rapid development and immediate utility over comprehensive testing and bulletproof architecture.

Every business has dozens of manual processes that are too specific for off the shelf automation, while being too small to justify traditional custom software. AI written bespoke software makes automating these viable, as suddenly every repetitive task becomes a candidate for elimination.

Bespoke Software: Non mission critical applications built for specific individuals or small teams to solve particular workflow problems.

The Code Quality Objection

Does code quality matter equally in all contexts?

The obvious objection against "bespoke software" is with regards to code quality. There's certainly, um... merit... to this argument. However, pointing to crappy and barely working vibecoded apps misses the underlying point about AI developed bespoke software; that they alter the cost benefit calculation, and each individual project must now be evaluated independently from one another regarding code quality and AI involvement.

Code quality has only ever really mattered for the purpose of meeting business outcomes and compliance; poor quality code and more broadly technical debt has historically negatively influenced the bottom line of a company. Bespoke software operates under a different set of constraints; when building small tools for small groups of people, with the ability to rapidly iterate, traditional quality standards become less relevant.

The real question isn't whether AI-generated code meets enterprise standards that must satisfy all kinds of uses and edge cases by multiple organisations, but whether it's adequate for the hyper specific context where it will be used. Since failure affects only a small group, and AI enables rapid iteration; the code quality, for bespoke software, often has a bar much lower than developers assume.

The question therefore shifts from "is this software robust enough to throw anything at it for future use cases" to "how does this software satisfy a small use case that exists at present".

The AI Collaboration Problem

Most developers approach AI tools the same way regardless of project type, leading to frustrations and failures.

At one end of the spectrum, we have experienced developers who haven't learned to provide appropriate context to the model, and asking it to solve complex problems in large codebases that the AI can't solve on its own.

At the other end, we have vibecoders generating massive and tangled codebases on projects that needed structured development from the get go. AI generated spaghetti code has a strange property; it continues functioning much longer than human-written spaghetti code. But at some arbitrary size, it will break down, and by then, the codebase is too complex to easily rewrite.

Between these extremes, we have developers who are resistant to giving AI control beyond basic boilerplate, and others who consistently attempt to iterate through problematic AI code that needed upfront architectural planning.

All of these approaches to using AI are valid in specific contexts, but having only a single methodology of using AI becomes counterproductive when presented with a different type of problem. Developers haven't yet developed the intuition on how to effectively categorise AI involvement for different types of projects.

This lack of systematic thinking about AI collaboration is one of the main barriers to bespoke software development. When developers can't reliably choose the right approach for different types of projects, they don't realise there is an entire category of software waiting to be written that was previously not viable. This is where a systematic categorization of AI collaboration approaches becomes valuable.

The Solution

I propose a framework of different types of AI involvement in the development process, so developers can quickly learn what types of problems are well suited to different types of involvement.

Categorising the involvement of AI development helps create a mental model of what types of projects are suited towards what type of development, helping you more effectively interact with the AI during the software development process.

Each of these categories lend themselves to different types of projects and business needs. They can help us approach problems with a better understanding of:

• Best practices for approaching each of these categories
• What types of projects are suited for which type of AI involvement
• Common pitfalls for each of these categories

If developers were aware of each of these categories and when to approach which problem with which approach, I believe we would see more successful bespoke software projects, fewer frustrated developers abandoning AI development, and ultimately the widespread adoption of custom automation that transforms how small teams work.

Introducing The Categories

AI assisted development can be categorised into five distinct categories:

1. Scaffolding: You request specific boilerplate to be generated by the AI, while actual implementation details and key business logic is manually coded.
2. Collaborative: Tasks are clearly divided between the AI and you, based on who is more effective at implementing type of task.
3. Architectural: Provide detailed specifications upfront, giving detailed requirements before coding begins. AI follows your blueprint.
4. Iterative: Code-level feedback loops with AI. You react to AI's design and implementation, suggesting specific improvements to functions and logic. AI does all coding.
5. Vibed: Fully give in to the vibes, embrace exponentials, and forget that the code even exists.

Twelve Tools In Twelve Weeks

Now I've introduced the categories, I'd like to introduce the projects I have written over the last few months (mostly bespoke) and the different methodologies that were used to build effectively, and in some cases, not effectively at all using AI.

Convocare

• Description: A local events webapp for Catholics in Melbourne
• Pain point: Young Catholics regularly complain about a lack of events, despite several parishes and groups regularly hosting events. Discoverability is a real issue.
• AI Development Category: Iterative (should've used collaborative)

Here is a breakdown of how it was built.

spellbound.nvim

• Description: A neovim plugin that introduces a new mode dedicated to spellchecking documents
• Pain point: Spellchecking documents in neovim is clunky and repetitive
• AI Development Category: Vibed/collaborative (Methodology is mixed, as it was my first real AI assisted bespoke software I built. I plan on rewriting using the collaborative method again, as the codebase kind of sucks)

Chronos

• Description: An advanced calendar TUI using BubbleTea, featuring multiple views, vim keybindings and iCal compliance.
• Pain point: We're apparently in the golden age of TUIs, but we don't have a half decent calendar application.
• AI Development Category: Architected

Project Therese

No screenshot because you're looking at it!

• Description: A dead simple static site generator that looks beautiful (this site uses it).
• Pain point: When setting up my blog I found static site generators to be more complicated than needed, and not actually look that good.
• AI Development Category: Iterative

Chronos Sync

• Description: A serverless calendar to SMS notification system built on AWS
• Pain point: Using a dumbphone means I don't have access to my calendar easily.
• AI Development Category: Architected

Hammerspoon switcher

• Description: A MacOS switcher that can jump to both applications as well as open tmux windows using a single letter
• Pain point: Although my tmux quick switch project works fine, I find myself thinking about whether I want to switch to an application or a window, which takes me out of the flow state.
• AI Development Category: Architected

Qutebrowser Jump to Audio

• Description: A Qutebrowser script that jumps to the tab with the actively playing audio source

• Pain point: I often find myself searching through my tabs to find the audio/video source that is currently playing just to stop it

• AI Development Category: Iterative

Youtube RSS Copy

• Description: A Javascript tool that works as a chrome extension or as a userscript to copy RSS feeds of youtube channels and playlists
• Pain point: Wanted to source YouTube RSS feeds without relying on third-party services that might track my viewing habits
• AI Development Category: Vibed

Failed Lazyorg Fork

• Description: An extension of Lazyorg to be more useful as a calendar TUI
• Pain point: Lazyorg is a promising calendar TUI but needed several large changes to be useful for day to day use.
• AI Development Category: Iterative (should've used collaborative)
• Why it failed:
  • Didn't ask the question: "Should I try extending this existing project or work from scratch?". The tech stack prevented extending the software to where I wanted it to go, and I didn't take the time to look into the implementation details and the limitations of the library it was built on.
  • Let AI write spaghetti

Rolodex

• Description: A pass-like contact manager that uses Git backed .toml files and fzf for its front end.
• Pain point: I don't like that I'm locked into proprietary Cloud based solutions for something as simple as managing my contacts
• AI Development Category: Architected

Tmux Quick Switch

• Description: Switch between tmux windows with a single letter
• Pain point: I organize tmux windows as conceptual applications ('Development', 'Work'), but switching between them requires too much cognitive overhead
• AI Development Category: Iterative

Selfhosted RSS Infrastructure

If there was an image it would just be the docker logo lol...

• Description: FreshRSS and RSS Bridge services deployed on AWS EC2 to sync RSS across devices

• Pain point: Wanted to securely synchronize my RSS feeds across devices while keeping them accessible via newsboat CLI, plus gain hands-on AWS experience

• AI Development Category: Iterative

Explaining the categories

Hopefully you can see the kind of complexities and types of projects that lend themselves to each category that I've defined earlier. However, it may be helpful to show how a single project can be approached using the different categories. Lets use the example of a calendar application, and see how each methodology may build parts of the application.

Scaffolding

• "Here's my Calendar.js file. I need empty functions called parseEvent(), validateDate(), and formatTime() with proper signatures that plug into my existing EventManager and DateUtils classes"
• Review output
• Manually write implementation logic

Collaborative

• "You handle the backend API, data models, and database logic, I'll build the frontend components and handle the styling"

Architectural

• Write document that outlines that you want a calendar app with these specific features, using this tech stack, using these design patterns, following this data structure, and provide documentation and files of APIs, libraries, example screenshots of what you want it to look like
• Review code
• Decide between jumping into an iterative process for specific issues, or to re prompt with better outline, documentation, etc.

Iterative

• "Build me a calendar app"
• Review code
• "See how in this function you're using a nested loop? We should be using a map for better performance"
• Review updated code
• "Move this validation logic into a separate function"
• Process continues

Vibed

• "Build me a calendar app"
• Test the app
• "Make the events bigger"
• Test the app again
• "Add a month view"
• Process continues...

What About Questioning AI?

What I call consultative development, the idea of you developing, and asking AI for feedback on changes, I'm not sure should really be considered AI developed software, I think this way of using AI acts more as an extension of feedback mechanisms. Definitely an important piece of the puzzle and needed in many cases where more control is needed, but not really what I'm getting at when I'm talking about developing with AI.

Moving Up And Down Through The Categories

It's important to understand what category your project is in before you open up your AI coding assistant. This is because it is far easier to move down a category than it is to climb up them again. Once you give the AI control over not just the implementation details, but the overall design of the project, you have already created a significant amount of technical debt that is extremely time consuming to wrangle back control.

A perfect example of this is when I was developing Chronos, using the "iterative" methodology. By the time I started to realise that the complexity of the project lends itself better to an Architectural approach, I had accumulated a significant amount of technical debt, particularly in the area of DRY and mixed concerns of packages and functions.

The Collaboration Boundary

One distinction that emerges through this categorisation is that between usage and authorship in the context of teams. The development methodology of the deeper categories of AI involvement scale less effectively to collaborative authoring.

This is obvious when you think about it, that the economics that make bespoke software viable: rapid AI-assisted iteration, tolerance for imperfect code, minimal upfront planning can break down the moment you introduce shared development. This is because maintaining consistent architecture across multiple contributors and documenting implicit design decisions reintroduces all the overhead that deeper categories can eliminate.

Take the iterative approach, for example, the design decisions live in your conversational history with the AI, not in transferable documentation. However, if I had used the Architecture category from the get go: creating proper specifications and documentation, then accepting contributions become much more viable. Ultimately, these categories determine the future ownership of the resulting software; deeper levels of AI involvement trend towards a more individualistic ownership model.

Questions To Help Categorise Projects Before Implementation

• How large is the project?: If the codebase is expected to be large relative to your LLM's context window, you may need to move up a category or two.
• Is this a library that other projects will be built on top of, or is this the end product?: AI can rapidly iterate for hyper specific business concerns, suggesting deeper categories. Libraries need stability and careful design, pushing toward more shallow categories.
• What tools will the project be built on?: Typed languages, TDD and static tools can help AI work more effectively with larger codebases, potentially allowing deeper categories. Dynamic languages and those without external refactoring tools outside of manually editing code may force moving up.
• Are my models well trained on my tech stack?: I've found AI produces poorer output on embedded projects, low level code, and newer frameworks like Svelte, requiring more oversight and manhandling to produce correct output. Common frameworks work better with deeper categories.
• What vulnerabilities/security issues do I need to be thinking about?: Higher risk projects and those dealing with sensitive data need more manual control.
• What will maintenance and future extensions look like?: Do you have a clear understanding of how this software will be used long term that you may need to accommodate? If not, extensibility is needed so a more shallow AI approach is required.
• Who will use this?: Personal tools allows for experimental approaches, while larger teams needs consistency.
• What is the impact of a catastrophic failure of this software?: What is your RTO/RPO, and more broadly; what is the business impact if the software were to go haywire? Critical applications require more manual intervention and oversight.

Where To From Here?

This introduction has established the framework, but I understand if you think it has been a little light on examples. The coming articles will flesh these out using the above projects as case studies, and will show how to effectively approach problems using each methodology.

But hopefully I've painted with a broad brushstroke that:

• LLM generated code should be judged contextually based on the development category appropriate for each project
• Bespoke software powered by AI is expanding what we consider viable projects, but only when we systematically match AI collaboration approaches to project requirements

This post explains why it's better to choose the boring tools and "outdated" patterns that everybody loves to hate. These are the tools that shine in the context of AI assisted development; facilitating rapid prototyping through patterns the model can actually predict, and being terse enough to fit inside the average LLM context window.

Before we dive into it, I need to get the definitions out of the way...

Definitions

the stack /stæk/ noun, informal

A collection of tools chosen with optimism and maintained begrudgingly. If you're still using it at MVP, it's in the stack.

See also: resume-driven development, "I should rewrite this"

the stuck /stʌk/ noun, informal

Tools and patterns that seduce you during prototyping but get thrown out by MVP. Characterized by "one more fix" sessions, infrastructure rabbit holes, and the realization that you're deleting weeks of work.

See also: premature optimization, yak shaving

the boring /ˈbɔːrɪŋ/ noun, informal

Tools and patterns that get out of your way and let you ship. Characterized by extensive documentation, predictable behavior, and the comforting feeling that you're building features instead of debugging infrastructure.

See also: battle-tested, "it just works"

Introducing The Project

Convocare is an events platform for young adult Catholics in Melbourne. Users discover events through a map, calendar, or card grid, and can save favorites for later. Admins manage everything through a dashboard that handles event creation/editing, scheduling, and approvals.

The application is fully responsive across desktop and mobile, and includes features like recurring event support, image uploads, and location mapping. While building the site, I learned just how important choosing the right stack is in the context of AI assisted development.

"The Stuck": Convocare Edition

Version 0

My first attempt at getting Convocare up was a mess. Although the site was functionally working, it was tied together with spaghetti, and used a backend so tightly coupled to the architecture that a full rewrite became the easiest option...

Let's take a look at the 3 main issues with my first attempt.

LLMs And DRY; A Love Story

In the AI assisted development discourse I see online these days, there is one crucial detail I think is being overlooked:

DRY violations are self perpetuating when developing with AI.

It's easy to be enticed by the quick prototyping that occurs working with AI, however, each DRY violation you accept will ironically create a pattern which the LLM will use to violate DRY again. This emergent behaviour is unique to LLMs, as humans can always just choose to write the next feature more cleanly, but with agentic AI agents contextualising the patterns of the entire codebase, each mistake will self perpetuate.

In my case, I slipped into bad habits when creating this prototype, allowing repeated code to be littered throughout the codebase, rather than creating clean abstractions. When I tried to steer the AI into a cleaner way of doing things, I found it was already too late, as it was clear the model was recognising the repetition as its own pattern that should be followed.

This is garbage in, garbage out for the agentic era, and should be avoided for anything bigger than a toy project.

Svelte

My first iteration of Convocare was built using Svelte and SvelteKit using Claude Sonnet 3.5/4. This was a big mistake. I think the lack of quality training data that exists for new and clever frameworks and patterns, like those Svelte offers, means that the code that LLMs will write will be poorer.

The code that it wrote was again, functional, but extremely verbose. I couldn't get the model to stick to a single pattern, and even when it did, they weren't idiomatic to Svelte.

I should've just used React from the start as it has tonnes of great training data to use for all kinds of problems.

Monolithic Architecture

This one's on me... I was enticed by the idea of simplifying the infrastructure to a single box, which is great for cost savings for a specific set of projects, but certainly overkill for Convocare. Still, I forged ahead, until I got bogged down in infrastructure hell. I spent more time debugging why an Nginx reverse proxy was grabbing its configuration from an unexpected file than implementing features that users would actually want.

Even worse, I actually considered hosting my own map tiles instead of just defaulting to using Mapbox (how likely is it I'll ever leave the free tier?).

AI thrives when you can isolate issues to a small area. A monolithic architecture doing 10 things at once is the nightmare scenario for an AI agent, it will struggle to pinpoint where something has broken. Add to that the fact that agentic tools can't SSH into remote servers to debug config issues (probably a good thing, security wise), and you're back to manual debugging.

Version 1

Coming back to the project with a fresh set of eyes I was able to recognise the mess I had gotten myself into. However, this wasn't to say I learned my lesson, yet again I was tempted by technologies and approaches that didn't lend themselves to AI assisted development, and got bogged down in technical debt and problems quickly!

Rolling My Own API

Realising the mistake of a monolithic architecture, I think I swung the pendulum too far the other way. I decided to roll my own REST API to maximise deployment flexibility; using a combination of Drizzle, Zod, and Better Auth (all excellent tools in the right context).

I got about 80% of the way through writing the API routes before I realised the code was unmaintainable. The issue here was consistency; each route generated had slightly different patterns for validation, error handling, auth, etc.

In hindsight, I think this had a lot to do with the context window. The conversation would compact before finishing a single route, meaning Claude would lose context of earlier patterns. Unless I manually fed it examples from previous routes (and I rarely did), each new endpoint reinvented the wheel; not thinking to look to see if any other routes had been created to reference in the first place.

Supabase CLI And Declarative Schema

Supabase is legitimately incredible, but for now, Claude can't leverage it effectively. I had two major issues when trying to get Claude to work with Supabase; use of the CLI, and working with migrations and declarative schema.

Normally, my go to solution to fixing Claude having issues with CLI tools, is to either find the relevant documentation and provide it as a file to be read, or to just paste in the entire documentation in the chat window. These approaches have worked for every tool I have had issues with, up until working with the Supabase CLI.

Claude would continually provide incorrect information on how to use the CLI, edit migration files that had already been run on the database, and continually misinterpret how to work with declarative schema. Despite giving Claude the context it needed to solve the problem, it was still unable to find a solution.

There are two reasons I think this occurred:

1. The Supabase CLI is a local first tool, but the AI kept treating it like it was applying changes on the remote database.
2. The declarative schema approach that I was excited to use (coming from Terraform), isn't feature complete. The tooling encourages you to think in terms of migrations, but the declarative layer creates confusion about what's already applied vs what needs to change.

In the end, I ended up doing most Supabase schema work manually through the dashboard and SQL editor. Not ideal, but not the end of the world.

"The Boring": Convocare Edition

After two failed attempts, here's the stack that actually got built:

• Frontend
  • Next.js, React, TypeScript
  • Tailwind CSS
  • Vercel (hosting & deployment)
• Backend/Data:
  • Supabase (Postgres + Auth + Storage)
  • Google OAuth (via Supabase)
  • Next.js API routes (middleware layer)
  • Sharp (image processing)
• External Services:
  • Mapbox (map tiles)
  • Route 53 (DNS)
• Validation & Type Safety:
  • TypeScript (compile-time checks)
  • Zod (runtime validation)
• Helpful AI Tools:
  • v0 (frontend component designer)
  • Claude Code (Agentic Tool)
  • Sonnet 4.5 (Model)

Benefits Of The Boring

"The Developer Experience"

Before working on Convocare, I thought "the developer experience" was only ever used as the butt of a joke for frontend devs who were scared of touching hardware. I'm ashamed to report, however, that the developer experience is REAL.

The Next.js w/ Vercel and Supabase stack is incredible. The following three commands essentially allowed me to forget about infrastructure and just work on implementing features:

vercel --prod
npx supabase db push
npx tsx supabase-seed.ts

Both Vercel and Supabase have sane defaults, hard billing limits, and reasonable free tiers, which really give peace of mind for small projects. Moreover, both are flexible in terms of deployment, so in the unlikely case Convocare gets to a point where cost becomes a real issue, we have options with where to run things without too much rigmarole.

In particular, using Supabase's RLS, as well as utilising views rather than joins for public queries means it's easier to separate concerns, and creates a mental model that goes "Database stuff? That's handled by the database".

LLM Friendly API Routes

Simplifying your API routes allows you to leverage AI debugging far more effectively, thanks to the unidirectional and linear patterns that AI seems to thrive on.

In my case, I used URL parameters over state management in React (think ?filter=upcoming&sort=date). This allowed issues to be quickly identified, as the LLM doesn't need to contextualise several processes at once, and doesn't need to mock in order to start debugging.

In short:

• A route an AI can debug easily: fetch, validate, display
• AI's nightmare route: query, cache, invalidate, retry, error, retry.

Context Is King

Boring tools are terse and clear. The more tersely the information you give the AI that is still intelligible, the more context you have left for actual solutions to the problem you're working on.

A great example of this is Tailwind, which plays extremely well with Sonnet. By managing a lot of the CSS in the context of your HTML, LLMs don't need to manage file references and state throughout your codebase, so that the changes it makes actually work.

Conclusion

Let's have another look at those definitions. In short:

• the stack: tools used to reach MVP
• the stuck: tools you ditch by MVP
• the boring: tools that make reaching MVP a breeze

By committing to the boring, you'll be in a much better position to leverage AI assisted development to deliver a functional platform in a fraction of the time it would take you if you tried to chase new and shiny, like I first did...

If you don't want to read that, the TL;DR is that there are specific pain points that I've encountered since switching to a dumbphone. One I still haven't sufficiently alleviated yet is: integrating my calendar system into my daily workflow without a smartphone.

The Terraform files, Lambda functions and bash script used to run this project are available on a Github repo. It's still very experimental, so use at your own risk.

Anyways, this blog post outlines one approach I took to solve this issue, and although I'm not using it currently, basically due to the price per SMS charged by AWS, I still think it's worth sharing.

Constraints

Teasing out the problem a little more from just 'smartphone bad, but i miss calendar', I figured the solution to integrating my dumbphone with my calendar system would need the following:

• Work with my calendar application of choice (more on this in a minute)
• Be automated; no manual uploads
• Endpoint needs to be SMS (for dumbphone notifications)
• Be a serverless solution, I don't want to have to pay and maintain a server just for this
• Use AWS services

Designing The Initial Architecture

The AWS ecosystem is large, complex, and at times downright confusing. Figuring out what would go at the end of the pipeline was straightforward though, an SMS endpoint screams an SNS topic. Obviously, the main difference to most projects is that my topic would have one subscriber; me!

The design of the pipeline feeding the SNS topic could be more flexible, however. The underlying calendar software would end up guiding this decision.

For a while I've been using my own fork of Lazyorg to manage my calendar from my laptop. It's a cool little TUI that is built with gocui. The events are backed by an SQLite database. To get these events pushed to my dumbphone, I'd need to build a pipeline that uploads the database, convert the events to a message, and place the event in the SNS topic.

Working with a small SQLite database lends itself well to using AWS Lambda. Therefore, I settled on a solution that would: upload the SQLite database file to an S3 bucket, and using S3 event notifications, create EventBridge schedules for each of these upcoming events contained in the database. The schedule would call a second Lambda function 15 minutes before a given event that formats the event as a message, and publishes it to an SNS topic, which my mobile phone was subscribed to.

I thought about potentially offloading some of the more complex transformations and parsing to my local machine before uploading, which would potentially remove the need for an S3 bucket, or a secondary Lambda function. However, I thought the following architecture provided the greatest flexibility to alter the design later, as well as provide advanced control over the message content that would be sent over text.

Overview Of Pipeline

Local cronjob -> S3 -> Processing Lambda -> EventBridge -> Notification Lambda -> SNS Topic -> Dumbphone

Implementing Prototype

With the architecture decided, I moved onto implementation. I setup a cronjob to upload my SQLite database once a week to an S3 bucket. This provided a beneficial secondary purpose, it would serve as a weekly backup of my calendar!

I used Claude Code to whip up a quick prototype Lambda function that would trigger on any upload of a file to complete the following:

1. Download the .sqlite3 database to the Lambda's /tmp directory
2. Perform an SQL query to grab upcoming events (within the next 7 days)
3. Clear any existing EventBridge schedules from previous uploads
4. Create new EventBridge schedules that triggers a second Lambda function 15 minutes before an event in my calendar

Fighting Dependencies

Something I wasn't quite happy about, however, was how the underlying dependencies of the project led to suboptimal code being produced for the Lambda sections of the pipeline.

One great example of this is with date parsing. Python has a wonderful datetime library (especially compared to Go, which I'm using for other projects), but it felt a little bit awkward integrating the SQL database which stores the date and times as strings with the inbuilt datetime implementation.

My calendar stored everything as UTC strings, so we had to do the following:

# Calculate time window: now to 7 days in the future
now_utc = datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S')
end_date_utc = (datetime.utcnow() + timedelta(days=7)).strftime('%Y-%m-%d %H:%M:%S')

# Query events within the 7-day window
cursor.execute("""
    SELECT id, name, description, location, time, duration
    FROM events
    WHERE time > ? AND time <= ?
    ORDER BY time
""", (now_utc, end_date_utc))

And then for each event, parsing the strings back into Python datetime objects:

if '+' in time_str or 'T' in time_str:
    event_time_utc = datetime.fromisoformat(time_str.replace('+00:00', '')).replace(tzinfo=None)
else:
    event_time_utc = datetime.strptime(time_str, '%Y-%m-%d %H:%M:%S')

It certainly felt like I was fighting the data format rather than working with it. Regardless, we pushed on.

Testing The Prototype

Despite some questionable data conversion, the prototype was largely working outside of the inevitable timezone issues you run into when developing anything calendar adjacent. Regardless, I was receiving my calendar notifications 15 minutes before the events occurred, as expected.

This was great, until I stopped receiving notifications for my events about a day or so later...

To debug, I first went through the logs of the first Lambda function's executions. This wasn't it, they were triggering fine. Next, I checked the EventBridge schedules, these were created and were set to trigger at the right time too! I narrowed down the problem to the final Lambda then, or so I thought...

This was working fine too! I was befuddled; the entire pipeline seems to be working, but I'm not getting any messages?!?!

Then I realised something... I wasn't receiving SMS messages from AWS AT ALL! I set up a separate SNS to SMS topic for the purposes of cost monitoring, and these weren't being pushed to my phone either! This was weird, surely my pipeline wasn't affecting other SNS topics I'd set up, right?

Well, turns out, I'd fallen victim to AWS quotas. AWS has a default spending threshold of $1 per account for SMS. I'm sure this helps prevent a significant amount of spam, but I felt a little frustrated that I wasn't even informed upon reaching the quota that the quota even existed!

The funny thing about this prototype, was that the most difficult thing to do was to request an increase on my quota (taking a number of days to be approved). I felt a little silly filling out the form clearly meant for much larger organisations running sophisticated campaigns and programs, requesting a $15 a month spend, and an intended audience of... myself.

Nevertheless, when the quota increase was approved, we were back in business, and receiving SMS messages again.

Reflections On Prototype

Living with the prototype for a while made me reflect on the architecture and decisions I had made, and how it could be improved.

The primary drawback of the prototype was that the calendar was backed by an SQLite database rather than a more standard iCal based system. This means that the Lambda functions I developed felt a little janky, and the entire system to me felt brittle because of it. Also, being a prototype, I hadn't written any tests (iT wOrKs On mY MaChInE).

Really, these problems could have been avoided if I gave less control of the design of the Lambda functions to Claude Code, and took more time teasing out the detailed instructions that it works best with. Instead, I ended up with giant cyclomatic issues, and a spaghetti code that, while working, wasn't worth going back and fixing (looking at you magic numbers and giga-methods).

Another problem with the prototype was that the build wasn't reproducible, I used the AWS console to set everything up, when I should've used CloudFormation or Terraform.

Finally, the S3 cronjob upload method I relied on to trigger the serverless pipeline wasn't particularly reliable; my machine obviously needs to be on when the cronjob is run, which means that if my laptop lid is closed when the cronjob is set to go off, the pipeline wouldn't be set off at all (until I noticed I'm not receiving SMS messages and manually uploaded them to S3).

Moreover, this architecture, specifically this use of S3, meant that it would only ever support one calendar, as each upload overwrites the previous calendar's events. Why? S3 event notifications trigger on every uploaded file, not on every upload batch, preventing uploading multiple calendars simultaneously.

Building V2

Despite the issues in the prototype, I was happy enough with how it was running.

The trigger to create a V2 of this project was actually building Chronos, my own calendar TUI. I'll be releasing it in the next couple of months. It's backed by a more standard iCal compliant system. Making the switch to this really forced my hand, and allowed me to make some major changes to this notification project.

Architectural Changes

The major design difference compared to the prototype would be with regards to how we used the S3 bucket. In the prototype, an upload would trigger the Lambda using S3 event notifications, but since we wanted to support multiple calendars (with Chronos: multiple .ics files), we would need to automatically trigger the Lambda function in a different way. Since calendar files are pretty small (usually measured in kb), we should be able to trigger a Lambda function with the calendar files as a part of the payload.

I still kept the S3 bucket as a part of the pipeline, however, as I still found it handy to have a second place my calendar is saved to, but, it really isn't needed to process the events, as the Lambda does all of the lifting now.

Another massive change is on the reproducibility of the project in V2. Now, we're using Terraform. This simplified the orchestration of the AWS services, and I really LOVE the declarative approach it uses to spinning up and managing running services. Now I've used Terraform for this project, I don't think I'll be using anything else.

One challenge moving to Terraform did present, ended up being very beneficial. It forced me to use best practices, and to avoid shortcuts. One example of this was the packaging of the libraries used in the Lambda functions. The recurring date time functions that expand iCal events into individual objects isn't a part of the standard datetime library in Python, instead, you would use a separate library or roll your own (RIP prototype recurrence generator). Terraform encouraged me to set up a Lambda Layer rather than just manually package libraries as a part of the Lambda function itself. It did this by making it dead simple to setup and manage a Lambda Layer.

Another key difference is the robustness and stability of the software. While I again used Claude Code to develop the Python Lambda functions, I took the time to control the design and implementation, using an iterative process to break down the complex functions into smaller, composable, and most importantly, testable functions. I used pytest and moto to mock and test the Lambda functions (I'll be honest, I just vibed the tests, outside of making sure it focused on timezone handling). Despite this, we still encountered a couple of bugs... timezones and missing events, a tale as old as time.

Implementation Challenges

One timezone bug (now patched) would occur every time the first Lambda function was triggered. Events that existed in the past (up to 10 hours ago) would immediately be texted to me. Since I'm in UTC+10, it was pretty clear what was going on. Digging a little deeper, it occurred when events had no timezone attached. So, adding a default timezone (Melbourne) seemed to work fine. This is implemented with a conditional check for timezone existence.

Another bug was with regards to EventBridge schedule groups. Rather than iterate through all existing EventBridge events to delete each one individually, I decided it would be more elegant to delete the entire EventBridge group. Only problem was that I wanted to immediately write to this EventBridge group again. The boto function to delete EventBridge groups operates asynchronously, so I had to introduce a manual sleep() that gives enough time for AWS to delete the group before attempting to write to it again, else the Lambda would error out. If anyone wants to measure the length of time this takes to save on Lambda compute, be my guest.

A Little Vent On IAM & LLMs

Why do LLMs seem to have a love for poor security practices, particularly when it comes to creating IAM policies? When building V2, it would create policies with permissions that were widely out of scope to the project, and even those that were necessary, would make the permissions far too broad. Several times I found myself reviewing generated policies that would be applied to all of my buckets, or to all of my EventBridge schedules, despite the fact that Claude Code had basically the entire project and previous secure policies from the prototype in it's existing context window.

Caution Before Running

So... You read the title, you got a little excited, you cloned the repo, modified the Terraform state location variable, added your phone number, and you're ready to run your own personal SMS calendar solution. Well... at least if you're in Australia, maybe think twice before jumping in with terraform apply.

The cost per SMS varies widely across different countries, and over here, it ends up being about $0.04 per text. I use a timeblocking methodology to organise my schedule, so I end up with about 10-15 events per day. Over the course of the month, this adds up to about $30AUD, which is more than I spend on my entire mobile plan.

The other major downside/quirk of this system is the deliverer ID. When you get a message, it's not from 'Sam's iCal', but rather 'UNVERIFIED'. Outside of testing prototype systems, it's expected that you end up registering a sender ID and setting up an origination identity, which can be quite a costly and time consuming process. Perhaps the market for rolling your own private SMS notification system might be a little smaller than I initially thought...

However, if you're a dumbphone user flush with cash, and can mentally map 'UNVERIFIED' to 'My Calendar', then check out the repo!

Conclusion & Future

I had a fair bit of fun getting this project up and running. However, it turned out to be an expensive education. Serverless is cheap, and Terraform is awesome, but AWS has more hidden quotas than you can poke a stick at. Most importantly, I proved that you can solve a $0 problem with a $30/month solution smh...

So, at least for now, I won't be using this system to push my calendar to my dumbphone. Having had some more time to reflect on the problem, I think the actual solution would be to use the inbuilt, barely working web browser on my dumbphone.

Perhaps I could setup a really simple webpage that my dumbphone could access, with simple password authentication provided by HTTP Basic Auth, and then secure it by enforcing a HTTPS connection. This would certainly be more flexible, however, the obvious downside is that there wouldn't be notifications. I might have to use my brain every now and again...

Switching Is Becoming Increasingly Difficult

Here's the problem with switching to a dumbphone in 2025. We're transitioning into a world that assumes constant connection and access to the internet at any given time. Without intentionally opting out of this, it can be hard to see that the infrastructure we once took for granted is quietly being eliminated. For myself, this has manifested itself in several awkward situations since I made the switch.

More concerning however, is knowing that this societal "paywall" is pushing out an increasing number of people out who don't have access to technology for financial reasons, cultural reasons, or simply for technical illiteracy.

So, I'd like to share some of the troubles I've encountered since making the switch to demonstrate how our increasing dependence on smartphones is creating barriers that extend far beyond personal choice.

WhatsApp

WhatsApp is ubiquitous, and since moving away from social media, it has become my primary method of communication. However, Meta is certainly making it difficult for dumbphone users.

WhatsApp technically doesn't need a smartphone to work, just a phone number. However, in practice, I've found it incredibly difficult to set up and manage without one. The main issue is that it requires web and desktop applications to be setup via a smartphone.

Currently, my workaround is to setup these connections using WhatsApp on Android via an Android emulator (Bluestacks Air for MacOS). This is far from perfect, the app frequently desyncs, meaning I lose my message history, and need to reset my contacts from scratch.

What is particularly annoying about the restrictions: the workaround won't work with the MacOS desktop version, only with WhatsApp for Web (or the nchat CLI if you're into that sort of thing). This is as the authentication method requires scanning a QR code on your desktop app from your smartphone (no text message auth available). I haven't been able to get this working with Bluestacks Air (although apparently a recent update may be able to change this; but I'm scared I'll lose my chat history again).

So much of our daily communication has moved to WhatsApp, particularly in the area of public groups. Email lists and group texting has been deprecated in favor of group chats on WhatsApp; events organisation, work group chats, parish mass schedules all demand participation via a smartphone.

Tech Infrastructure Is Changing

Switching to a dumbphone has also revealed to me how quickly we abandon working technology for marginal improvements, systematically excluding people who can't afford constant upgrades.

My first encounter of this was actually when attempting to setup my dumbphone in the first place. When I decided to make the switch, I figured I'd just use my old phone from years back and be done with it. Well, I was a bit miffed to learn that Australia, as of November 2024, has shut down their 3G networks. This meant for me that my old phone was off the table, as well as any other second hand device I would have wanted to purchase. There are plenty of dumbphones out there that can still play Snake just fine, but not many that would still be able to make a phone call...

Purchasing a dumbphone in 2025 means purchasing one with features I would rather not have, as I'm really trying to enforce on myself this intentionality of technology; and unnecessary features have for me always contributed to excessive use. The only "dumbphones" I was able to find for purchase that operate on the 4G network all have internet access, which I find incredibly frustrating.

This frustration extends to mobile plans too; I couldn't find a single service provider that offers voice and text without data. My plan was recently "upgraded" both in amount of data available and in price. I'm literally paying extra now for the internet access I'm trying to avoid, and most sites (including this blog) don't even work on low data connections like dumbphones in the first place!

Perhaps most heartbreaking was recently meeting a community member who had recently spent money they could hardly spare on a phone, only to discover it would stop working entirely due to network changes they'd never heard about or understand. It's become clear to me that forcing upgrades disproportionately impacts vulnerable populations.

Getting Around

Travel has been perhaps the most difficult part of migrating to a dumbphone. So much of how we get around these days has become tied up with using our smartphones.

The obvious change is navigation. Satellite navigation is the one feature I most wanted to keep when I made the switch, so naturally I set out to find a GPS system. It was surprisingly difficult; most are as expensive as modern smartphones, and lack the basic features to be reliable for day to day driving. The first one I bought I returned within an hour. I ended up settling on a Garmin Drive, and just deal with the lack of real time traffic and outdated mapping.

Parking is another pain point. The humble parking meter has largely been replaced by the smartphone app. Just yesterday I was trying to find a park at a library. When I arrived at the meter, I was warmly greeted with a laminated sign asking to use an app or to call a number to find alternatives. I decided it wasn't worth the hassle, and drove off to find another library. For people without smartphones, these "improvements" to parking systems can make basic civic services like libraries effectively inaccessible to the people they have the greatest duty to serve.

Perhaps more subtly, I've noticed the loss of the "landmark". We used to say "Meet me under the statue at the State Library, then we'll walk to Joe's Cafe." Now it's just "Meet me at Joe's Cafe". There is an implicit assumption that didn't exist 20 years ago; that everyone can navigate directly to any named location. Without access to a smartphone, impromptu gettogethers are more awkward to organise; my friends will often receive from me a text disrupting the flow: "Where is that near?".

QR Codes And Authentication

I see a QR code and I throw up in my mouth a little.

Coffee shops have replaced punch cards with apps, restaurants offer digital loyalty deals, and you can save on groceries with app exclusive discounts. Again, the irony is that these systems have become inaccessible to people who would most benefit from these cost savings.

Security has also become smartphone dependent. Two-factor authentication is often only implemented via an app, and not over text, or better yet, using a hardware key. Logging out of my password manager has on multiple occasions become quite a headache to recover from, so much so that I've moved my password management to the Linux tool pass. I've even fallen victim to public WiFi that needed to authenticate over email!

My least favourite QR code story is when I attended an event at my local parish. For the purposes of child safety, we were asked to log our attendance. The catch, of course, was that there was no option to log my attendance manually, only via a QR code. I ended up asking a stranger to borrow their phone to sign in, but I haven't been back since cause the whole thing was a bit awkward.

Every QR code has become a reminder that the infrastructure we rely upon is increasingly reliant upon smartphone ownership.

You're Always Contactable

The biggest shift I've noticed is how my inability to be constantly contactable frustrates others. Our new social contract assumes everyone can instantly respond to texts, access shared links, and conduct impromptu research.

When I am sent a video or article over text, a delayed response can be seen as purposely disengaged, when the underlying reason is that it is reasonably inconvenient to respond to at that moment (texting with a dumbphone), or that I lack the ability to contextualise the message ("Hey what do you think about this video?").

A common frustration for myself is receiving an image over text. I can rarely see the content contained within them on a small screen, if they even load on my dumbphone at all! Worse still is that there is no easy way of communicating that you can't view the image without responding via a text that may take a couple of minutes to write. Yet again, we encounter an irony, that you can't easily communicate that you can't easily communicate.

Perhaps most telling for me is how saying "I'll need to check my calendar" has become a euphemism to decline an invitation. For those of us without a smartphone, we legitimately need to check our calendars, as it's unlikely we're carrying them in our pocket that very second. However, this can be seen as flakiness without explaining the context of not having a smartphone.

Conclusion

My choice to use a dumbphone has made me reflect on just how much of what we consider "choice" in technology adoption has actually become an unreasonable necessity to participate in the economy and society.

Ultimately, switching to a dumbphone in 2025 isn't just about personal discipline, unfortunately, it's also about opting out of infrastructure that increasingly assumes universal smartphone adoption.