Building AI Workbench Lab in Public: What I’m Learning

AI Workbench Lab is a practical experiment:

Build useful things with AI, measure what actually happens, and share the lessons without pretending every decision was right the first time.

The project began as a simple Blogger site.

It is now a Next.js website with migrated content, practical resources, GitHub-based development, Vercel deployments, Search Console data, and a growing set of articles based on real project work.

The technical changes are visible.

The less visible change is how much my own way of working had to change before the project became useful.

I used to think I needed to understand more before I could begin.

In reality, most of what I now know came after I started building.

That is why I keep this project public.

What “building in public” means here

For AI Workbench Lab, building in public does not mean posting every activity or treating every small update as content.

It means documenting work that produced a reusable lesson.

That includes:

• why I chose one platform and later changed it
• how I migrated content without abandoning old URLs
• where AI saved time and where it wasted time
• what Search Console showed after launch
• which technical problems appeared in real deployments
• how a small collection of articles became a more structured resource site
• what I changed after something failed

The important part is the last one.

A project becomes more useful when the mistakes are documented clearly enough that someone else can avoid repeating them.

Why I started AI Workbench Lab

I did not start this site because the internet needed another stream of AI news.

There is already more AI news than most people can use.

What interested me was the gap between hearing about a tool and actually using it to complete real work.

Could AI help me build a website?

Could I use it to understand code I had never learned formally?

Could it help me structure SEO work?

Could I move from a rough idea to something people could actually use?

Could I document the failures honestly instead of only showing the polished result?

That became the purpose of the site:

Practical AI. Real Experience. Built in Public.

The part I underestimated: starting before I felt ready

Before this project, many technical areas felt like separate professions.

Website development belonged to developers.

SEO belonged to specialists.

Design belonged to designers.

Databases and authentication sounded even further away.

AI lowered the barrier, but it did not remove the learning.

My early prompts were vague.

I used tools inefficiently.

I spent credits before I understood what I wanted.

I rebuilt things that should have been planned first.

I sometimes assumed that if the output looked convincing, it must be correct.

It was not.

What changed was not sudden expertise.

It was repetition.

One working page made the next page easier.

One deployment made the next deployment less intimidating.

One mistake with Cursor made me more careful about reviewing diffs.

One problem with v0 taught me to decide structure before generating.

One Supabase problem taught me that authentication, authorization, and data access are different layers.

Confidence came after those repetitions, not before them.

That is one of the reasons I no longer wait for a project to feel completely comfortable before I begin.

The project so far

1. Starting simply on Blogger

Blogger was useful because it removed infrastructure decisions.

At that stage, the most important thing was not building a sophisticated site.

It was proving that I would actually publish.

The simple platform helped me start.

Later, the same simplicity became limiting when I wanted more control over content structure, redirects, metadata, reusable resources, and future interactive tools.

I wrote about that full arc in Blogger vs WordPress in 2026: What I Learned After Starting on Blogger.

2. Migrating the original content

When I moved away from Blogger, I learned that migration is not a copy-and-paste exercise.

A real content migration includes:

• old URLs
• redirects
• titles and metadata
• publication history
• internal links
• images
• canonical URLs
• sitemap entries
• Search Console monitoring

The visual redesign was the easy part.

Preserving the relationship between old pages and new pages required more care.

The process is documented in How to Migrate a Website Without Losing SEO.

3. Building a real development workflow

The site now uses a workflow that includes ChatGPT, v0, Cursor, GitHub, Supabase when needed, and Vercel.

The value is not the number of tools.

The value is knowing what each one is for.

ChatGPT helps me think.

v0 helps me make an interface direction visible.

Cursor helps me work inside the codebase.

GitHub gives me history and a safety net.

Vercel gives me Preview and Production environments.

Supabase becomes relevant when a project needs identity, data, permissions, or backend rules.

That workflow is explained in My AI Website Stack in 2026.

4. Building resources, not only articles

One of the biggest changes in the site was realising that an article is not always the most useful output.

Sometimes the reader needs something they can use immediately.

That led to resources such as:

• Google SEO Checklist
• Practical AI Prompt Library
• AI Website Launch Checklist

That is the direction I want the site to keep moving toward:

experience → lesson → practical resource

What the mistakes changed

Some of my earliest writing focused heavily on motivation:

start before you are ready, stop chasing perfection, make time, keep learning.

Those ideas are still true for me.

But publishing several separate articles around the same message taught me another lesson:

A site does not become more useful just because it has more pages.

If five articles repeat the same idea with slightly different wording, that is not five times more value.

That insight matters even more after seeing how search engines and advertising systems evaluate site quality.

So I am applying the same principle to the site that I apply to code:

• remove unnecessary duplication
• keep the strongest version
• make the useful page more complete
• redirect the old path
• improve the structure instead of increasing the count

That is a more honest form of building in public than pretending every old page deserves to stay forever.

What the project looks like now

By 2 November 2026, AI Workbench Lab had been reduced and rebuilt into a smaller, more deliberate site:

• 18 public articles
• 3 practical resources
• a GitHub → Vercel Preview → Production release workflow
• a documented Blogger migration
• Search Console measurement after launch
• two AdSense reviews that both returned Low-value content

The second AdSense rejection was especially useful because it showed that cleaning up obvious technical issues was not enough.

Before the second review I had already reduced overlapping articles, added the correct ads.txt, removed an unfinished newsletter section, fixed a stale hardcoded article count, and strengthened trust pages.

Google still returned Low-value content.

That forced the project to move from:

Does this page look finished?

to:

Does this page show enough original evidence, practical usefulness, or first-hand experience to justify its existence?

That is now the publishing standard for the site.

What Search Console changed

Once the site started receiving real Google impressions, SEO became less abstract.

Instead of asking:

"Is this SEO good?"

I could ask:

• Which pages are appearing?
• Which queries are triggering them?
• Are those queries actually relevant?
• Are impressions increasing?
• Which pages get clicks?
• Which pages are being discovered but not selected?
• What should I improve before writing something new?

That changed my content strategy.

I am less interested now in publishing because the calendar says I should.

I am more interested in strengthening pages that already show a real signal.

Small-site data needs patience, but even early data can tell you whether Google understands the topic of the site.

What AI changed in the process

AI did not make every task easier immediately.

At first, it often created more work.

I used Cursor too broadly.

I regenerated too much in v0.

I treated AI answers as if they were decisions instead of suggestions.

The improvement came when I changed the workflow.

I started defining the problem first.

I made smaller changes.

I reviewed what actually changed.

I tested the real user flow.

I used GitHub before risky edits.

I learned to ask whether a failure came from code, environment, data, permissions, or deployment.

I documented that journey more fully in AI Didn't Save Me Money. It Changed the Way I Work..

What I want AI Workbench Lab to become

The site is not meant to be a catalogue of tools I have never used.

I want it to be a record of practical work:

• real website builds
• AI-assisted workflows
• deployment problems
• SEO experiments
• migration lessons
• checklists and templates
• mistakes worth documenting
• measurable changes when data is available

That means the site should get more focused over time, not more crowded.

A smaller collection of strong, original pages is more useful than a large archive of repetitive thoughts.

The rule I use now

When deciding whether something belongs on AI Workbench Lab, I ask:

What can the reader do differently after reading this?

If the answer is unclear, the page probably needs more work.

A useful article should give the reader at least one of these:

• a decision they can make
• a process they can follow
• a mistake they can avoid
• a checklist they can use
• a system they can understand
• a real example they can compare with their own situation

That is now the standard I want the site to meet.

Final thought

Building AI Workbench Lab has taught me that progress does not come from keeping every version of the work.

Sometimes progress means rewriting.

Sometimes it means merging.

Sometimes it means admitting that two pages are saying the same thing.

And sometimes it means changing the direction of the site after real users, search data, or a failed review shows you something you could not see at the beginning.

That is what building in public means to me now.

Not proving that every decision was right.

Showing how the project gets better when a decision turns out to be wrong.

Practical AI. Real Experience. Built in Public.