I Can't Code. I Shipped 36 Versions in Six Days.
Six days ago I was reading PDFs on my laptop and getting more and more annoyed with the app I was using. A little before midnight I sent Claude a message. It started like this:
I want to build a PDF reading tool for myself… I'm not a programmer, so please talk to me in simple language.
Today the tool is on version 36. It reads PDFs, e-books and Markdown files. It translates as you read, lets you ask AI about any sentence, and turns your notes into key points and a mind map with one click. There's an international edition and a separate edition for mainland China, each with its own website. A few friends are using it to read papers and books, and when something bugs them they can complain about it right inside the app.
In those six days I didn't write a single line of code.
I want to write this down. The tool isn't anything remarkable. But building it showed me that the barrier to making a product has moved.
The hard part is no longer "how". It's "what".
Over those six days I sent Claude more than 170 messages. Looking back, the thing I said most often was some version of "don't build it yet, confirm the requirements with me first." I said it more than thirty times.
My very first message ended that way: "Please don't write any code yet. First give me a plan: what technology to use, how the data will be saved, what the steps are. Then ask me whatever you need to confirm."
I didn't plan to work like this. It became the rhythm almost immediately. I'd describe what I wanted, the AI would turn it into a concrete plan, and then it would ask me questions. Where does this button go? What happens in that case? Should there be a setting to turn it off? Only after I answered would it start building. Many of those questions had never occurred to me. Being asked them showed me how vague my "I want" really was.
It used to be that when someone who couldn't code had an idea, what stopped them was how. Now "how" is barely a problem. What's left is all what: what problem you're actually solving, what good looks like, and what not to build. AI can't answer those for you. But it's very good at making you ask them properly.
I was the first user
The tool improved fast for a simple reason: I used it every day.
Whenever something felt awkward, it became a new version that same day. At first you had to select text and then click "Highlight". Two steps felt like one too many, so now dragging across a sentence highlights it. When I read English with translation on, the translated page would often jump to the next page before I'd finished reading, and I'd lose my place flipping back and forth. So the translation now flows continuously, one page after another.
None of these are big features. But they decide whether something is merely usable or actually pleasant to use. And you only notice details like these if you really use the thing every day.
What I figured out reading Paul Graham
On the second night I was reading Paul Graham's essays, and somewhere in there I realized I wasn't really building a PDF reader.
A lot of people read books, especially business and self-improvement books, and feel inspired while reading. Then they find it very hard to actually use any of it in their lives. The knowledge gets into their eyes but not into their heads. What I care about was never remembering what I read. It's digesting it until it becomes mine.
So what the product really needs is a whole loop. You note your thoughts while reading. When you finish, AI organizes them into key points and a mind map. Then it quizzes you on your own notes. Later you come back and check whether you really absorbed it. That night I gave myself a rule:
Every feature should be designed around one goal: helping people digest what they read and put it to use.
Since then, whenever I want to add something, I ask myself first: does this help someone digest what they read, or is it just one more button?
What my first real user taught me
On day five, a friend who's doing a PhD used the tool on an ordinary morning to read a paper from start to finish. He wasn't testing it as a favor to me. He actually had something to read that day. That made me really happy.
He gave me a lot of feedback, and one point changed how I understood the product. He wanted literature summaries. If he could train this agent to summarize papers the way he wants, he said, it could replace ChatGPT for him.
Talking it through, we realized that most people don't read PDFs for fun. They read them because they have to: papers, reports, work documents. For them the most honest need fits in one sentence: "I don't want to read this, just tell me what it says."
So that sentence became the name of a button. And we can do it better than pasting the text into ChatGPT, because every point in the summary comes with the original sentence and page number. One click takes you back to that sentence in the document, where you can highlight it or save it to your notes, with no copying and pasting between two apps.
He also told me what he didn't like. For example, he thought the quiz feature was pointless. I kept it. People who don't need it can simply not use it. But his feedback made one thing clear: some people open the same tool to read closely, and others just want to know quickly what's inside.
The real barrier wasn't code
People assume the hardest part of building a product without knowing how to code is the code. Over these six days, what gave me the most headaches was everything around it.
I wanted friends to try the tool, but I couldn't hand them my AI key. That meant invite codes and a relay server. I had never used Cloudflare, so I had the AI walk me through it click by click. Claude isn't available in mainland China, so I made a separate mainland edition that runs on MiniMax, a Chinese model, with its relay on Alibaba Cloud. There I stared at error messages and settings I had never seen before and sent the AI screenshot after screenshot. Then, so friends could just open a link, I bought a domain and learned what DNS records are. Late at night I sat watching a Tencent Cloud dashboard, waiting for "Deploying" to turn into "Active".
None of that was code. It was accounts, permissions, networks and regional restrictions, the friction of the real world. AI could explain every step. But I still had to click every button myself.
The hardest part is saying no
Once AI can build whatever you ask for, what's scarce changes.
Several times a plan for a new feature came with a setting that let users switch it on or off. I took those settings out. Translation follows you automatically when you turn the page, with no setting. Opening the app takes you straight back to where you left off, with no setting. I want it to feel as smooth as possible, not cluttered with settings no one needs.
By day six the tool did a lot, and the toolbar had become bloated. I've always believed in Steve Jobs' idea that simplicity is the key. So we made a minimal mode. When you open a book you see only the essentials, and everything else lives under "More". People reading research papers can switch to a pro mode with one click. Then we redesigned the whole interface from scratch.
Adding a feature now costs almost nothing. So the real work becomes deciding what not to add.
Why this site exists
These six days convinced me that one person with an idea and AI can now get surprisingly far. I'm going to keep building this product, and I want to write down how it goes: what I did each day, what feedback I heard, what I decided, and what I figured out.
You'll find two kinds of writing here. Essays, like this one, are about things I've figured out. The log has one entry per day and covers the day-to-day of building a startup. The site is an experiment too. AI will draft most log entries from my day's work, and I'll edit them and add my own thoughts. It's the same way I built the reader: I work out what I want, and AI builds it.
If you're building things with AI too, or you're curious about the reader, I'd be glad to see you here again.