I Rebuilt NotaryStyle in Next.js. Here's What I Learned.

NotaryStyle.com started as a standard WordPress site with affiliate links and product recommendations for notaries.

I decided to rebuild it as a custom Next.js application. Not a static site, not a headless CMS, but a full app with its own database, admin panel, and automated deployment pipeline.

Here's what actually happened.

Why I Left WordPress

WordPress stores everything in a database: posts, revisions, settings, plugin configs, user data. Over years that database bloats with post revisions, abandoned drafts, spam comments, and transient data. Every plugin adds tables. Every update risks breaking something.

The maintenance treadmill never stops. Security patches, plugin compatibility, PHP version updates, backup scripts. For a site that's essentially a blog with affiliate links, the overhead was outsized.

Before pulling the trigger, I searched my transcript knowledge base using Qdrant for WordPress pain points. The data confirmed what years of running WordPress sites had already taught me. I needed to get off it.

What I Built

The new NotaryStyle is a Next.js application using:

• libsql (a fork of SQLite) as the database, accessed through Drizzle ORM
• Bunny Magic Containers for deployment (Docker containers triggered by GitHub pushes)
• Bunny Storage as a CDN for blog images
• An admin panel with a full Markdown editor for managing posts, products, categories, and affiliate links
• Automated Docker builds: push to GitHub, container rebuilds, deploys automatically

The database has tables for blog posts, blog categories, products, product categories, product cache (populated from the Amazon API), admin users, and sync logs. Blog posts store MDX content directly in the database alongside metadata like slug, tags, category, featured image, and publication status.

I used Drizzle ORM for type-safe queries instead of raw SQL. The schema lives in TypeScript files, which means the database structure is version-controlled right alongside the application code.

Writing Posts With AI

The old WordPress site had some content, but most of what's on the site now was written for the Next.js app using an AI content workflow.

I built scripts that could generate blog articles, inject affiliate links, add internal crosslinks, and pull relevant stock images. Each batch went through a review pass where I'd check accuracy, fix affiliate link placement, and adjust the tone. Then straight into the database.

The AI handled the heavy lifting of drafting. I handled quality control. The admin panel made reviewing and publishing each post fast.

Images

Blog images live on Bunny Storage CDN. The Next.js config includes a rewrite rule that proxies any request to /images/* to images.notarystyle.com, so image references in blog post content work without needing to update every file individually.

The Amazon API Deprecation

Just as I finished the rebuild and got everything running smoothly, Amazon deprecated the Product Advertising API version I was using. The product cache system that automatically fetched pricing, availability, and product details from Amazon stopped working.

Every product listing on NotaryStyle depended on that API. Display prices, availability status, ratings, review counts. All of it.

I had to migrate to the new API version, update the authentication flow, restructure the product cache sync scripts, and deal with new rate limits and response formats. The migration itself was straightforward code-wise, but it meant touching the product catalog system, the sync scripts, and the admin panel's product management tools.

The timing couldn't have been worse. Or better, I suppose. If I'd still been on WordPress, I would have been at the mercy of whatever plugin handled Amazon product data. Instead, I owned the integration end to end. I updated the code, pushed to GitHub, and the containers rebuilt automatically.

What I'd Do Differently

Don't wait until your WordPress site is big to rebuild. Every post you create in WordPress is content you'll eventually need to deal with. The migration debt compounds.

If I were starting NotaryStyle today, I'd build it on Next.js from day one. The admin panel is more work upfront, but it eliminates years of WordPress maintenance and plugin dependency.

Was It Worth It?

Yes. The site is faster. The admin panel does exactly what I need and nothing I don't. Deployment is automated. When Amazon broke their API, I fixed it in my own codebase instead of waiting for a plugin update.

But if your WordPress site is small and working fine, the ROI of a full rebuild isn't there. Start with custom if you can. Migrate only if the maintenance cost of staying on WordPress exceeds the cost of rebuilding.

If you're building a consulting business and want help standing out, that's what I do. Get in touch.