Building Kinsta’s authority beyond WordPress in 28 articles

Covering the four databases Kinsta sold, then three it didn’t

Kinsta sold managed MySQL, MariaDB, PostgreSQL, and Redis. I covered all four.

Then I wrote MongoDB operators, creating a MongoDB database, MongoDB against PostgreSQL, SQLite against MySQL, and PostgreSQL against SQL Server. Kinsta hosted four databases and those three were not among them. I wrote about them anyway.

Think about where a developer is when they are picking a database. They have not chosen a host yet, and half the time they have not chosen the database either.

So if our coverage stopped where the price list stopped, they could tell. And then the articles would only be worth reading to somebody who had already picked us.

The part of this with someone else’s name on it

Not all of this work is mine to show you.

The categories came before the articles. Node.js, React, Vue, Laravel, and Angular, with API, Python, Docker, and Git underneath them.

I wrote 28 of them inside that structure. Other writers wrote the rest. Kinsta’s application development hub still organizes the section that way, which is the closest thing to a record of what I proposed.

Everything else I did there was the job I was hired for. I was Kinsta’s first Technical Editor, working with more than 20 freelance writers.

The work started at the topic and the outline, ran through the draft review and the pre-publishing check, and finished with an SEO read once a post went live. Every post in those categories that published while I was there went through that.

The React topic archive alone lists 43 articles now, though a good share of them published after April 2023 and I had nothing to do with those.

Working out what a company should be useful about is its own piece of work. Then you hand it to a writer who will do it better than you would, and your name comes off it.

There is no public record of which posts I briefed or edited. You have my word and nothing else, which is why this runs a few lines instead of becoming the page.

The one piece where both audiences turn up

Connecting Python to WordPress is the article I am proudest of from those 16 months, and it is the smallest thing on the list.

It walks a Python developer through talking to a WordPress site over the REST API, with authentication, HTTP client libraries, and the JSON coming back.

A WordPress person reading it learns that their site is an API. A Python person reading it learns that WordPress is something their app can talk to.

I wrote it that way on purpose. Kinsta was asking both groups to believe the same brand could serve them, and one tutorial where they meet does more for that than a positioning statement.

Backups, which is where the product work lived

In January 2023 I wrote the guides for backing up to an Amazon S3 bucket and a Google Cloud Storage bucket. Each one covers a site, an app, or a database.

These two document the product rather than the category.

Someone evaluating a new platform wants to know how to get their data out of it. Answering that early is worth more than another comparison.

Deploying an app to the platform I was writing about

In March 2023 I built a video games aggregator from Andre Madarang’s Laracasts course, pushed it to my own repository, and deployed it to Kinsta Application Hosting. It uses the TALL stack, which is Tailwind, Alpine.js, Laravel, and Livewire.

Madarang designed the project and I built it by working through his course. I wanted to deploy something I had put together myself rather than a starter template, because the interesting part was never the app.

The build went green. I opened the URL and got an error page. I no longer remember what it turned out to be.

A deployment that reports success is not the same thing as an application that runs. The distance between those two events is where a developer’s first hour goes, and I had read our own product copy many times without learning that.

Editing technical content improves a lot when the editor has watched the workflow fail once.

I also worked with Kinsta’s development, product, and sales teams as the subject demanded. I do not have a surviving review record that ties each person to each article, so I am not going to draw one now.

The comparison I could not write honestly and sell at the same time

The database comparisons were straightforward to write, because Kinsta hosted whichever one a reader picked. PostgreSQL against MySQL, MariaDB against PostgreSQL. The product had no stake in the winner.

The best Firebase alternatives was the exception, since Kinsta was one of the alternatives. The archived version from that period lists Kinsta first.

A roundup where the sponsor appears at the top is the thing a developer has learned to distrust, and I was the one publishing it.

I could control the other entries, so I wrote them properly. Back4App, Parse, Kuzzle, Supabase, AWS Amplify, and Backendless each got a straight account of what they do, what they cost, and who they suit.

Parse is free and you can self-host it, and I said so. Supabase gives you Postgres and complex queries, and I said that too.

A developer could read that piece, decide Kinsta was wrong for them, and leave with a shortlist that worked.

Four years on, that article has produced no independently published use I can find. Two comparisons that kept Kinsta out of the running produced 14 citations between them.

One article proves nothing on its own, and I would not build a theory on a single count. I still come back to it.