DEV Community: Benjamin Touchard

I shipped a 20-feature DevOps tool solo in 60 days using Claude Code — the unfiltered breakdown

Benjamin Touchard — Thu, 07 May 2026 18:50:15 +0000

TL;DR — I built Maintenant, a 20-feature monitoring tool (Docker + Kubernetes + endpoints + certs + alerts + status page + MCP server), solo, in two months, with Claude Code. AGPL-3.0 open-core, Pro tier at €29/month, real users in production. This post is not a pitch. It's the honest breakdown — what actually got 10x'd, what completely wasted my time, what I'd never claim about AI coding, and why the code was probably the easiest part. If you're a senior dev considering whether to bet on LLM-augmented development, this is what the inside actually looks like.

Everyone's writing "I built X with AI" posts. This one tells you what they leave out.

What I actually built

Maintenant is a Go binary that runs on about 17 MB of RAM at idle. You drop it into a container and it auto-discovers your Docker, Swarm and Kubernetes workloads, watches your HTTP and TCP endpoints, your cron jobs through heartbeats, your TLS certificates, the resource usage of every service, detects images with updates available, flags dangerous network configurations — exposed database ports, 0.0.0.0 bindings, privileged containers — exposes a public status page, and ships alerts through webhooks, Discord, and on the Pro edition Slack, Teams, and email. It also ships an embedded MCP server with OAuth2 so an AI assistant can query your infrastructure directly. Everything is stored in SQLite with WAL, no external dependencies. No Postgres, no Redis, no message queue. The Vue 3 + TypeScript + Tailwind frontend is embedded into the binary through embed.FS. One Docker image, one process, zero orchestration.

I built it alone. AGPL-3.0 open-core, Pro edition at €29/month for agencies and freelancers managing client infrastructure, with a CLA for external contributors. License keys signed with Ed25519, delivered through an environment variable. Marketing site on Hugo + PocketBase handling Stripe checkout and license verification. Full documentation. And I built all of it by working with Claude Code in a continuous loop.

This is where most "I built X with AI" posts derail. They tell you about the excitement, the screenshots, the "look ma, no hands" energy. This one does the opposite.

The honest timeline (this is where most posts lie)

I started in March 2026, even though I'd been mulling the idea over before that. So two months, two and a half months of serious work to arrive at what I just described — twenty features, dual-licensing, marketing site, documentation, MCP server.

Which wouldn't have been possible if I were discovering Claude Code at the same time as I was building Maintenant. I've been using Claude Code daily for about a year and a half — on other projects, on client refactorings, on explorations that ended up in the drawer. The custom skills, the verification reflexes, the instinct for when to frame tightly versus when to let it breathe: all of it pre-existed Maintenant. The product was built on accumulated practice, not discovered during construction.

That distinction matters because it changes what this article can promise. If you start today with Claude Code and aim for twenty features in two months, you're going to wreck yourself. Not because the tool doesn't allow it — it does — but because practice with the tool is itself an investment, and the short two months only work on top of eighteen long months upstream.

Why Maintenant exists in the first place

People who run Docker seriously always end up with the same stack: Uptime Kuma for uptime checks, Portainer or Dozzle for containers, a cron script for TLS certificates, a half-configured Grafana for metrics, and a status page running on a public Notion. Five tabs, five databases, five alerting layers that don't talk to each other.

Maintenant replaces all five. Not because it does each one better than the specialist — Grafana will always be more powerful for metrics. But because the friction of juggling five tools costs more than the quality delta on each one. When you're chasing a problem you want to see the container state, recent logs, the HTTP check hitting it, the certificate of the endpoint and the CPU consumption all on the same page. Not by swiping between five dashboards.

The principle is strict: observe, never act. Maintenant doesn't restart anything, doesn't pull anything, doesn't touch anything. It's a witness. That simplifies the code, the security model, and the trust a client places in the thing they deploy. Read-only is non-negotiable.

It's a product that has a reason to exist independently of who built it or with what. That matters for the rest of the post.

What Claude actually 10x'd

First thing to clarify: I'm a senior Go developer, fractional CTO, and I've been doing web work for twenty-five years — I was hosting PHP and Flash sites on dedicated LAMP servers back when "DevOps" wasn't a word yet. I'm not learning how to code with an LLM. So when I say "Claude accelerated me", I'm not talking about "it wrote the code I couldn't write". I'm talking about bandwidth.

The frontend, for one. My daily stack is Go, backend, network protocols, systems work. Vue 3 with TypeScript and Tailwind is not my home turf. I can do it, but slowly, second-guessing the conventions, losing time wondering if this should be <script setup> or an explicit Composition API. With Claude knowing the stack better than I do, I attack a new component as if I had a frontend dev sitting next to me. Not so it makes the calls — I decide architecture, UX, visual conventions — but so it carries the cognitive load of the framework. The result: a real-time dashboard with uPlot charts, PWA support, SSE streaming, that would have been a project of its own in a classic solo build.

Scaffolding new modules, same story. The MCP server with its OAuth2 PKCE flow and refresh token rotation. The OSV.dev scan for CVEs with risk scoring. The network insights that inspect OCI manifests to map images to their software ecosystems. Each is a feature that takes two to five solid days in classic mode: read specs, understand APIs, write code, test. With Claude, I spend those two to five days validating, refining, integrating cleanly into existing architecture. Going from blank file to a working first draft happens in an afternoon. It's not just faster — it's qualitatively different. The friction of starting a module disappears, so I start things I would have indefinitely postponed.

Mass refactorings. By the time Maintenant crossed ten internal services, the initial architecture cracked. I was sitting on a six-hundred-line main.go that wired everything in the wrong order, with latent circular dependencies and an event bus typed through interface{}. Refactoring that by hand is three weeks of pain — breaking five things on every commit, adding tests that didn't exist. With a go-refactoring skill I wrote for Claude — encoding my conventions for typed events, App container extraction, dependency injection, test coverage patterns — I shipped the refactor in four days. Coverage went from embarrassing to respectable. Zero regressions in production.

Everything that isn't code. The docs that track the code closely instead of drifting. The cold-email pitches to tech YouTubers and journalists, contextual rewriting every time, the chore every solo dev procrastinates on. The LinkedIn copy, in casual French dev tone, with the link in the first comment to dodge the algorithm's shadow-ban. Article drafts, exactly like this one. The Pro landing page copy. Terms of service, DPA, legal mentions. All that overhead that historically leaves a solo dev with a great product and anemic communication.

This is where the leverage gets unreasonable. The code is still mine, under my control, with my architectural choices. But the twenty-eight other things that make a product actually exist — documentation, website, communication, outreach, billing, legal — suddenly become possible at a level that was out of reach for one person.

What completely wasted my time

If I stopped here this article would be sellable and dishonest. Here's the honest part.

Feature hallucinations. Several times Claude generated content — for LinkedIn, for the docs, for a pitch — that mentioned alert channels Maintenant doesn't have. Telegram, Gotify, Ntfy. None of these exist in the product. They exist in Uptime Kuma, in self-hosted culture, so statistically they emerge whenever monitoring is the topic. If I hadn't reread, I would have shipped false claims that would have torpedoed my credibility. The cost isn't in the correction — it's in the constant vigilance. Every output, I have to go back to the README and verify. The verification cost is constant. It does not decrease over time.

Over-engineering when scope isn't bounded. When I look at my own Claude Code usage data — 263 commits across 90 sessions, around 440 cumulative hours — the most frequent friction pattern isn't factual hallucination, which only fires 2 times over that period. It's "wrong approach" (31 incidents) and "misunderstood request" (25). A 56-to-2 ratio between scope drift and hallucination. The conclusion is sharp: my specs were clear, but Claude drifted toward over-engineering anyway. A refactor that wanted to factor out two things that had nothing to do with each other, an extra abstraction layer to "prepare for the future", a gitignored baseline file force-added because some tasks.md mentioned it — costing me a rebase to roll back. The dominant risk isn't that the LLM invents false things. It's that it does correct things you didn't ask for. The fix is mechanical: "you touch X, you do not modify Y, and you don't factor out anything that wasn't explicitly requested", at the start of every task.

Misdiagnosis before verification. Adjacent pattern, different mechanism. Claude proposes a root cause, declares it fixed, and you have to force it to reproduce the bug before proposing a fix. It's not a capacity issue — on sessions where I push it to reproduce concretely, read the logs, test the request before proposing a correction, it gets it right. It's an instinct issue: by default the model jumps to the conclusion. The fix is in the default prompt: "reproduce the bug before proposing a fix", and always anchor the environment and the layer at the start of any debug. It's a framing discipline, not a model limit.

The SaaS detour. At a moment of commercial doubt, I explored offering Maintenant as SaaS with a client-side agent. It's a seductive architecture for an LLM — opens up plenty of technical directions. Except for my target audience, sysadmins and CTOs who care about data sovereignty, the SaaS model destroys the pitch. I lost a week exploring it before reverting to self-hosted only. The LLM couldn't have known on its own that this direction was strategically wrong — that's a cost on me for not framing it from the start.

The cost of custom skills. All the advantages I described above don't exist out of the box. They exist because I wrote skills that encode my conventions, my rules, my anti-patterns. go-refactoring, mobile-first-audit for the Vue/Tailwind frontend, linkedin-post-generator for the casual French tone, linkedin-lead-capture for analyzing comments on my posts, linkedin-trend-research for the editorial radar. And on top of that, I built Maintenant following the GitHub Spec Kit workflow — spec-driven development that forces you to articulate the need, the plan, and the breakdown into atomic tasks before writing a single line of code. Without that discipline, outputs scatter in every direction. With it, they converge. But writing skills takes time. Maintaining them too. And adopting Spec Kit takes discipline at the moment you'd be tempted to "just go fast". It's a real investment, not a free lunch.

The trade-off between velocity and understanding. Some modules Claude helped me scaffold quickly, I understand less deeply than if I had written them line by line. It's a different kind of technical debt: I could re-read and own them, but every time I haven't taken that time, I'm less equipped to intervene quickly when a bug surfaces. On critical modules, I re-read. On peripheral modules, I let it slide. Conscious trade-off, but it has a price.

The real shift no one talks about

If I had to isolate the thing that changed the most between building Maintenant with Claude versus building it alone, it wouldn't be the speed of writing code. It would be the ratio between dev time and everything-else time.

Historically, a solo developer spends eighty percent of their time on code and neglects the rest. Documentation rots. The marketing site is ugly. LinkedIn copy doesn't exist. YouTube pitches never go out. Terms of service come from a template found on some blog. The product is technically solid and commercially invisible.

With a well-orchestrated LLM, that ratio inverts. Code stays central but takes up less absolute mental space. Documentation gets updated in near real-time because writing 200 words takes two minutes. The marketing site gets iterated on every week. LinkedIn copy becomes a morning routine. Cold-email pitches to YouTubers — DB Tech, Christian Lempa, Techno Tim, NetworkChuck — go out in series instead of marinating six months in a draft. Terms of service get reviewed, the DPA exists, the legal page is up to date. The product takes the shape it should have had all along.

And that's not code. It's an organizational shift. The solo developer of 2026 who knows how to orchestrate an LLM can hold a product surface that in 2022 required a team of three or four people — a developer, a technical writer, a part-time commercial, a community manager.

Here's the line worth keeping:

The LLM doesn't lift a junior to senior level. It lifts a senior to team-of-four level.

Individual skill is still the ceiling. But the cost of the surrounding activities — which historically consumed the developer's energy — collapses. So the same skill can cover much more product surface.

What I'd actually tell you to do

If you want to do the same — not necessarily a monitoring product, any ambitious solo project — here's what works for me, in order of priority.

1. Write custom skills early. Not after six months when you're sick of re-prompting the same conventions. The third time you correct the same thing, that's a skill. Mine run between two hundred and a thousand words; they encode anti-patterns, architecture rules, tone, references. They transform Claude from "smart intern with no context" into "colleague who knows your codebase".

2. Use a structured spec workflow. For non-trivial features, I use GitHub Spec Kit — a spec-driven development framework that produces a spec, an implementation plan, and an atomic task breakdown before any code gets written. The thinking phase is explicit and critiquable upfront. This prevents drift because you catch wrong directions at the markdown stage instead of at the two-thousand-lines-to-revert stage.

3. Interrupt firmly and early. The cost of a late revert is ten times the cost of a quick "stop, you're overflowing". When Claude starts touching things you didn't ask about, factoring out things you didn't request, claiming something works without verifying — don't hesitate. Cut, redirect, force the restart. The difference between a session that ends clean and one that ends in technical debt is almost always interruption latency. The longer you wait, the more expensive the rollback.

4. Verify every factual claim. Every feature mentioned in a post, a pitch, a doc — back to the README. Every number — verify. Every competitive comparison — verify. The LLM is an excellent generator of plausibility; it doesn't distinguish true from plausible. That's your job and it stays your job.

5. Keep strategic decisions to yourself. The LLM can explore directions, weigh technical trade-offs, propose architectures. It cannot decide your market positioning, your licensing model, your commercial target, your pricing. Those decisions you take alone, or with other humans who know your context. Otherwise you end up with a lost week on a SaaS detour.

6. Invest in the everything-but-code. This is where leverage is strongest and where solo developers have historically been most behind. Documentation, communication, outreach, legal, billing. If all you do is code better, you miss nine-tenths of the gain.

The bottom line

Maintenant exists. It has GitHub stars, Docker pulls, users opening issues and discussions on the repo. The Pro tier has conversions. The product isn't a "look what I built with an AI" demo — it's something people actually use in production on their dedicated servers and client infrastructure.

And it exists only because I was able, alone, to maintain a product surface that would have required a small team three years ago. That's the real story. Not the AI that codes. The orchestration skill that multiplies a senior developer.

Code doesn't disappear. Craft doesn't disappear. Architectural rigor, test discipline, critical reading of every output, domain knowledge — all of it remains indispensable, and even more so than before, because without those guardrails an LLM produces pretty plausible content that ships to production and sinks you. But the ratio between "what you can do" and "what you can ship" has changed radically.

For a solo developer with a clear vision, this is probably the best time to be building since the invention of the web framework.

If you got something out of this

⭐ Star Maintenant on GitHub if you want to follow what comes next — I'm shipping a new module roughly every two weeks
🚀 Try Maintenant on your stack — single Docker container, AGPL-3.0, free community edition
💬 Drop a comment with your own LLM-coding war stories. I'm especially curious about the workflows other senior devs have settled into.
🔁 Follow for follow-up posts: I'm planning a deeper dive on the custom skills setup and how I run Spec Kit on real product work specifically.

About me

I'm Benjamin Touchard, senior Go developer and fractional CTO, building Maintenant under the Kolapsis brand from Bordeaux, France. I write about LLM-augmented development, self-hosted infrastructure, and what solo product building actually looks like in 2026. Find me on GitHub or LinkedIn.

Your Docker Stack Is Running. But Is Anyone Actually Watching It?

Benjamin Touchard — Sat, 02 May 2026 12:23:20 +0000

You deployed your app. It runs. The containers are green. Job done, right?

Except here's what's probably happening right now on your production server and you don't know about it:

That Postgres container is listening on 0.0.0.0:5432 because you forgot to scope the port binding
Your MariaDB image has a critical update (11.4 → 12.2.2) that's been sitting there for weeks
One of your SSL certificates expires in 6 days
That "temporary test container" you spun up on Friday afternoon is still running, exposed to the internet, and it's now Monday
Your nightly backup cron job silently stopped working 3 days ago

Nobody's watching. Because setting up proper monitoring for a Docker stack is a pain, so most of us just... don't.

Let's talk about why that's a problem, what the existing solutions look like, and why I ended up building my own.

The numbers are worse than you think

SSL certificates: the ticking time bomb

72% of organizations experienced at least one certificate-related outage in the past year. 34% had multiple. The average outage takes 2.6 hours to identify and 2.7 more to fix.

And it's about to get much worse. As of March 2026, the CA/Browser Forum is phasing certificate validity down from 398 days to 200 days — and eventually to 47 days by 2029. That means you'll go from renewing certs once a year to roughly 8 times a year. Manual tracking with a calendar reminder? Good luck.

Microsoft Teams went down for hours because of an expired certificate. Spotify had an outage on their podcast platform for the same reason. The US government had 80 certificates expire at once, taking multiple government websites offline. These aren't small companies with junior sysadmins — these are organizations with entire security teams.

If it happens to them, it's happening to your production servers too.

Container security: what you can't see can hurt you

37% of organizations reported container or Kubernetes security incidents in 2024. The most common attack vectors? Vulnerable base images (32%), containers running as root (28%), and exposed Docker sockets (18%).

In November 2025, researchers found over 10,000 Docker Hub images leaking live production credentials — API keys, cloud tokens, database passwords — from more than 100 organizations, including a Fortune 500 company. A national bank's architect had hundreds of public images on a personal Docker Hub account, several leaking internal infrastructure credentials.

And that's just the stuff that makes the news. What about your Redis container that's been running in privileged mode since that debugging session last month? Or the MongoDB port you exposed for "quick testing" that's still binding to 0.0.0.0?

The container you forgot about

We've all done it. You spin up a container for a quick test on a staging or production server — a database, a cache, a random API service. Someone pings you on Slack, you context-switch to something urgent, and the container sits there. If it's Friday afternoon, it sits there all weekend. With an open port. On a public-facing server.

No alert. No notification. No dashboard telling you "hey, this thing is exposed and probably shouldn't be."

The attack surface of your infrastructure is not what you think it is. It's what you deployed plus what you forgot you deployed. And when you manage multiple servers or client environments, the problem multiplies.

What about monitoring tools? Yes, they exist. About 15 of them.

The monitoring landscape in 2026 is not a lack of options — it's an excess. About 75% of Kubernetes environments use Prometheus. Most serious setups pair it with Grafana, cAdvisor, and AlertManager. That's already 4 containers just to watch your other containers.

Here's what a "proper" monitoring stack looks like for a typical production Docker setup on a dedicated server:

What you need to monitor	Tool	Additional containers
Container metrics (CPU/RAM)	Prometheus + cAdvisor + Grafana	3
HTTP endpoint uptime	Uptime Kuma	1
Cron job monitoring	Healthchecks.io (or self-hosted)	1
SSL certificates	A bash script, or... another tool	0-1
Image updates	Manual `docker pull`, or Watchtower	0-1
Status page for users	Cachet, Statusnook, or another tool	1
Total		6-8 containers

And that doesn't even cover network security analysis (exposed ports, privileged containers) or CVE detection on your running images. For that you'd need to add something like Trivy or Grype, plus custom scripting to scan your running containers.

Let's look at what this actually means in docker-compose terms.

Prometheus + Grafana + cAdvisor (container metrics)

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    ports:
      - "8080:8080"

  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

volumes:
  prometheus_data:
  grafana_data:

That's 4 containers, 3 config files to maintain, and you still need to write PromQL queries and build Grafana dashboards before you see anything useful.

Uptime Kuma (HTTP/TCP checks)

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    volumes:
      - uptime-kuma_data:/app/data
    ports:
      - "3001:3001"

volumes:
  uptime-kuma_data:

Simple, clean, but it only does endpoint checks. It doesn't know about your containers, their resource usage, their images, or their network exposure.

Healthchecks.io (cron monitoring)

services:
  healthchecks:
    image: healthchecks/healthchecks:latest
    environment:
      - SITE_ROOT=https://checks.example.com
      - SECRET_KEY=your-secret-key
      - DB=sqlite
    volumes:
      - healthchecks_data:/data
    ports:
      - "8000:8000"

volumes:
  healthchecks_data:

Another container, another UI, another set of credentials.

The total cost

At this point you're running 6+ monitoring containers to watch 20 containers. That's a 30% overhead ratio just for observability. Each tool has its own UI, its own alerting config, its own data store. None of them talk to each other. None of them give you a single view of "is my stack healthy?"

And you still don't have SSL monitoring, image update detection, or network security analysis.

This is over-engineering for a fundamentally simple need: knowing if your stuff is running, safe, and up to date.

Why most people don't monitor properly

It's not laziness. It's friction.

The Prometheus+Grafana stack is incredibly powerful — it's what runs Google-scale infrastructure. But for a team running 10-50 containers on a dedicated server or a small cluster, it's like using a Formula 1 pit crew to check the tire pressure on your daily driver. The setup time alone kills the motivation, and then you have to maintain it.

So what actually happens?

You deploy Uptime Kuma for the HTTP checks because it's easy
You tell yourself you'll add proper metrics "later"
"Later" never comes
You find out about problems when users complain or when you SSH in and something is red

Sound familiar? Yeah, me too.

So I built the thing I wanted

After running this exact fragmented setup for way too long, I decided to build what I actually needed: one container that does all of it.

Maintenant is a single Docker container that monitors your entire stack. You mount the Docker socket (read-only — it never touches your containers) and in 30 seconds you have:

services:
  maintenant:
    image: ghcr.io/kolapsis/maintenant:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc:/host/proc:ro
      - maintenant-data:/data
    ports:
      - "8080:8080"
    environment:
      MAINTENANT_ADDR: "0.0.0.0:8080"
    restart: unless-stopped

volumes:
  maintenant-data:

That's it. No config file. No PromQL. No Grafana dashboards to build. It auto-discovers everything on first start.

What it covers

Container monitoring: every container is tracked the moment it starts. State changes, health checks, restart loops, CPU/RAM/network/disk per container. Grouped by Compose project automatically. Top consumers view to spot the greedy ones.

HTTP/TCP endpoint monitoring: define probes via Docker labels — no config files, no UI clicks. Maintenant picks them up when the container starts:

labels:
  maintenant.endpoint.http: "https://api:3000/health"
  maintenant.endpoint.interval: "15s"
  maintenant.endpoint.failure-threshold: "3"

Heartbeat/cron monitoring: create a monitor, get a URL, add one curl to your cron job. Maintenant tracks start/finish times, durations, and alerts when a job goes missing.

curl -fsS -o /dev/null https://your-instance.com/ping/{uuid}/$?

SSL/TLS certificate tracking: auto-detected from your HTTPS endpoints, plus standalone monitors for any domain. Alerts at 30, 14, 7, 3, and 1 day before expiry. With certificates moving to 200-day validity this year and 47 days by 2029, this isn't optional anymore.

Update detection: scans OCI registries (Docker Hub, GHCR, etc.), compares digests and semver tags. Flags critical version jumps — like that MariaDB 11.4 → 12.2.2 that you might have missed. No more running docker pull manually and hoping for the best.

Network security analysis: automatically scans your containers' network configuration and flags risky patterns — database ports exposed on 0.0.0.0, containers in privileged mode, host-network mode, and for Kubernetes, NodePort/LoadBalancer without NetworkPolicy. This is the "test container you forgot about on Friday" detector.

Public status page: built-in, customizable, auto-reflects your monitor states. No manual update needed — if something goes down, your status page shows it.

The stack

Single Go binary. Less than 20 MB of RAM at idle. SQLite in WAL mode — no Postgres, no Redis, no external anything. The Vue 3 frontend is embedded in the binary via Go's embed.FS. Real-time updates via SSE.

One container instead of six. Same coverage, fraction of the resources.

It's also a MCP server

Maintenant has a built-in Model Context Protocol server. You can query your infrastructure health, read container logs, and check alert status from Claude or any MCP-compatible AI assistant. Because in 2026, your monitoring tool should be queryable by your AI tools too.

The business model (I'll be upfront)

Maintenant is open-core under AGPL-3.0. The full codebase — including Pro features — is visible on GitHub. Nothing is in a private repo.

The Community Edition is the real product: containers, endpoints, heartbeats, SSL certificates, update detection, network security insights, status page, Kubernetes support, Webhook + Discord alerts. Monitors defined via Docker labels are unlimited. Manually added monitors have soft caps (10 endpoints, 10 heartbeats, 5 standalone TLS certificates) — generous enough for most setups, and label-driven config is the recommended approach anyway.

The Pro Edition (29€/month or 290€/year) lifts all limits and adds Slack/Teams/Email (SMTP) alerts, alert escalation and routing, CVE detection via OSV.dev, security posture dashboard, incident management, maintenance windows, and subscriber notifications.

I'm a solo developer. This is how I sustain the project. If the free edition covers your needs, that's the intended experience.

Try it

docker compose up -d
# open http://localhost:8080
# your containers are already there

GitHub: github.com/kOlapsis/maintenant
Website: maintenant.dev
Documentation: docs.maintenant.dev

If you've been running the "5 tabs and a prayer" monitoring setup on your production servers, give it a try. It takes 30 seconds and replaces a lot of duct tape.

Whether you manage a single dedicated server or multiple environments for your clients, Maintenant gives you the full picture from one container.

I built two open-source tools faster by letting AI write most of the code

Benjamin Touchard — Sat, 20 Dec 2025 11:20:40 +0000

Over the past weeks, I built two open-source projects:

one in a few weeks,
the other in a few days.

Not because I rushed.
Not because they are toy projects.

But because I changed who types the code.

What actually changed (and what didn’t)

I didn’t “let AI build a product”.

I still:

define the architecture,
decide what exists and what doesn’t,
control data models,
review every line,
say no very often.

What changed is simple:
I don’t type most of the code anymore.

The AI does.

This is not about prompts or magic

This has nothing to do with:

clever prompts,
autonomous agents,
“vibe coding” without thinking.

It works because:

I know exactly what I want,
I know when something is wrong,
I know how the system should behave.

The AI is fast.
I am precise.

That combination matters more than prompts.

How I actually use AI to code

My workflow is closer to this:

I describe very precisely what needs to be implemented
The AI writes the code
I read it like a strict reviewer
I ask for corrections, refactors, deletions
I integrate or reject

The AI writes faster than I ever could.
I think slower, but better.

It feels very similar to:

the first smart autocompletion,
then IDE refactoring tools,
then real-time linting.

Same shift. Bigger scale.

Two different projects, same approach

Ackify

Ackify is an open-source tool to handle internal document acknowledgements:
proof that people actually read internal policies, procedures, or mandatory documents.

It required:

a clear domain model,
strong constraints,
no feature creep.

AI helped write:

handlers,
storage layers,
repetitive logic.

I stayed in control of:

scope,
semantics,
guarantees.

SHM

SHM (Self-Hosted Metrics) is much smaller.
It answers one question:
“Is this self-hosted app actually used?”

It was built in days because:

the scope was tiny,
the rules were strict,
the AI handled most of the boilerplate.

Different scale.
Same method.

AI as a force multiplier, not a decision maker

The biggest misunderstanding about AI-assisted coding is thinking it replaces thinking.

It doesn’t.

It replaces:

typing speed,
mechanical repetition,
obvious glue code.

The moment you stop knowing what you want,
the output degrades immediately.

AI is not creative in architecture.
It is efficient in execution.

Why this matters for solo developers and open-source

For solo developers, time is the real constraint.

AI doesn’t give you ideas.
It gives you throughput.

That makes it possible to:

explore ideas faster,
kill bad ones earlier,
finish small useful tools instead of polishing one forever.

That’s exactly how many open-source needs are met:
small tools, precise scope, fast iteration.

Closing thoughts

I don’t feel replaced by AI.
I feel amplified.

I still design.
I still decide.
I still review.

I just don’t type as much anymore.

And that’s fine.

Proving people actually read internal documents is still a mess

Benjamin Touchard — Sat, 20 Dec 2025 11:15:33 +0000

I’ve worked on internal tools, compliance processes, and regulated environments for years.

And there is one recurring problem that almost everyone underestimates:

How do you prove that people actually read internal documents?

Not signed contracts.

Not legal agreements.

Just things like:

internal procedures
security policies
onboarding documents
mandatory trainings

The answers are usually disappointing.

How this is usually handled

In most teams, it looks like this:

a PDF sent by email
a shared folder or intranet page
a checkbox in a form
sometimes a signature on paper

When someone asks:

“Can you prove that employees read this document?”

The answer is often:

“Well… we sent it.”

That’s not proof.

And in audits, that difference matters.

Why existing tools don’t really fit

There are many tools for:

e-signatures
contract management
document workflows

They are usually:

heavy
expensive
SaaS-only
designed for legal or sales use cases

They solve problems like:

signing contracts
closing deals
external compliance

But internal acknowledgements are different.

They are:

frequent
low-risk
internal
boring but mandatory

Using a full contract-signing platform for that feels excessive.

What I actually needed

From a technical and operational point of view, I needed something simple:

prove that a document was presented
prove that it was acknowledged
keep a verifiable record
without managing contracts or identities manually

No document storage SaaS.

No legal framing.

No complexity.

Just proof of read, done properly.

A pragmatic response: Ackify

So I built Ackify, an open-source tool focused on one thing:

Internal document acknowledgements.

Ackify:

generates acknowledgement requests
records confirmations
produces verifiable proof
stays simple by design

It’s not a replacement for legal signature platforms.

It’s a tool for internal compliance and operational needs.

👉 Repository: https://github.com/btouchard/ackify-ce
👉 Website: https://ackify.eu

Why this problem is mostly ignored

Internal compliance is not shiny.

It doesn’t:

generate revenue directly
impress investors
fit growth dashboards

But it costs time, energy, and stress when done badly.

Big platforms optimize for contracts and transactions.

Small teams just need clarity and traceability.

This gap is where many open-source tools live.

Closing thoughts

Not every problem needs an enterprise platform.

Some problems just need:

a clear scope
a simple workflow
and reliable evidence

Internal acknowledgements are one of them.

Why I refuse to ship Google Analytics in open-source projects

Benjamin Touchard — Sat, 20 Dec 2025 11:03:15 +0000

I build open-source applications, most of them self-hosted.

Like many developers, I need metrics. Not marketing metrics. Just basic signals:

Is the application actually used?
How many instances are alive?
Which features are used at all?
And for a long time, the default answer was obvious: Google Analytics.

But at some point, I decided to stop shipping it entirely.

Google Analytics is a poor fit for open-source and self-hosted apps

Google Analytics is not a bad tool. It’s just built for a completely different purpose.

It assumes:

a centralized SaaS product,
tracked end-users,
marketing funnels,
cookies, consent banners, and external dependencies.

None of that aligns well with self-hosted open-source software.

Embedding GA in an open-source app means:

sending usage data outside the user’s infrastructure,
introducing legal and privacy concerns you don’t control,
tracking individuals when you only want aggregate usage.

At that point, the cost (technical, ethical, cognitive) is higher than the value.

Existing alternatives didn’t really solve my problem

I looked at many “privacy-friendly” or “self-hosted” analytics tools, like Countly, PostHog, ...

Most of them still assume:

websites, not distributed instances,
user tracking (even anonymized),
dashboards designed for marketing teams,
heavy setups for very simple questions.

What I needed was much simpler.

What I actually need as a developer / CTO

For open-source and self-hosted software, my questions are boring but essential:

Is this instance still running?
Is anyone using this feature?
Is adoption growing or stagnating?
Did this release break usage patterns?

I don’t need:

page views,
funnels,
session replay,
user identity.

I just need signals, not surveillance.

A pragmatic response: build something smaller

So I built a small open-source service called SHM (Self-Hosted Metrics).

It’s intentionally minimal:

it accepts simple JSON events,
it doesn’t track users,
it’s agnostic to the application,
it works well with self-hosted deployments.

The goal is not analytics.
The goal is observability of usage, without violating the principles of open-source or self-hosting.

Repository:
👉 https://github.com/btouchard/shm

What this says about the open-source ecosystem

A lot of real needs sit between:

“no metrics at all”
and “full SaaS analytics stacks”

Big tools don’t care about these needs.
They’re not scalable, not monetizable, and not flashy.

But for maintainers, indie developers, and small teams, they matter.

Not everything needs to be measured like a growth funnel.
Sometimes, knowing that your software is simply used is enough.