Getting Started

The current version of proofofwriting.com started on a whim. I was sitting in a hotel room while on vacation with my family when I came across yet another tweet about someone who used Claude to build an application. They claimed to have no coding experience and described how Claude walked them through every step of the process and built a working prototype within hours. So I thought what the hell, let me try.

I signed up then started with the free version using Claude Sonnet 4.6 and here's the first prompt I fed it:

"i want to build a site that works similar to substack but using crypto rails. so people can post content and put it behind a paywall but those paywalls can be unlocked without requiring any sign up or credit card information. see ProofOfWriting.com for an example of how this could work using the PayButton plugin for wordpress. Take me through this step by step from beginning to end. I want it to be possible for someone to create their account using nothing but an email address to post content, but their "customers" can "login" using an eCash payment like on ProofOfWriting.com so they don't have to reveal any identifying information about themselves. They just need a bit of XEC."

Claude then responded by giving me a high level overview of what I was trying to build, what the different phases of the build would entail, as well as offering multiple options for how we wanted to approach each problem. For example, I could choose Option A: WordPress + PayButton Plugin (Faster, Less Control), or Option B: Custom Full-Stack App (More Work, Full Control).

After I chose Option B, it gave me the full tech stack: database schema, payment flow mechanism, backend implementation, frontend implementation, and everything else I would need to deploy. I was surprised by not only how comprehensive it was, but how easy it made it for me to understand exactly what we needed to build for each phase and why. Everything from email signups, to the author dashboard, to the reader experience was covered.

I then pushed back on items that weren't how I imagined they would work and made further suggestions to refine the build. Once I was happy that we were on the same page, we got started. It even asked me things like my coding experience level and how I wanted to host the site so it would know exactly what to do.

Here was my recommended stack:

Frontend - Next.js
Database - Supabase (Postgres)
Auth (authors) - Supabase Auth
Backend logic - Next.js
Background worker - Railway
Payments - Chronik + ecashaddrjs
Deployment - Vercel

I then proceeded to follow its very easy to understand directions and installed Node.js, Cursor, VS Code, as well as creating accounts on GitHub, Vercel, Supabase, and Railway. Once I signed up and connected my accounts, I was ready to begin my journey.

All I needed to do was copy and paste Claude's instructions and lines of code into Cursor or my terminal and wait for things to run. If I was confused by anything, I could just ask Claude to clarify, and after only about 3 hours, I had a simple minimum viable product (MVP) that actually worked!

It wasn't perfect, but it proved the concept was possible, and I had yet to spend a single penny. More on that later.

As I said, I started the project on a whim, so I hadn't planned anything other than getting to see what AI coding tools were capable of. But when I saw what it produced after only a few hours of work, I realized this could be something more. I worked on it for another couple of hours the following day to see where it might lead, and I was blown away by how much progress I was making in such a short period of time.

Once my initial set up was complete (Claude, Cursor, Vercel, Github, Supabase, etc.) I was off to the races. It was just a matter of iteration. Prompting the AI for a new feature or fix, feeding that into Cursor, then pushing to production where I could test everything and make sure it was all working the way I wanted.

In terms of timeline, I began this project on April 3rd, launched and announced the MVP on April 6th, then after several days of testing with a small number of users, I launched on my official domain on April 12th. It's only been a week since the official launch, and I've not only added a ton of features that weren't there a week ago, but the site has been running smoothly without any significant issues.

Dealing With Bugs

Now there were definitely bugs along the way. Don't think Claude is just going to one-shot your application. In addition to Claude not always understanding your prompt and having to sometimes nudge it in the right direction, it can also make mistakes just like a human. Think of it like a super intelligent being that can think and code super fast but just like a human, can make mistakes along the way. For example, I'd make a change, deploy the new version, only to find that the change didn't work, or it broke something else.

Easily the most annoying bugs I had to deal with were the ones regarding payment verification. For example, I would send a payment to unlock an article but the paywall would stay up. Or I'd log out as a reader and find out the article remained unlocked when it no longer should. Fixing this involved Claude having me go into the dev console and providing screenshots or pieces of data to see exactly what was breaking. There was definitely a moment when I thought of giving up, but luckily I kept at it and eventually got it working. Ultimately, one of the problems was that the URL pointing to a Chronik instance (name of eCash indexer) was missing a trailing /. This was only solved when I added a Claude plugin called eCashSkill that helped Claude figure this out. The plugin was developed by an eCash community member and helps ensure that Claude has all the most up to date development skills for building with the eCash blockchain.

Other bugs I had to deal with included everything from new users being unable to sign up as an author, profiles not being saved, database bugs, pagination bugs, and the list goes on. My point is that Claude will make mistakes. But for the most part, fixing those mistakes was relatively easy and painless, with the lone exception of the payment verification issues above. As long as you explain to Claude what the problem is, it will think about what might be causing it and systematically figure it out. Just be sure to read through its explanations because sometimes it's as if Claude is thinking out loud and the first idea it comes up with may not end up being the one it ultimately recommends.

I suggest making sure you iron out any major bugs before launching your application to avoid users being impacted. I found building in production was easiest so I didn't have to fire up my local environment to test everything once and then test again in prod. But testing in prod can become more complicated once you have real users.

Pricing and Cost

I touched on how fast this whole process has been. How I went from idea to fully functioning website in about a week, while on vacation, in my spare time. But remember when I said I hadn't spent a single penny? Well, that was short-lived because the free version of Claude ran out of tokens on my 2nd day of working on this site. So I signed up for the $20/month plan and that's what I've been using ever since. I haven't once been rate limited on tokens, though I wonder if that's because I've stuck with Sonnet 4.6 rather than Opus 4.7. Now that I'm pretty much done with the rapid iteration phase, I might start using Opus 4.7 for future prompts.

Besides Claude, the only other subscription I paid for is Supabase for $25/month. I probably could have stayed on the free tier, but wanting to give this site the best chance to succeed as possible, I figured paying $25 to improve it in any way was worth it.

That's it. I've spent a total of $45 on building this site. I won't include the cost of the domain and hosting fees since I was already paying those before, but that's only about $30/month, which means if I continue to pay for Claude, it's $75/month in total. While I believe that feels extremely cheap for what I've built, I guess at some point I will have to ask myself if I genuinely believe this site will be able to generate at least $75/month in revenue. Time will tell.

Conclusions

While the general consensus seems to be that you can't build a serious application by vibe-coding, I think it's a great way to build something that's more than just an MVP though maybe not something that's actually going to perform at scale. The truth is I'm incredibly happy with this site and its performance thus far, and it blows my mind that we live in a time when someone like me who never learned to code can build something like proofofwriting.com for a total of $45 and about a week of working on it in my spare time.

No more having to hire a developer and all the friction that entails, and even after finding one, having to deal with managing the working relationship and hoping this person is capable enough to deliver. With AI, you can keep iterating without managing a relationship or feeling like you're imposing.

While I've used AI in the past to look up facts, or improve my writing, or turn a picture of my kids into a cartoon, it wasn't until I used it to code that I began to get a glimpse of how much AI can impact our world and our future.

Personal Tips

Build something you want to use yourself. I would say my biggest advantage building this site was that my project already had a built-in power user: me. Since I built this for myself, I know exactly how I want things to work, and through actual usage, I'm able to see what does work and what doesn't work. I imagine it also makes the entire process way more fun.
Just start with a prompt. If you have any interest in trying to build something, I suggest you give it a shot. All it takes is a minute to explain what you want to build and have the world's smartest assistant help you build it.
After a while, Claude starts to slow down if your conversation goes too long, so if you notice it's taking a long time to respond, start a new conversation and briefly remind it of what you're building, and go from there.
Ask Claude to add a test framework to each of your programs. Let it develop all the tests (e.g. unit, E2E, etc.), then use another session to audit that. For every change or problem, have it run the suite and update if necessary. These tests have already helped me catch things like lines of code referring to an old version of the home page. As the project grows and bugs become harder to track down, having a solid test suite means there are fewer of them to begin with.
Which brings us to one that may not be easy, which is talk to actual developers. I think my project would not have turned out nearly as well if I didn't have the benefit of having been closely following the work of Bitcoin ABC and having the privilege of asking them questions and learning from them. It helped me know what to look out for and what to ask Claude to do to give myself the best chance of success.
Ask Claude to audit your code. I don't know how this compares to paying someone to actually audit your code, but all I know is doing this helped me catch a bug I wouldn't have discovered until someone exploited it and I was made aware of the exploit. The bug was that someone with the technical expertise could delete any comment they wanted on the site. While this wouldn't be catastrophic, it was still something I'm glad the AI caught and patched before it could be exploited. But again, be sure you understand what Claude is suggesting because even in this phase, there were things it identified as bugs that really weren't. Like not understanding that even if an eCash address is public, an attacker can't use it to unlock articles without having control of the private keys.

That's it. Maybe your experience will be different from mine, but as they say, you'll never know unless you try. Also, keep in mind that I'd be more cautious vibe-coding something that handled credit cards or personal data, but since the platform runs on eCash rails and doesn't custody funds or store sensitive info, the potential blast radius of a bug is small.

Good luck, and if you have any specific questions or feedback, feel free to post them in the comments and maybe I'll include them in a future article. Remember, this journey is barely two weeks old, and I'm sure I still have a ton to learn, but all I know is I'm having a ton of fun, and it's easily worth the $75/month it's currently costing me.

Thank you for reading, and for spending your precious XEC. Oh, and here's my public GitHub repo: https://github.com/CainXEC/xec-publish

How I built a crypto-paywall Substack in a week for $45 with no coding experience

Preview (12 min read)