I’ve spent the last decade or so working in production roles, helping teams build and ship games. My background is technical, and I still code now and again, but these days it’s more often to support a team or scratch a personal itch than as part of any formal delivery work.
Recently, one of those itches turned into a small iOS app. Not for work, not for side income—just a tool for my local pétanque club.
They run weekly training sessions—mostly one-on-one and two-on-two—and once a month hold a melee competition, where players rotate through a series of matches with different partners and opponents. It’s a casual setup, but even so, things go more smoothly if someone takes charge of the matchups. The app helps with that. It handles the draw, makes sure it’s random and fair, and allows quick adjustments if someone arrives late or has to head off early. That used to mean redrawing things on paper, which was fine, but not ideal. Now it’s a couple of taps and we’re off again. Same goes for updating the whatsapp channel with results, the club website etc. Nothing rocket sciencey, just an improvement on what we had.
Tinkering, Not Planning
I put it together in Xcode, with a fair bit of help from integrated ChatGPT. I wasn’t trying to prove a point about AI-assisted development—it just made things quicker. I’d hit a layout issue or get stuck on a bit of syntax, ask a question, get a few suggestions, tweak, test, and move on. It was informal and conversational, but surprisingly effective.
What struck me most was how different it felt to the structured, professional process I’m more used to. No roadmap, no feature list, no long-term maintenance plan. It was just a case of trying something, showing it to a few people, adjusting it, and doing the same again. That sort of informal, fire from the hip, flow is often harder to practice in production environments, and for good reasons. But this context was different. It reminded me how satisfying small software can be, especially when the audience is right there in front of you.
A Question of Quality
Not long after the first version was working, I came across a piece on GamesIndustry.biz about the rise of AI-generated shovelware flooding digital storefronts. It raised fair points: if creating software gets easier and incentives remain unchanged, we risk a wave of low-quality apps designed to game rankings and extract money. That’s a real concern—especially for platforms that rely on discoverability, trust, and a sense of quality curation.
But it made me pause. By some definitions, what I’d just built might fall into the same broad category. It was made quickly, helped along by AI, and it’s not designed to scale. On the surface, it ticks a few of the shovelware boxes.
The difference, of course, is intent. This wasn’t churned out to pad a portfolio or trick an algorithm. It was built to solve a problem for a very specific group of people. They didn’t want myriad options, bells and whistles. They just wanted a better solution to take out some of the hassles on a Saturday. That was enough for me to create it, and take a little pride in it, even though it’s not going to win any accolades outside of the clubhouse.
Choosing to Keep It Small
There’s a quiet kind of satisfaction in deciding not to build more than you need. I could have added features—player stats, saved profiles, tournament structure options—but none of those would have improved the experience for the people using it. They would have made the app more complicated, not more useful.
That kind of restraint feels like a skill in its own right, though it’s not one that modern platforms are set up to recognise. App stores are designed to promote growth, retention, and monetisation. That makes sense from a business perspective, but does it means that smaller, more purposeful tools are often overlooked? Or, as I suspect, looked down upon.
If AI tooling makes it easier to create bespoke apps—hyper-specific, functional, and built for a few dozen users—I’m not sure the current app ecosystem knows what to do with them. The stores are marketplaces, not libraries, and their logic favours apps that scale because that’s where the money is. But not everything should. Some software is better when it chooses to stay small.
This is part of why stores like itch.io remain such an important counter-example. They offer a space for experimental, non-commercial, and personal software to live on its own terms. If we want room for more of this kind of app in the mainstream platforms, we might need to rethink how we surface and support them.
Small Software in a Big Software World
None of this is new, of course. Small, personal software has always existed—quietly passed around between colleagues or friends. I’ve known (and been) people who built macros for Excel to run their pub’s fantasy football league, or cobbled together Python scripts to simplify repetitive admin at work. Little apps, never public, never monetised, and all the more useful for it.
What’s changed is the environment. These days, many people use their phones as their primary computing device, and phones don’t work like desktops. You can’t just email someone an .exe or drop a script into a shared folder and expect it to run. Mobile platforms are more tightly controlled—especially iOS, where the App Store remains the main way to distribute apps. There are workarounds, like TestFlight or enterprise profiles, but they’re not designed for casual sharing or personal projects. On Android, it’s technically possible to sideload apps, but the process involves enough friction and security warnings that it’s still far from mainstream.
So even though it’s never been easier to build small, bespoke apps, it’s harder than ever to share them without going through systems that were built for polished, commercial software. The barriers to creation are coming down—but the barriers to distribution are still very much in place.
The Edges of Craft
I’ve been in and around software long enough that I still think about code quality, structure, and maintainability, even on side projects. This was no exception. I found myself wondering whether I’d covered the right edge cases, whether I’d be able to fix it if something broke unexpectedly, or whether I’d let the AI suggest a fix that I didn’t fully understand.
There’s a different kind of uncertainty that comes from working this way. I was still making decisions, still shaping the behaviour of the app, but at times the work felt more like editing than writing. It’s a shift that people like Simon Willison have spoken about—seeing AI as a collaborative tool, a kind of pair programmer who’s occasionally wrong but often helpful.
It’s also pushed me to think differently about what software craft means when you’re not touching every line of code. If the tools are helping more actively with the heavy lifting, then the value comes not just from syntax, but from care—framing the problem well, making good decisions, keeping things focused.
This connects to a much older idea too—what Doug Engelbart called “augmenting human intellect.” These tools don’t replace us, but they do change what it means to do the work. Maybe craft, in this context, is more about what you choose not to build.
Just Enough
This isn’t a big app. It’s not built to scale, or to grow, or to generate income. It’s there to make one part of a weekly routine run more smoothly—and it does. That’s enough.
It reminded me of something I’ve seen across my own career in games. I’ve spent years working in AAA development, on large-scale open-world titles that take hundreds of people and multiple years to build. Those games can be extraordinary—but they’re also complex, expensive, and often weighed down by the very systems that make them possible.
This app was the opposite. Built quickly. Small team (me). Tight audience. Clear goal. Like a good indie game, it didn’t need to offer dozens of features or hours of content. It just needed to be the right tool for the moment. And like the best small games, it was better because it didn’t try to do more than it should.
I think there’s room for more software like that. Tools that don’t pretend to be more than they are. Apps that aren’t designed for millions of users, but are perfect for the few they’re built for. This idea aligns with what Cal Newport calls digital minimalism—technology that is intentional, clear, and fit for purpose.
Not everything has to scale. Not everything has to grow. Sometimes, small is better.
