Tobias Wirtz

Building in Public: Day 8

2026-08-17T07:00:00+00:00

It’s been a few weeks since the last entry. Picking the series back up with a weekend and a Monday worth of Magellink work.

What I shipped

Over the weekend I built the first version of a feature I’d been circling for a while: upload a one-page HTML prototype, the kind you get out of Claude or similar tools in minutes, let real end users click through it, and record what they do.

The ARD conversation

Today I pitched it to the UX research lead at ARD, Germany’s public broadcaster. He was interested, and the reason he gave me was more useful than the interest itself.

ARD runs a lot of quantitative research and some qualitative research, but nothing in between. No way to watch a hundred people react to a prototype the way you’d watch five people in a lab.

What’s still open

Five things came up that I don’t have good answers for yet:

Recruiting. ARD’s own site can’t run third-party recruiting tools, so participants have to come from somewhere else.
Recording face and audio, not just clicks and timing, while someone works through a prototype.
Goal states and success criteria. What “done” means for a given task, defined per prototype.
Monetary incentives for participants.
A research pool. Keeping people who’ve completed a session around so they can be invited back.

Tomorrow

Starting with recruiting and task/success states: get the right people in front of a prototype, watch them try to do something specific, learn whether they could. The rest only matters once that holds up.

Also filming a LinkedIn video relaunching Magellink around this feature.

Building in Public: Day 7

2026-07-22T07:00:00+00:00

I launched the landing page under werkdoku.com.

Building in Public: Day 6

2026-07-21T07:00:00+00:00

I had to work a lot today - could not do anything.

Building in Public: Day 5

2026-07-20T07:00:00+00:00

Day 5. Two things: I shipped the on-prem rebuild that came out of the first interview, and I sat down to think seriously about how I’d ever reach this market at all.

The on-prem rebuild

I turned the on-prem and trust work from day 3 and 4 into a real change.

The interview killed my assumption that “EU-hosted” answers the data-residency objection. This buyer already turns down AI vendors because, in his words, none of them can actually run it locally, and he runs his own local LLM. But he doesn’t want everything local either: quality-assurance paperwork can go to the cloud, bath compositions never. So the rebuild is built around that split:

Data classification. Every department guide is marked internal or secret, and one routing rule decides whether a class can be processed in EU cloud, locally, or not at all. It fails closed: a class this deployment isn’t allowed to handle gets refused and reported, never quietly downgraded to the cloud. The rule binds the live voice call too, not just the write-up, because the transcript contains whatever the interview was about.
Worker trust surface. A concrete, translated reason spoken in the consent script and shown on the link page, a non-surveillance guarantee, role-only attribution so employee names never enter a prompt, and a withdrawal button that actually deletes the transcript instead of flagging it.
On-prem stack. Per-class LLM endpoints, an Ollama + faster-whisper profile bound to localhost, a preflight check to run in front of the customer at handover, and a transparency page that renders the real data flow from live config as an attachment for the works council.

Two follow-up commits added a reminder budget (at most two chase messages, then the name moves to a manager-round list rather than a third SMS) with a coverage view, and fixed the admin UI printing raw status values in an otherwise translated app. 52 tests passing, smoke-tested end to end.

Building on-prem doesn’t validate the hypothesis that on-prem is what unlocks the sale. It just makes the real test possible, which is to go back to this same interviewee with a working local deployment and ask for a paid pilot.

Channel experiments

I wrote up a set of growth bets for werkdoku, borrowing the spirit of a “grow an app for almost nothing” playbook but reframing it, because werkdoku is the opposite shape: a five-figure one-time sale to a narrow, conservative buyer (owner, production manager, or quality manager at 50–500-person mid-sized German manufacturers), not a free consumer download. So the metric for every bet is qualified pilot conversations with the right buyer, not traffic.

Each bet is written as a hypothesis with a signal and a kill/go threshold. The three I’d start with:

A free knowledge-loss risk self-assessment that a production manager runs and forwards to their boss, outputting a euro-quantified risk estimate. It manufactures the pain in the buyer’s own numbers.
The live demo as spectacle at a chamber-of-commerce or industry-association event: interview a volunteer on stage and generate an SOP draft in minutes, which de-risks the “will they let an AI call employees” fear in front of the exact buyer.
The public digitalization and subsidy channel: public programs that exist to push tools like this to this buyer for free, plus checking whether an engagement qualifies for funding.

Tomorrow

Create a landing page.
Plan one of the channel experiments.

Building in Public: Day 4

2026-07-17T07:00:00+00:00

Short one today. I didn’t get much further than designing what needs to change to make werkdoku on-prem, and working in the trust and control aspects that came out of the first interview.

I’m also thinking about building new channels for Magellink.

Building in Public: Day 3

2026-07-16T07:00:00+00:00

Day 3. The list was cold outreach, a Business Model Canvas, and one customer interview. All three got done.

Cold outreach: sent, silent

I sent cold emails to the companies from yesterday’s qualified list. No responses yet. Too early to read anything into it, but worth writing down that the count so far is zero.

Lean Canvas

I built a Lean Canvas to force myself to be precise about what I’m building, who it’s for, and how the money works. Putting it on one page made the weak spots obvious.

The biggest open question that fell out of it is channels. I have “personal outreach” and then a question mark. I know how to reach a handful of companies through my own network and one cold list. I do not yet have a repeatable way to reach the German Mittelstand at scale.

Customer interview

I did one interview with a Mittelstand CEO. Three things came out of it, in increasing order of how much they changed my thinking.

First, the need is real. Documentation is genuinely required, and today they do it with slower, more manual mechanisms. That’s hypothesis 1 getting a little more solid: the pain exists and they already spend effort on it.

Second, on-premise is table stakes. He is currently turning down lots of cloud AI vendor that lands on his desk, because his crown-jewel IP cannot leave the building. I’d been treating “EU-hosted” as the differentiator, but for this segment EU hosting alone won’t be enough.

Third, and this is the one that’s rearranging the whole thing: the hard part isn’t the tech. People resist documenting because they’re afraid it makes them replaceable, sometimes to the point of reporting false numbers so their process stays a black box. Following up with employees to get them to document also took considerable effort.

Hypotheses

Knowledge-loss pain, pay five figures once — small positive signal. The need was confirmed; willingness to pay 5000 euros was confirmed.
Let an AI talk to employees — no new data, but the interview points at why this one is hard: the resistance is about job security, not technology.

Tomorrow

Rebuild into an on-prem solution.
Work in the trust and control aspect from the first interview.
Think about channel experiments.

Building in Public: Day 2

2026-07-15T07:00:00+00:00

Day 2. Three things on the list today: line up interviews, find a way to reach cold customers, and figure out what it actually takes to deploy.

Interviews from my own network

I reached out to people I already know and set up two interviews with contacts for whom this might be relevant. Warm intros first, because the fastest way to find out whether the knowledge-loss pain is real (hypothesis 1) is to talk to people who will actually pick up the phone.

A cold outreach source for ICP customers

I need a repeatable way to reach companies I don’t know. Today I had an AI agent qualify 23 companies against my ICP as a candidate list to reach out to. I will reach out to these companies tomorrow.

What it takes to deploy

I spent time working out what it would actually take to put the MVP in front of a real company, and found two blockers:

Multi-tenancy. The MVP wasn’t built to cleanly separate one customer’s data from another’s. This obviously has to change if I want to deploy it.
US-hosted dependencies. Some of the libraries I’m using are served from American CDNs. Need to be substituted to ensure European hosting and data residency.

On the plus side, I turned the deployment work into a runbook, a written, repeatable set of steps for shipping the MVP, so this isn’t knowledge that only lives in my head.

Hypotheses

No progress on any of my hypotheses today. Everything I did was setup: pipeline, list, infrastructure.

Random Thoughts

I found a great video on growth hacks that I will take some inspiration from. Check it out here.

Tomorrow

Do cold outreach to the 23 companies mentioned above
Create a Business Model Canvas to be very clear about what I am building.
Do one of the customer interviews

Building in Public: Day 1

2026-07-14T07:00:00+00:00

I’m going to build in the open. Every day I’ll post a short entry documenting the work of building a real business: what I shipped, what I learned, what worked, and what didn’t.

The rules are simple: one post a day, numbers, no polishing away the hard parts. The metric I’m using to know I’ve made something people actually want is $20,000 in monthly recurring.

This is day one. Let’s see where it goes.

What I’m building

The first idea I am working is an AI agent that talks to employees in their own language about how they actually do their job, and turns the transcripts into documentation the company keeps: SOP drafts, a process map, a list of the things nobody on the team could explain.

The target customer is the German Mittelstand manufacturer, roughly 50 to 500 people. Two things are colliding there right now. A generation of workers is retiring and taking undocumented knowledge with them, and these companies are often not very digital yet, so they don’t have a lot of data that can feed AI agents even though there is valuable implicit knowledge.

Two things are supposed to make this different and defensible:

Data Residency: Everything is EU-hosted or self-hosted, no US subprocessors anywhere.
Pricing: Mostly one-time fee, low subscription to cover cost.

My hypotheses

Before I believe this is a business, six assumptions have to hold, roughly in order of how much they scare me:

Owners and plant managers feel the knowledge-loss pain strongly enough to pay ca. five figures once.
A company will actually let an AI talk to its employees at all. Works councils, surveillance fears, culture.
Shop-floor workers actually talk usefully for 15 to 20 minutes in their own language.
Interviews alone already produce something a company would call a real first draft of documentation.
The EU-only voice stack is actually good enough on a noisy shop floor.
The one-time-fee economics work once I account for what it costs me to deliver each engagement.

I will be testing these in the next two weeks.

What I built so far

A working MVP someone can sit down and use: upload a list of employees, write an interview guide, run the interview with consent, and get back SOP drafts, a process overview, and a gap list you can export. Interviews work in German, Turkish, and Polish.

Right now it only runs through a browser call, not a real phone call. I’m unclear on whether I need actual calling.

None of this is launched to the public yet because I haven’t set up the infrastructure, but it works locally.

What’s still open

GTM motion: I’m thinking about looking at companies with a succession problem or with a desire to sell as a wedge due to the more acute knowledge problem, I’m not sure about this though.
Branding and naming.

Product & The Long Tail

2025-10-31T10:00:00+00:00

AI is quickly changing the product world. The focus of change however has not been where it should be in my eyes: on enabling the user to solve their specific problems.

The old paradigm

Pre-AI, Products at scaled SaaS companies were built roughly like this:

This process introduced various bottlenecks. Since engineers building certain cost a lot of time and money, ideas had to be filtered excessively such that only the highest value opportunities were pursued. This in turn meant that product teams at scaled companies were focussed on those opportunities that the largest number of customers would pay for. Only the needs of large niches could be addressed economically with SaaS. Within this scope, these businesses often operated efficently while covering all edge cases that engineers of specialized solutions could often not afford to address.

The new AI paradigm

With the new AI paradigm, the promise is that AI engineers can dramatically reduce the marginal cost of building solutions, increasing the number of opportunities that can be addressed. However, the fundamental bottleneck does not get removed, we are just improving the throughput. Ideas are still mostly generated and tested manually by PMs, designers, and engineers, even if they can be prototyped faster. Nevertheless, by increasing the throughput, it has become economically possible to serve the needs of smaller niches.

The Long Tail paradigm

A long time ago, before we had scaled operating systems or the internet, software was written to solve problems of individual users or customers. It was prohibitively expensive, but it catered to these needs perfectly. These days, it would be much simpler to build a comparable solution using tools like Cursor or Lovable, but the cost of maintenance is still high, which means that for companies, it still often makes sense to buy rather than build when it comes to software that isn’t addressing the company’s core mission. You have to trade off maintainability and customizability, which again leads to software that is not being tailored for individual use cases.

Ideally, however, we would like to return to the world of individualized software while being free of its high costs. We would finally have software that does not ignore the long tail of problems that our messy reality creates for us. I think this is becoming possible.

Taking the SaaS approach of spreading out the cost of edge cases within the general domain scope across the user base and combining it with a Lovable-like approach of letting the end user build for their own specialized needs all within one product is where SaaS should go in the next 5 years. SaaS companies would build and maintain a core product and let users build on top of it dynamically using AI.

For more involved use cases, this may seem scary given the capabilities of the current models. Yet one area that is already ripe for this kind of model is analytics. Any SaaS that stores and operates on a single source of truth (SSOT) currently has to provide analytics to their users. Analytics really isn’t core business for these companies because few of their customers will make a buying decision based on the quality of their analytics platform, but if there isn’t one, you will lose customers. This means lots of companies have expensive analytics teams shipping half-baked solutions that are constantly outdated as users keep coming up with more and more questions for which there is not enough capacity to build answers.

Why should there be such teams chasing all these data requests and trying to generalize them, when each end user could just build their own report using AI? Whoever can build a company that abstracts this capability and provides it to your local SaaS will build a generational company.

Confidence Slop

2025-06-29T10:00:06+00:00

Both reading and writing suck now.

Everything seems high quality, little is

I’m sure if you have been on Instagram, Twitter, or, god forbid, Facebook recently, you are no stranger to slop. Slop commonly denotes low effort media that puts quantity over quality. Though hard to precisely define, it is easy to identify. On the other side of this spectrum, I put what I would call confidence slop. Confidence slop is content that appears to be high quality because

the communication is targeted and not too spammy
some human thinking has probably gone into it
AI was used to to communicate the outputs of this thinking in a way that sounds reassuring

Examples of this are status updates in any of your Slack channels that use emojis to highlight important paragraphs and tag all the right people. They all look the same, but they clearly do not all describe the same states of the world. It is relatively easy to define, but to differentiate what is confidence slop and what is actually good work is very hard.

In the above message, many different thoughts are communicated, most of which do not have much impact on decision-making in the future. A little differentiation is made between levels of confidence of certain items. However, the general tenor of the update is “everything is under control” and lots of uncertainty is abstracted away under language that feels like it should give you confidence that everything will go well (e.g. “All blockers have owners and next steps”). Obfuscating this uncertainty is one of the key detriments of confidence slop. The message’s format is almost ideally designed to make the reader’s eyes glaze over and evoke an as-of-yet-undeserved sense of trust. Nevertheless, there is always a lot of truth to confidence slop, making it hard to disentangle what to believe and what to question.

Confidence slop is not new. Some people are predisposed to it and some professions even teach it as a rite of passage. As a PM, I produce it regularly. What has made it ubiquituous however is the availability of AI writing tools.

Combatting confidence slop is much important than normal slop to me. Slop and psychological defense against slop is memetic in that by engaging with slop, most people start to build up mental models that identify and ignore it. Confidence slop is anti-memetic in that it is very hard to identify whether one should actually put stock into a statement or not, so fewer people build up defenses to it.

A forcing function for thought

Confidence slop is not just an intellectual crime against the reader; it is also a crime against oneself. To write is to structure one’s thoughts and to calibrate one’s confidence in them. By engaging in confidence slop, you lose the ability to identify gaps in your thinking. Additionally, you will not be able to look back at a later date and re-evaluate your confidence levels in a certain belief.

I want to be clear: Using AI to write is not bad in and of itself. You just need to make sure it doesn’t make everything sound the same. This seems like a problem software could solve.

A better writing experience

Communicating confidence

The core problem of confidence slop is that it has become too easy to produce it. To combat it, we need to introduce the right amount of friction to the process of writing. I built a small prototype to indicate how this could work.

One approach to do this would be to visually communicate confidence levels. This needs to happen in a non-obtrusive way. My first idea was to play with the font weight as an indicator of the confidence level with faint writing showing low confidence in a belief.

I like this approach because it naturally draws the eye to the beliefs that are low confidence, hopefully allowing the writer and later the reader to think more about whether they should be upheld or not.

Assumptions are second-level

People often try to communicate uncertainty about a belief with a clarifying comment on their own document. This also achieves drawing the eye, but it does not allow you to easily prioritize which uncertainty to address first as you really need to read every comment for that. In the model above, uncertainty is communicated by font weight, allowing prioritization. How to deal with the uncertainty is a second-level idea. Therefore, I made the choice to only show assumptions when viewing a specific belief.

Code for the prototype can be found in the corresponding Github repo.

Continuous reflection on beliefs

I think this writing experience allows oneself to structure one’s own thoughts in a better way. What is missing here as an exercise to both reader and writer is tracking beliefs throughout time, in the micro and macro way. Adding an assumption should automatically update confidence levels, for example. Moreover, some beliefs and assumptions should probably be re-evaluated at some time in the future.

To really build something that could improve writing and communication for a wider audience, the approach would also have to be ported to a chat format rather than just existing in documents.