The Price of an Idea Has Changed

One Conversation

A few friends and I have been living in Germany for years. We're all engineers, we're all expats, and almost every time we meet, the conversation eventually drifts toward the same topic: bureaucracy. It doesn't matter whether it's health insurance, the tax office, a bank or a school. Sooner or later another PDF lands in your mailbox, you open it, throw it into DeepL, read the translation twice and still don't know the only thing that actually matters: what do they want from me?

That evening was no different. Somebody had received yet another letter that looked important but was written in exactly the kind of formal German that makes you question whether you've forgotten the language entirely. We laughed about it, shared a few stories of our own, and after a while someone casually said, "Wouldn't it be nice if you could just send this PDF to a Telegram bot and get a normal explanation back?"

Not a perfect translation. Not legal advice. Just something simple enough to answer four questions: what is this document, do I need to do anything, is there a deadline, and what happens if I ignore it? The more we talked about it, the more reasonable the idea sounded. It wasn't trying to solve AI. It wasn't trying to reinvent document processing. It was solving one very ordinary problem that every one of us had experienced more times than we wanted to admit.

As always, the conversation immediately became technical. OCR. Privacy. Hosting. Different document layouts. How to deal with scanned PDFs. Whether it should store documents or process them in memory. Before long somebody finally said, "Interesting idea... but that's probably at least a month of work."

Normally I would've agreed without thinking.

Instead, I went home wondering whether we were actually talking about building a product... or whether we were accidentally assigning the same price tag to simply validating an idea.

The Experiment

The next evening I decided to stop talking about the idea and simply build the smallest possible version that could answer one question: is this actually useful? I wasn't trying to build a startup, think about scaling or design the perfect architecture. If the idea turned out to be useless, I wanted to learn that after one evening, not after several weeks of development.

The stack almost assembled itself. Python let me move quickly, Telegram provided the interface, Tesseract handled OCR, and OpenAI transformed extracted text into a concise explanation with a list of recommended actions. There was nothing particularly innovative about any of those components individually. What surprised me was how little effort it took to connect them into something that already felt genuinely useful.

A few hours later I had the first working version. I could take a real letter from a German health insurance company, send it to the bot and receive a short explanation instead of several pages of bureaucratic German. The response didn't try to translate everything word for word. Instead, it answered the questions I actually cared about: what the document was about, whether I had to do anything, whether there was a deadline and what the recommended next step should be.

It wasn't production ready, and I never expected it to be. There was no polished UI, no monitoring, no proper deployment pipeline and no serious security model. It wasn't something I would give to thousands of users. But that wasn't the goal of the experiment. The goal was to move the discussion from "this sounds like a good idea" to "here, upload another document and let's see what happens."

By the end of the evening I had spent around ten dollars on the OpenAI API and written a few hundred lines of code. More importantly, I no longer had to guess whether the idea had potential. I had something people could actually use, criticize and improve. That alone completely changed the nature of the conversation.

Reality

At that point I was convinced the hardest part was behind me. The bot worked, OCR extracted text, OpenAI returned surprisingly good explanations and the whole pipeline behaved almost exactly the way I had imagined. Going into the experiment, I expected to spend most of my time fighting the AI model: tweaking prompts, dealing with hallucinations and trying to make the responses more consistent. Instead, the model turned out to be the least problematic component of the entire project.

The real engineering challenge started the moment I began feeding it more documents. Every organization generated PDFs differently. Some sent perfectly structured digital documents, others uploaded scans that looked as if they had been copied five times before reaching the mailbox. Tables completely confused OCR, text positioning varied from one template to another, and some documents didn't even contain text at all because every page was just a large embedded image. Every time I thought I'd handled another edge case, a new PDF immediately proved me wrong.

At first I kept looking for a universal parser. It seemed impossible that, after decades of PDFs being everywhere, nobody had solved this problem already. I tried different libraries, experimented with extraction strategies and kept thinking I was only one more package away from making everything work. Eventually I had to accept something I really didn't want to hear: there is no universal parser. Not because nobody has tried, but because every organization manages to generate documents in its own wonderfully unique way.

That realization completely changed the direction of the project. The AI wasn't the difficult part anymore. The real work moved one step earlier in the pipeline, into preparing clean, reliable input before it ever reached the model. Suddenly the problem wasn't prompt engineering but document engineering. Every improvement came from making the extracted text cleaner, preserving the document structure a little better or handling yet another special case that appeared in one specific PDF.

Looking back, that's probably the biggest surprise of the entire experiment. I started it expecting the newest technology in the stack to be the biggest unknown. Instead, the newest component behaved almost exactly as advertised, while a file format that has existed for decades consumed most of the engineering effort.

The Real Lesson

When I looked back at the experiment, the numbers almost felt ridiculous. One evening of work. A few hundred lines of Python. Around ten dollars spent on the OpenAI API. That's all it took to move an idea from a conversation over coffee to something people could actually use. It wasn't polished, it certainly wasn't production ready, but it was real. More importantly, it answered the question that started the entire experiment: would this actually be useful?

That's the part that stayed with me long after the code stopped changing. The project didn't convince me that AI would replace software engineers, nor did it magically remove the complexity of building software. If anything, it reminded me how much engineering still happens around the AI rather than inside it. Reliable systems still need thoughtful architecture, observability, testing, security, deployment pipelines and dozens of other things that don't disappear just because an LLM can generate a good answer.

What changed wasn't software engineering itself. What changed was the price of learning whether an idea deserves your attention.

For years I treated validation as the first phase of development. Even answering the question "is this worth building?" felt expensive enough that I automatically filtered out ideas before giving them a chance. Every new project came with an invisible commitment of several weeks, sometimes months, before I could even decide whether it solved a real problem.

I don't think that's true anymore.

Today, building a reliable product is still difficult. Running it in production is still difficult. Turning it into a business is probably the hardest part of all. None of those things have become easier. What has changed is the cost of taking the first step. Experiments that used to require weeks can now often be completed in a single evening, and that fundamentally changes the way I think about new ideas.

Since then I've caught myself reacting differently whenever someone says, "That'll probably take a month." Sometimes they're absolutely right. But before accepting that estimate, I ask myself one more question.

Are we estimating the product... or are we only estimating the first experiment?

Looking back, that simple shift in perspective turned out to be far more valuable than the Telegram bot itself. The bot was just the outcome of one evening. The real result was realizing that curiosity has become dramatically cheaper than it used to be, and that many ideas deserve to be tested before they're estimated.