I built. The result is Huvanti, a self hosted publishing platform on Laravel 13, PHP 8.3, Tailwind CSS 4 and Vite. It runs my live publication at https://huvanti.com every day, and the source is public at https://github.com/pritamsarkar711/project15.

This post is the engineering account, not the marketing one. Architecture decisions, the tradeoffs behind them, the things I would defend in code review, and the two choices I know a lot of you will disagree with.

The shape of the system

One Laravel codebase serves three surfaces.

A public blog front end for readers, server rendered Blade with Tailwind, no client side framework. An admin CMS at a prefixed route group covering posts, categories, pages, navigation, comments, contacts, feedback, ads and settings. An author dashboard, a separate surface with its own controller and its own permissions, where contributors draft and submit but never publish directly.

The important structural decision is that the author dashboard is not the admin panel with buttons hidden by a role check. It is a distinct route group with a distinct controller, because permission by CSS visibility is not permission. Anything an author can reach is reachable because that controller exposes it, not because a Blade conditional forgot to run.

The SEO analyzer, and why it exists twice

The problem with client side scoring

Most editor SEO scores live entirely in JavaScript. They are useful while you type and worthless the moment the tab closes. You cannot query them, sort by them, or audit them.

How Huvanti handles it?

The analyzer exists in two places on purpose. A JavaScript module runs in the editor for instant feedback while typing. A PHP service mirrors that logic one to one on the server, runs on save, and persists the result to a column on the post row.

That mirror is the whole point. The score becomes a queryable field. It appears as a badge in list views. Six months later you can answer why an article shipped at 62 by reading a row instead of interrogating a colleague.

What it grades?

Sixteen checks across four weighted blocks. Title and meta carries the most: focus keyword in the post title, the SEO title, the meta description and the slug, plus length bands of 30 to 65 characters for the title, 30 to 60 for the SEO title, and 120 to 165 for the meta description. Then keyword placement: keyword inside the first ten percent of the body, density between 0.5 and 3 percent, keyword present in at least one H2 or H3. Then depth: 600 words minimum, two subheadings minimum. Then links and media: at least one internal link, at least one external link, alt text on every image.

Two implementation details worth stealing. Density counting distinguishes single word keywords from phrases, using a word boundary regex for the former and substring counting for the latter, because naive substring matching on a single word inflates density badly on common terms. And when no focus keyword is set, the displayed score is capped at 24 even if other checks pass, so an unoptimised draft can never wear a respectable number.

IndexNow, and a failure policy I would defend anywhere

An Ahrefs audit on my old site flagged that changed pages were never submitted to IndexNow. New articles waited on crawler mood, which meant days.

Now every publish, update and delete submits the affected URL to the shared IndexNow endpoint, which fans out to Bing, Yandex, Seznam and Naver. Admins and authors both get manual submit buttons, single and bulk, for migrations.

The policy around it matters more than the feature. The HTTP call has a two second connect timeout and a three second total timeout, sits inside a try catch, and logs a warning on failure. It never throws, never retries inline, and never surfaces an error to the user.

The reasoning is simple. Indexing notification is a side effect. Saving the post is the transaction. A side effect that can fail the transaction is a bug waiting for a bad network day. If you take one thing from this post into your own codebase, take that.

Social automation without the duplicate post disaster

Publishing pushes the post to X, Facebook Pages, LinkedIn, Instagram, Telegram and Pinterest. No SDKs, no packages, direct HTTP against each API, including a hand rolled OAuth 1.0a signature for X because that is what X still requires.

The constraint that took the most thought was idempotency. An author edits a published post at 9pm. Should that trigger another share? Obviously not, but the naive implementation does exactly that.

Huvanti keeps a row per post per network. A successful delivery is recorded and never repeated unless an admin explicitly forces it. Each attempt logs its error text and offers a retry. Every network call is isolated, so a Pinterest token expiring cannot stop the LinkedIn post, and none of them can stop the save.

Credentials are AES 256 GCM encrypted at rest, masked in the UI, and every network has a one click test connection action. A silent auth failure is worse than no automation, because it teaches you to trust something that is not working.

The editor decision, stated honestly

I wrote the rich text editor from scratch. Around 1800 lines of vanilla JavaScript, zero dependencies. Formatting, colour and highlight pickers, lists, indentation, alignment, tables, superscript and subscript, find and replace, source view, full screen, keyboard shortcuts, autosave with crash recovery.

The argument against is real and I will state it fairly. Editor libraries are mature, well tested, and handle contenteditable edge cases that took me weeks. I reinvented a wheel.

The argument for is the one I still believe. The editor is the fastest moving dependency in any CMS and the single most common cause of breakage two years into a project. An upstream API change should never be able to break my publish button. I traded upfront cost for the ability to fix any bug myself in an afternoon.

Roughly half the developers who have looked at this think I chose wrong. I would rather say that out loud than pretend the decision was obvious.

AI with a narrow, defensible scope

The assistant drafts meta titles, meta descriptions, focus keyword candidates, excerpts and FAQ blocks. It does not write articles, and I will not ship that.

The client is provider agnostic against any OpenAI compatible endpoint: NVIDIA NIM on its free tier, Groq, OpenRouter, OpenAI. The admin lists models in priority order. A model that errors, times out or rate limits is marked down in cache for ten minutes and the next one takes over transparently. The last known good model is cached and tried first, which cuts latency noticeably.

Keys are AES 256 GCM encrypted, never sent to the browser, every call proxied server side, with per user daily quotas. The browser never learns the key, the base URL or the model list.

Other things worth mentioning briefly

Uploaded images convert to WebP at quality 78 and cap at 1600 pixels wide, with unicode filenames preserved. Four colour themes and three structural templates compose freely, driven from a single palette source, so restyling the entire product including both panels in both colour modes is a settings dropdown. Auth covers bcrypt, TOTP two factor, CSRF, throttled login and registration, and server side HTML sanitisation on all submitted content. Deployment targets shared hosting through Git auto deploy with a vendored dependency directory and committed build assets, so no composer or npm runs on the server.

What it deliberately is not?

Not a page builder. Not multisite. No plugin marketplace, and that absence is the entire thesis of the project. Not ecommerce. Every one of those is a decision, and each one is why the codebase is still legible to me.

The takeaway

Building your own CMS is bad advice for most people and it was right for me, and the difference is entirely about whether the thing you are replacing is core to your work or incidental to it. Publishing is my work. Owning it changed how often I ship, because the tax on shipping fell close to zero.

Every article on https://huvanti.com is written, scored, indexed and distributed through this exact code, which is the only product endorsement I trust from anybody.

Code, issues and pull requests: https://github.com/pritamsarkar711/project15
Live implementation: https://huvanti.com

If you have shipped a custom editor and regretted it, I would genuinely like to hear where it went wrong for you. That is the decision I am least certain about, and the comments are the cheapest place to learn.