For years, I wanted to build my own website—and kept putting it off. I’m not an engineer. Building something from zero felt like a huge undertaking.
Then AI changed the equation.
After months of working closely with ChatGPT, and learning more about vibe coding, I finally decided to try.
I expected the hard part to be building the website. It wasn’t. The harder questions were surprisingly basic:
- What exactly am I building?
- What belongs in the first version?
- What should I leave out—even when AI can build it in minutes?
Here’s what I learned.
1. Get the positioning right before you build
My first idea was not Jennifer’s AI Product Growth Notes. It was an AI Product News site.
The idea looked reasonable: I was already tracking major AI products every day, so why not turn that work into a website?
I initially imagined daily updates. Then I realized how much data collection, organization, and ongoing maintenance that would require. I reduced it to weekly updates.
Still too much. Eventually, I killed the idea.
The problem wasn’t whether AI could help me launch it. The problem was whether I wanted to keep running it. That distinction changed how I thought about building.
Instead of asking What can I build with AI?, I started asking:
What am I willing to keep building for years?
That moved the product away from news and toward something much closer to what I was already doing naturally: learning about AI products, studying how they grow, experimenting with building, and documenting how my thinking changes.
I looked at what I was already working on, the experience I had accumulated, and where I wanted to go next. After multiple rounds of discussion with AI, the positioning gradually became clearer: Jennifer’s AI Product Growth Notes—an editorial publication exploring how AI products are positioned, adopted, and grown, while sharing what I’m learning along the way.
Looking back, I’m glad the first idea failed. It helped me understand that choosing what to build matters before deciding how to build it.
If you’re new to vibe coding, a few things I’d suggest:
Start with an experiment, not your dream product.
Build a simple page, recreate a small tool, or make a tiny app. Use it to learn how to prompt, review, iterate, and collaborate with AI. A small prototype that improves the way you build can be more valuable than an ambitious first project you struggle to finish—or never want to maintain.
Choose something you can realistically keep running.
For a first project, be cautious with ideas that depend heavily on live data, automation, complex backend systems, or constant content updates unless you already understand the operational cost. Launching is only the beginning; the product still has to be maintained after the novelty of building it wears off.
Don’t confuse technical feasibility with product value.
When AI can build almost anything you ask for, “Can I build this?” becomes a much weaker filter. The better questions are: Is this worth building? Does it fit what I want to do? And will I still want to own it after launch?
2. Just because AI can build more doesn’t mean you should
Once the positioning became clearer, I ran into the opposite problem:
I could build too many things.
When I was researching other websites and designing the initial structure, I considered many sections that seemed useful:
- Case Studies
- About
- Learning Path
- Read All
- Archive
- Separate pages for Courses, Books, and Resources
- More content sections across the homepage
None of these were bad ideas. That was exactly the problem.
When AI can generate another page quickly, “This could be useful” starts to feel like enough justification to build it.
But implementation is only one layer of cost.
✨ Every additional page still requires:
Definition → Content → Design judgment → Review → QA → Maintenance
Codex might implement a new page in minutes. I would still need to define its purpose, decide what belongs on it, fit it into the information hierarchy, review the design, test it across desktop and mobile, and maintain it as the site evolves.
That was when I started to see the hidden cost of AI-assisted building: AI makes it easier to add things, but it doesn’t make the complexity they create disappear.
If you’re building on your own, two things are worth keeping in mind:
Resist the temptation to build more just because AI makes it easy.
AI dramatically reduces implementation cost, but every new feature still creates decision, content, review, and maintenance costs. The faster you can build, the more deliberate you need to be about what enters the product.
Before adding anything to V1, ask three questions:
- Does the first version actually need this?
- Is there enough real content or user value to justify it now?
- What ongoing work will this create once it exists?
If the answer is unclear, defer it. You can always build it later when the need becomes real.
3. Build for today without losing sight of tomorrow
Building something meaningful requires long-term thinking. But thinking too far ahead can also slow down what needs to happen now.
Products are no different.
AI makes it increasingly possible to build features and pages that once would have been constrained by time, technical skills, or resources. But for me, that changed the meaning of an MVP. The challenge was no longer only What are my limitations? It was also:
What belongs in the product today—and what should wait for the product to grow into it?
One of my favorite small decisions was removing the About page.
At one point I joked:
“Can I skip About Jennifer until I’m famous enough to need one?” 😂
Behind the joke was a useful question: why did the website need an About page?
Because personal websites normally have one?
That wasn’t a good enough reason.
The homepage already explained why I was building the publication and gave visitors enough context about me. An About page might make sense later, but it wouldn’t make V1 meaningfully better.
So it went.
Learning Path was a more interesting decision because the reason was different.
It does fit the long-term vision. I want the publication to show not only what I think about AI products, but also what I’m learning along the way.
But Courses, Books, and Resources already communicate that in V1. A dedicated Learning Path page can become valuable when there is enough content to justify it.
For now, it can wait.
That helped me separate three ideas I had previously treated as almost the same:
- Useful ≠ Necessary
- Can build ≠ Should build now
- Aligned with the vision ≠ Needed in V1
Before this project, I tended to think of an MVP partly in terms of constraints:
What can we realistically build with the time and resources available?
Vibe coding weakened some of those constraints. What became more important was sequencing—knowing what the product needs today without prematurely building everything it may need tomorrow.
If you’re building your first website, here’s what I’d keep in mind:
Start by making the core experience work.
For my publication, that meant getting the homepage right first. It needed to explain what the site was about, show what was worth reading, and give visitors a reason to explore further. Subpages could be added when real content and real needs justified them.
Keep the long-term vision, but build it in stages.
You don’t need to abandon a good idea simply because it doesn’t belong in V1. Put it on the roadmap and let the product earn its complexity over time.
Give yourself permission to ship before everything feels perfect.
For a first-time builder, there will always be another detail to improve. Make the first version clear, coherent, and good enough to represent what you want to build—then put it in front of real people. Feedback from a live product can tell you more about what deserves the next iteration than another week of polishing in private.
Long-term thinking tells you where the product can go. Good sequencing tells you what to build now.
4. AI didn’t remove the product decisions. It exposed them.
This was the biggest shift for me.
I started this project thinking the process would look roughly like this:
Idea → Define → Build → Done
AI would make the last part dramatically easier.
And it did.
But once implementation became easier, the unresolved product questions became much more visible:
- Is this a publication or a portfolio?
- What should the homepage prioritize?
- Does this feature improve the product, or only make it look more complete?
- Am I designing for what exists today—or prematurely building for an imagined future?
- Is something here because it serves the product, or because websites like this usually have it?
AI could help me explore every one of these questions. It could suggest alternatives, challenge my assumptions, compare different approaches, and turn an idea into something I could actually see.
But faster execution didn’t make the decisions disappear.
In some ways, it made avoiding them harder.
When producing something becomes almost frictionless, it is easy to confuse ease of creation with value.
They are not the same.
The process also made me rethink the relationship between AI and human judgment. I don’t think the useful distinction is simply that “AI executes and humans decide.” AI was part of the thinking process too. Some of my decisions became better precisely because I could discuss them with AI, explore several directions quickly, and challenge my initial assumptions.
But collaboration is different from delegation.
What I’d keep in mind when making product decisions with AI:
Use AI to expand your options, not to outsource your judgment.
Ask it to propose alternatives, challenge your reasoning, identify trade-offs, or show you directions you might not have considered. The goal is not to accept the first plausible answer, but to use AI to make the decision space clearer.
Give your own taste and point of view real weight.
If you have a clear sense of what you value, how something should feel, or what you want the product to represent, don’t treat AI’s recommendation as automatically better because it sounds more rational or polished. A product needs coherence, and that often comes from someone consistently deciding what fits—and what doesn’t.
Keep the final decision with the person who owns the product.
AI can help you reason through a decision. It can even change your mind. But someone still has to take responsibility for the choice and its consequences.
For this website, that person was still me.
The workflow became less like:
Human decides → AI builds
and more like:
Human intention → AI exploration → Human judgment → AI build → Review → Decide again
That is the role I now find most interesting in AI-assisted building.
AI can dramatically expand what I’m able to create.
But expanding the possibility space makes product judgment more important, not less.
What building taught me
I started vibe coding because I wanted to learn how to build.
And I did.
I learned how to turn an idea into something real without being an engineer. But the more interesting lesson was that building was only one part of the work.
AI gave me more possibilities than I expected. What it couldn’t give me was a reason to choose one possibility over another.
That still required understanding what I wanted the product to become, making trade-offs, and taking responsibility for the final decisions.
My website is only at V1, and I’m still learning how to make those decisions better.
But one question has stayed with me throughout the process:
When almost anything becomes easier to build, what is actually worth building?
Maybe that’s the more important skill to learn next.