DEV Community: Benjamin Touchard

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.