Bespoke Software

Twelve Tools In Twelve Weeks

Last Updated 2025-10-06

Over the past few months, I've built dozens of tools that have fundamentally changed my daily workflow. None of them would have been worth building without AI, and all of them paint a picture of an emerging category of software I call "bespoke software"; tools that demonstrate why the current debate about AI code quality misses the point entirely.

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:

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:

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

Here is a breakdown of how it was built.

spellbound.nvim

Chronos

Project Therese

No screenshot because you're looking at it!

Chronos Sync

Chronos Sync serverless architecture diagram

Hammerspoon switcher

Qutebrowser Jump to Audio

Youtube RSS Copy

Failed Lazyorg Fork

Rolodex

Tmux Quick Switch

Selfhosted RSS Infrastructure

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

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

Collaborative

Architectural

Iterative

Vibed

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

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: