You can just build things

Somewhere around summer 2025 I started taking AI coding agents¹ more seriously. I’d been somewhat dismissive of them for a while - the early versions produced code that looked plausible but fell apart rather quickly. They would often get stuck and make silly mistakes. The newer models are different. Not because they magically write perfect code, but because they’re good enough to be directed. You tell them what to build, how to structure it, and they do the mechanical work while you make the decisions. The code is not the most effective and most beatiful but I don’t really care since I can change it so easily.

It clicked when I rebuilt the core of pixbin.net in about two hours. Pixbin is a super simple image sharing service I’ve been running since 2012 - drag and drop upload, auto-expiring images, shareable links. The codebase was showing its age and I’ve been putting off a rewrite/upgrade for years. With an agent handling the boilerplate while I focused on architecture and review, the whole thing came together in a single sitting on a hot summers day. Django, Celery for background image processing, S3 storage, Kubernetes deployment configs. Two hours. And then I started adding features!

This changed how I looked at my project backlog and list of ideas.

Templates matter more than prompts

Honstly, the biggest unlock wasn’t better prompting - although precise prompts do help. It was having a solid project template. I built hellok8s-django with all my opinions baked in: Nix and devenv for reproducible environments, Docker builds with uv, Helm charts, SOPS for secrets, GitHub Actions CI/CD. And yes I used Agents to make the template as well. Now, when I start a new project, the agent understands the conventions immediately because they’re encoded in the template. No explaining where things go or how deployments work.

This is important because agents are excellent at following patterns but bad at inventing them. If you give an agent a blank canvas you get mediocre code with inconsistent structure. If you give it a well-organized codebase with clear conventions, it produces code that fits right in.

None of this is vibe coding. I’m reviewing every diff, making the architectural calls, fixing the things it gets wrong - it does get things wrong. But the grunt work - the CRUD views, the serializers, the test scaffolding, the Helm values - that’s largely handled. My throughput went through the roof.

Solving the same problems once

Once I had the template and the workflow down, I started noticing a pattern: every project I build needs the same handful of infrastructure services. Email, image hosting, form handling. I’d been solving these ad-hoc per project, or paying for SaaS tools I didn’t really need. So I started building them as shared services that my future projects can use.

Email

Every web app needs email. Registration, password resets, notifications. I was looking at various SaaS services - but I don’t have real users yet for most of these projects. Paying $20+/month for a service that sends maybe 5 messages a month is absurd. Also some of them doing a rugpull and disabling their free tier without notification didn’t help either.

I remember reading a tweet by Pieter Levels about how the economics of AWS SES were just unmatched, and how most of these SaaS services were wrappers around SES. I don’t know if it was this specific tweet but something to that effect. This rang true to me - at least for my needs.

So I built sesy.email. It’s a Django service that wraps AWS SES behind a REST API. You delegate a subdomain (like notify.yourdomain.com), and SESY handles everything automatically: creates the Route53 hosted zone, provisions the SES identity, writes the DKIM CNAMEs, SPF and DMARC TXT records, configures the MAIL FROM domain. It also handles bounces and complaints via SNS webhooks and maintains per-project suppression lists and limits. It’s a clicky web interface with a “next-next-finish” feel to it. I am thinking about making it agent first but haven’t gotten to it yet.

I built Python, JavaScript, and Django SDKs for it. The Django SDK is a standard EmailBackend, so any Django project can use it with two lines of config. SES costs fractions of a cent at my scale. I have this problem solved forever.

Now … being heavy in infra all my life I’m saddend by the steady degradation of the distributed internet and I briefly thought about building the email backend directly but I wanted to get going faster. I may still do it. I mean, I still self host my own email server so why not.

Image hosting

Pixbin already existed, but I gave it a proper API so all my projects can use it for image uploads and processing. Every web app eventually needs thumbnails, resized versions, maybe format conversion. I don’t want to reimplement this per project. Upload an image, get back URLs. Done.

Forms

I was using one SaaS for contact forms on my static sites. I don’t have any beef with them but I built my own replacement: formsubmit.cloud. It’s a Django app - you create a form, get a POST /f/{uuid}/ endpoint, and submissions get emailed to you via SESY. I added Cloudflare Turnstile for captcha, honeypot fields, some basic spam scoring, and webhook support for forwarding submissions to other services.

Then one evening I wanted to organize a dinner with friends. We usually used Doodle for this kind of thing. Doodle now requires registration and has gotten so bloated that it takes genuinely long to load and it’s a pain to use. I built basic scheduling functionality into formsubmit instead. Took an hour or so.

That’s the theme here. Something annoys me, I build a replacement, and it takes an evening instead of a month. The agent does the mechanical work, I make the design decisions, and the template ensures everything deploys the same way and generally reuses the same patterns.

What I’m working on now

A digital products store - inspired by Basecamp’s ONCE model. Pay once, own forever. No subscriptions. Django backend, Stripe for payments with multi-currency support (USD and EUR, geo-detected via Cloudflare’s CF-IPCountry header), pre-signed S3 URLs for file delivery, and GitHub API integration for granting repository access to buyers. Once it’s ready I’ll list SESY there as a purchasable self-hosted product. Haven’t decided yet if formsubmit will be a product or remain a hosted service.

A social media scheduler - just for myself, just Twitter and LinkedIn. Next.js with PostgreSQL. I want to batch-write posts on Sunday and have them go out during the week. Nothing fancy.

And a few more that I’ll talk about in other posts.

The economics

I run everything on a single bare metal instance on Scaleway. Kubernetes, all my services, all my databases, one box. Total cost is the hosting bill plus whatever pennies SES charges me. No per-service SaaS subscriptions, no usage tiers that suddenly spike when you cross some arbitrary threshold. And yes it runs NixOS. :)

Self-hosting has real costs - I maintain the Kubernetes “cluster”, handle ops, keep things patched. But for a single developer building tools for myself this is manageable. And the marginal cost of deploying one more service is effectively zero. That changes the math on what’s worth building.

If a project takes off I change the credentials in the CICD pipeline and point it to a proper kubernetes cluster where I can scale. Easy peasy.

What changed

I haven’t been this excited about computers since I first learned programming, discovered the internet and deployed my first webapp.

The backlog of projects that lived in my head for years is actually shrinking. Ideas that would have stayed in a notes app are getting deployed - even if I’m the only user, at least I’m trying stuff out. I’m also way less tolerant of small annoynaces in my day to day - like on my laptop - I just tell the agent to fix them.

What used to take a week takes a weekend. What used to take a weekend takes an evening. Not because the agent is doing the thinking for me, but because it’s doing the typing. I still need to know what I want, how to structure it, and what a good solution looks like. But the bottleneck has shifted from implementation speed to decision-making speed, and that’s a genuinely different way to work.

You can just build things.