My Co-Founder is an AI: How I Built PenCode

I have a folder on my personal computer that I call my “graveyard of ideas.” It’s packed with meticulously written PRDs (Product Requirement Doc), a habit from my day job, for little apps and tools I’ve dreamt up over the years. Each was a solution to a problem I faced, and hours of thought would go into it. But with a lack of coding knowledge, they would just continue to gather digital dust.

For many of us non-coders, the story is the same: we have the vision but lack the technical skills to bring it to life. Hiring a developer is expensive, and learning to code from scratch is a mountain of a commitment. So, the PRDs pile up.

With GenAI now in the scene, and every other person talking about “vibe coding” on LinkedIn, I thought of trying my hand at finally building a solution to one of my problems. But I took a different path. The easy route, the one people call “vibe coding” and that you see in flashy demos, is to write a single, all-encompassing prompt: “Build me a web app that does X, Y, and Z.” I knew that wouldn’t get me the robust product I envisioned. More importantly, it wouldn’t teach me anything.

I didn’t want to just get a product; I wanted to build one. I chose a more deliberate, hands-on path because my primary goal was to learn. I wanted to be in the trenches, to understand the “why” behind every line of code, and to finally appreciate the language of software development.

So I decided to treat the AI not as a vending machine, but as a technical co-founder, who would act as my strategic partner and patient software developer.

And together, we finally built one. Let me tell you about PenCode, and the incredible, often frustrating, and deeply rewarding journey of building it.

The Idea: What is PenCode and Why Bother?

The idea for PenCode came from a personal friction point. As someone who lives by their physical notebooks, I love the tactile experience of writing things down. But that flow hits a wall when I need to reference a web link. Scribbling a long, messy URL is a chore, it’s prone to errors, and it completely breaks my focus.

That’s where PenCode comes in. Many years ago, I came across a solution to solve this. It was called PaperCode, if memory serves me right, but it was soon deprecated. So, I decided to build a solution for myself.

PenCode is a minimalist web app that takes a long URL and gives you a simple, sequential numeric code (like 1, 2, 3...) that’s unique to you. You jot down “See link #7” in your notebook, and when you need it, you type 7 into PenCode and get redirected. Simple. Fast. No frills. We also made a key security decision here: while the codes are predictable, every action is protected by JWT authentication. This ensures you can only ever access your own links, preventing any cross-user data access.

At this point, you might be thinking, “Hasn’t this been solved already?”

• Why not just use a spreadsheet? I tried. It’s clunky. It’s not mobile-first, it becomes unmanageable once you have a lot of links. It cannot check for duplicates intuitively. It lacks any built-in redirection. It’s a glorified list, not a functional tool.
• Why not use a standard URL shortener like Bitly? These tools are built for marketing analytics and branding, not for personal, analog workflows. They generate random, unmemorable character strings (like http://bit.ly/4lxHhJo) which are just as hard to write down as the original URL. PenCode is built for the act of thinking, not the act of marketing.

You can read more about the thought behind PenCode here.

Choosing the Right Partner: ChatGPT vs. Gemini

I have personal subscriptions to ChatGPT Plus and Gemini Advanced, so those were the tools I stuck with.

I began this journey with ChatGPT, using GPT-4o. I created a Custom GPT and fed it my PRD. It was great for getting the initial project scaffolding up. However, as the architecture became more complex, I found the discussions lacked the depth I was hoping for. The responses felt a bit superficial when it came to debating architectural trade-offs.

This led me to switch to Gemini 2.5 Pro. The quality of the discussion immediately felt more mature. I created a custom Gem, similar to a Custom GPT, and loaded it with the same context. The difference was noticeable. The code was solid, but more importantly, the strategic dialogue felt more like working with a seasoned developer.

This isn’t to say one tool is definitively better than the other for all use cases, but for this specific, complex task of building a full-stack application from scratch, Gemini proved to be the more effective partner for me.

The Informed Partnership: My Approach to Building with AI

There’s a lot of talk about AI replacing jobs, but my experience building PenCode showed me a different, more optimistic future. I believe the most effective way to work with AI isn’t to simply command it, but to form a partnership. I call this the Informed Human-in-the-Loop (I-HITL) Development System.

The key word here is “informed.” A loop with an uninformed human can become a bottleneck. But when the human has a foundational understanding of the domain, the AI transforms from a potential replacement into a powerful force multiplier. This process reinforced my belief that in the age of AI, understanding the fundamentals of how things work has become more valuable, not less.

I’ve always been driven by a curiosity to peek under the hood. It’s what led me, years ago, to manage my own self-hosted WordPress blog without any formal experience into server admin. I just wanted to understand the moving parts. That experience, born from curiosity, gave me a conceptual map that proved invaluable time and again in my career.

This same mindset shaped my entire approach to PenCode. It meant I didn’t just accept the AI’s first answer. My role was to be the product leader, the user’s advocate, and the final decision-maker. I had to:

• Ask Deeper Questions: When the AI suggested a technical solution, my foundational knowledge allowed me to ask, “Is this the best way, or just a way? What are the trade-offs?” This led to better, more future-proof architectural decisions.
• Identify Subtle Flaws: I could spot when something was “plausibly wrong.” For instance, I had to explicitly remind Gemini to update the database schema after we decided to add a name field to the registration page. It had updated the frontend code but missed the backend implication.
• Navigate, Not Just Follow: Most importantly, I had to steer the project with a clear product vision. An AI can build what you ask for, but it can’t anticipate what a user needs. I had to be the one to make the critical product calls, such as improving the mobile experience with a bottom navbar, reducing user friction with auto-selected input fields, anticipating user errors and push to make the system more forgiving for common mistakes, and designing for the “empty state” when a new user has no codes.

This extended beyond just functionality; it was about building a tool that felt right. My belief in minimalism was the guiding principle for the entire user experience.

Drawing on my interest in design and UX, I worked with my ‘Design Gem’ – a specialist AI I’ve trained on color theory and UI principles – to make very deliberate choices. We picked the colors that go with the minimalistic philosophy; we established a complete, theme-aware palette in the code, ensuring every button and text element was consistent and readable. We obsessed over the button hierarchy on each page to make the primary action immediately obvious, reducing cognitive load for the user.

This is where the I-HITL model shines. The AI can generate a hundred designs, write thousands of lines of code, but it can’t have a philosophy. My role was to provide the ‘why’ – the respect for the user’s attention and the subtle details that can separate a functional-but-clunky tool from one that is a genuine pleasure to use. It was a powerful reminder that this is the kind of thinking you cannot outsource.

An Appreciation for the Craft (and the Struggle)

This journey gave me a profound appreciation for the craft of software development and design. I learned that there is no such thing as a “small change.” That seemingly simple request to add a name field required modifying the database schema, updating the backend API, changing the frontend UI, and making a product decision about how to handle existing data. It forced me to reset my test database, which was fine during development, but it was a stark lesson in why a well-thought-out PRD is critical before development begins.

There was the struggle too. Working with Postman to test the backend APIs was where I struggled the most. It’s a powerful tool, but it has a steep learning curve for a beginner, at least for me. There were moments of deep frustration, especially when dealing with authentication tokens. This process taught me that every part of the system – the frontend, the backend, the database – must be in perfect sync for the application to work.

My Playbook for Building with GenAI

This project took a lot of concentration. It wasn’t a casual weekend project. I worked on this during my month-long sabbatical (thanks to Uber – they provide a 4-week recharge break after you complete a certain number of years with the company), often working late at night when the house was quiet. Based on this intense experience, here’s my playbook:

• Be the Product Manager: Have a clear vision. Write a PRD. The AI is a powerful tool, but it needs a clear destination. Don’t outsource the thinking; use AI to elevate it.
• Build a Team of AI Specialists: Make use of custom GPTs (Chat GPT) or Gems (Gemini) when working on complex projects that require specialized skills.
• Work in Phases: Break the project into logical phases. This makes the project manageable and the goals for each session clear. It also makes it easier to maintain logs – see the next point.
• Keep a Detailed Log: Our implementation log was our single source of truth. As the chat history grew, the AI would start to forget previous changes or hallucinate. The log was our reset button. I would start a fresh chat, provide the log, and we’d be back on track without wasting hours on rework.
• Embrace the “Why”: Don’t just accept the code. Ask, “Why this way?” This is how you learn and build a better product.

From Graveyard to Pipeline

PenCode exists today. It’s a real, functional web app that I built. The total cost was about $7 a month for the server, $14 per year for the domain, and countless hours of my time. And the reward? An immense amount of satisfaction to see it live. I know it solves a very niche problem that may not have many takers, but it solves my problem. Isn’t that what technology is about?

Check out PenCode and let me know what you think.

Tech Stack Used:

• Frontend: React, React Router, TailwindCSS
• Backend: Node.js, Express.js, PostgreSQL, Prisma
• Authentication: JWT

Photo Credit:

1. Feature Image: Photo by Payton Tuttle on Unsplash