DEV Community

Arnold XIAO
Arnold XIAO

Posted on

I shipped a small AI skill as a paid website. The last 10% felt very different this year.

A visual guide to the Ten Heavenly Stems in Bazi, showing Chinese calligraphy, elemental types, and short personality notes.

I recently tried a small experiment:

Take an internal skill and turn it into a real website.

Not a demo. Not a local prototype. A site that people can visit, sign in to, pay for, and get a generated result from.

The skill itself is in a niche category: Bazi, also known as Four Pillars or Chinese astrology. The product idea is simple enough. A user enters birth information, the site generates a chart, then offers a deeper interpretation.

The project is Hidden Stems, a small Bazi chart and reading tool.

Hidden Stems Bazi Oracle interface showing a birth chart form, Five Elements diagram, Four Pillars cards, and cultural reading preview.

But making that into an actual product meant a lot more than putting a form on a page.

I had to get these things working:

  • sign in and account flow
  • Stripe checkout
  • payment webhooks
  • database persistence
  • Vertex AI generation
  • Vercel deployment
  • environment variables
  • SEO / GEO basics
  • error states around payment and generation

After getting through it, my biggest takeaway was not "AI can write code now."

It was this:

The last 10% of shipping a web product feels much less scary than it did last year.

Last year, I kept stopping at 90%

Last year I used Cursor for a few web projects.

For the early parts, it was useful. Building pages, writing components, wiring basic logic: that part felt faster than before.

But once I got into the backend side of a Next.js app, deployment, Stripe, cloud services, and production configuration, the process became painful again.

Next.js errors can be pretty unforgiving. Sometimes one small issue makes the whole page fail, and before you can even understand your business logic, you first have to repair the framework-level problem in front of you.

Stripe was similar.

The docs are good, but real integration still means dealing with keys, checkout sessions, webhook secrets, local vs production mode, callback URLs, database state, and all the small places where something can silently not line up.

I had quite a few projects that reached about 90% and then just sat there.

Not because they were impossible.

Because the remaining work was boring, fragile, and full of tiny traps.

Deployment. Config. Webhooks. Production errors. Reading docs. Testing the same flow again and again.

That final stretch drained the momentum.

So for a while, I stopped doing much web deployment work.

This year I wanted to see if Codex could push through the boring part

This year, our team had been making a number of skills. We also kept talking about taking some of them overseas.

At some point I got tired of only talking about it.

So I asked a simple question:

Can I take one of these skills and ship it as a real website end to end?

I decided to try it with Codex.

The rough stack looked like this:

  • Codex for reading the codebase, editing code, running checks, and fixing bugs
  • Stripe CLI for payment-side setup and verification
  • gcloud CLI for Google Cloud and Vertex AI
  • Vercel CLI for deployment and environment variables
  • Supabase for the database

The main website was not the part that worried me most.

The part I did not feel confident about was Vertex AI.

I had looked at Google Cloud docs before. More than once. The concepts are all understandable one by one, but there are so many of them: project, billing account, IAM, API enablement, regions, service accounts, model access, credentials.

Each one feels like it could eat half a day.

This time I mostly wanted to see whether I could use gcloud to move through the setup instead of doing everything manually through documentation and dashboards.

To my surprise, it worked.

Not in a magical one-command way. There were still errors. There were still permissions and configuration details. But the difference was that Codex could walk with the CLI, read the errors, adjust the next command, and keep moving.

That changed the feeling of the work.

Cloud setup used to feel like something I had to fully understand before I was allowed to touch it.

This time it felt more like debugging a path forward.

Stripe also felt less like a black box

Stripe was another place where the CLI helped.

Last year I would often bounce between dashboard pages, docs, local code, and production settings, trying to figure out whether a webhook was actually connected.

This time I could verify more of the flow directly:

  • whether the provider was configured
  • whether the live keys were present
  • whether the webhook endpoint existed
  • whether checkout could be created
  • whether the order moved to paid
  • whether the report state changed after payment

The payment code still had to be correct, of course.

But the debugging loop was much better.

Instead of staring at a broken product and guessing which part was wrong, I could break the system into smaller checks.

Payment provider registered?

Webhook configured?

Database updated?

Report unlocked?

Generation saved?

That sounds obvious, but when you are shipping alone, the emotional difference is huge.

The boring launch work was also easier to keep moving

The same thing happened with SEO and GEO work.

Normally this is the kind of work I postpone.

Sitemap, metadata, multilingual pages, search console verification, programmatic content pages, external link notes, directory copy, page checks, indexing checks. None of it is hard in isolation. But it is manual, repetitive, and easy to forget.

This time, because Codex could work with local files, the browser, and command-line tools, it could help me keep a launch checklist alive.

It did not make the work disappear.

But it made it less lonely.

That matters more than I expected.

The hardest part was still the product experience

The most painful part of this project was not Stripe.

It was not Vertex AI.

It was the frontend experience.

A page that works and a page that makes someone want to pay are completely different things.

A button being clickable is not the same as a user understanding why they should click it.

I went through many versions of the interface:

  • how to make Bazi understandable for English-speaking users
  • how much Chinese terminology to keep
  • how to preserve the feeling of the original culture without making the page look cheap
  • how to make the paid report feel valuable
  • how to avoid the mobile layout falling apart
  • how to make the user journey feel less complicated

And honestly, I am still not fully satisfied with the UI.

It is much better than the first version. It has more of the atmosphere I wanted. It starts to feel like an Eastern metaphysics product instead of a generic AI card layout.

But it is still not exactly the thing I have in my head.

That was one of the clearest lessons from this build:

AI can help close the engineering loop very quickly. It can also generate several usable UI directions.

But when you want a very specific feeling, a certain visual taste, a certain level of trust, and a page that feels like it naturally belongs to the product, you still have to guide it very closely.

Frontend is not just "make it pretty."

It is product judgment.

It is positioning.

It is trust.

It is whether the user understands what is going on without reading too much.

My current feeling

AI plus CLI tools made the engineering loop faster.

But product judgment did not disappear.

Last year, I was afraid of the last 10%.

Payments, deployment, database, AI integration, environment variables, SEO, production callbacks. Any one of those could kill a project if I lost patience.

This year, those things are still annoying, but they do not feel as intimidating.

Codex could stay with the problem long enough to turn a fuzzy skill into something that actually runs online.

That is the real change for me.

Shipping no longer feels like one giant gate.

It feels like a pile of small problems.

And if you have an agent that can help you keep breaking them down, a lot of projects do not need to die at 90%.

Still, I do not think the human part got smaller.

If anything, it moved.

Less time fighting basic integration.

More time asking:

  • does the page explain itself?
  • does the product feel trustworthy?
  • does the UI match the culture behind it?
  • does the paid experience feel worth paying for?
  • does the user know what to do next?

That is where I am still struggling.

If you have built web products with AI tools recently, I would love to hear how you handle the final frontend and product-polish stage.

Do you ask the model for multiple visual directions?

Do you design first and then ask AI to implement?

Do you have a workflow that keeps the UI from becoming "technically done, emotionally not quite right"?

That is the part I am still trying to improve.

For context, this is the Bazi calculator I shipped.

Top comments (0)