James Lawrie introduces WikiNative Studio for professional Wikipedia editing and page creation

2 November 2026

Creating and editing Wikipedia pages for paying clients requires a lot of organisation. Clients will typically spread their brief across a dozen emails, documents, press URLs, maybe a structured Excel spreadsheet if you’re lucky. More often than not, it’s up to me, as the freelancer, to structure the client’s materials and turn them into a first draft.

Often, the client has prepared an unverified company history or biography written in the third person, based on vague memories or elaborate interpretations of the source material. Whether the client has prepared something in-house or not, my process is the same. I determine which sources contribute towards establishing Wikipedia’s definition of notability, then discard any sources that don’t.

Only then will I write the first draft in my LEUCHTTURM1917 notebook using my gold-plated 1960s Parker ballpoint. Or, if the client has shared an attempt at a “wiki page”, I will delete everything that doesn’t contribute to notability or cannot be verified. The latter takes longer, but the outcome is the same regardless of the drafting process.

Writing a Wikipedia page is not a creative process. It is a deterministic process. The outcome is predetermined, and the client and I arrive at the outcome via:

Input	+ process	= outcome
Sources that support notability	Wikipedia’s content policies, guidelines + manual of style.	A Wikipedia page that shows (not tells) why the subject is notable.

Previously, I relied on Google Docs as my project’s central hub, with sources, communications, and supporting documents spread across email, Docs, PDFs, and numerous other file types.

Finally, after working with my clients in Google Docs and agreeing on a draft to format and upload to Wikipedia, I would then have to format the page in wikitext markup using Codeblock or TextEdit, test the code in a Wikipedia sandbox, preview it without publishing it, screenshot the preview and share it with my client, then save the working code to a new .txt file. The code usually needs another update on upload day because Wikipedia’s verification process is baked into the citation templates, and stale metadata raises new reviewers’ eyebrows. Simply put, every stage of my process required tools that weren't built for the needs of a professional Wikipedia editor.

While this was manageable with an average workload of four or five projects per month, it wasn’t scalable. I needed a platform to manage every aspect of my projects. So I created WikiNative Studio. It took me four years to plan and build my platform whilst running a busy Wikipedia consultancy service single-handedly.

Wikitext is very easy to work with when you’re using it to create and edit Wikipedia pages. However, using it to build a platform that could accommodate several overlapping workflows such as draft review, research, client review and comments, notability assessments, client edit request viability assessments, source organisation and verification, all within private client spaces, took a lot of time to conceptualise and build.

I am often mistaken for a Wikipedia agency. However, so-called Wikipedia agencies usually consist of one person outsourcing their client’s work to third parties via freelancing websites such as Upwork. These providers are usually unreliable and compromise the project’s secrecy and the client’s confidentiality.

My clients are usually notable people or organisations from the United Kingdom. Sometimes I work directly with the article’s subject, who might be a private individual or organisation. Or I might work with the subject’s nominated representative, usually a third-party contractor such as a public relations firm, publicist, agent, public relations consultant, or assistant. Sometimes there might be more than one team member, and other times a third party might represent multiple subjects.

Subsequently, no two projects are alike. There is no typical Wikipedia client, so I built my Wikipedia project-management platform with user-friendly dynamics and flexibility as its overarching design principles. I curated my platform using insights gleaned from numerous projects spanning multiple years. I learned that while each client is unique and whether I am managing a live Wikipedia page editing project, a new page creation project or performing an exorcism on a previously declined Wikipedia draft, my workflow involved three distinct stages:

1. Preliminary assessment

a) Compiling sources for the preliminary assessment. Upon activating your WikiNative Studio account, I recommend using Studio’s source uploader. It accepts all file types, including PDF, JPEG and Excel. It also accepts links to online articles. It does not accept audio files. These should be submitted as verbatim transcripts in .docx format.

b) Like most forms of academic writing, Wikipedia writing relies on secondary sources for structuring articles and demonstrating notability. Therefore, parsing secondary sources from primary sources produces better notability assessment outcomes and thus optimises the Wikipedia page publication.

Optimum source selection is a skill derived from experience, and I will gladly put my many years of experience to work selecting sources that support notability and carrying them forward to the notability assessment.

c) If my client wants to edit an existing Wikipedia page about themselves or their business, then organising the source pool becomes part of the preliminary viability assessment.

The first step in a preliminary viability assessment determines whether the subject has the right type of sources to support the changes they want to make. Wikipedia does not publish original research, and anything that I publish on Wikipedia requires a straightforward verification route for Wikipedia’s editors or public to follow if they wish to fact-check my work.

d) Notability assessment. The notability assessment gives the client and me a clear picture of what sources a notability-focused page creation about a subject should include and what the drafting strategy should be.

Thursday 5 November

2. Drafting

a) Writing and publishing a Wikipedia page is a deterministic process. The first step is to organise the sources and determine which ones support notability. Drafting arranges the knowledge from those sources by applying a neutral point of view, checking verification routes, and removing original research such as elaboration or synthesis. I write the first draft in my notebook and then bring it to life in my client’s private space in WikiNative Studio using wikitext.

b) WikiNative Studio is a wiki. It runs on adapted MediaWiki architecture. It uses the same templates as Wikipedia, and it uses the same code. However, each one of my clients’ spaces in my studio is private to them. My studio is not connected to Wikipedia.

This posed a problem during development. Internal links to other Wikipedia pages are one of Wikipedia’s most compelling features. WikiNative Studio needed a way to map a draft’s internal wikilinks, but Wikipedia’s internal-link code renders dead red links when deployed outside of Wikipedia’s ecosystem.

I solved this problem by building my own wiki-encyclopaedia. It’s a general encyclopaedia, but its modest article count of roughly 60,000 articles is usually enough to resolve most red links (internal links), while the external links function as normal.

c) Preparing royalty-free images and fair usage exemptions for logos is a vast topic which I will cover in a separate open letter. Both are handled within WikiNative Studio, and the images’ copyright still applies.

d) Revisions and refinement.

Previously, I relied on the comments in Google Docs or email for collaboration. Neither tool was purpose-built for creating Wikipedia pages. The markup often became unwieldy, and large comment batches didn’t align with the draft’s text. I circumvented this problem by reinventing the wheel.

The draft scrolls top-to-bottom as usual, but WikiNative Studio has a comment wheel at the core of its collaborative features. Studio users view it from a top-down, edge-on perspective. Gentle shading and a freehub sound produce the rotation effect. Clicking a comment auto-aligns it with its corresponding revision, word or sentence. Conversely, clicking a highlighted revision automatically locks the comment wheel into place.

Additionally, each WikiNative Studio draft has a discussion page where Studio users can suggest longer passages of text and have more in-depth conversations with me, without the fragmentation that complex email chains with multiple participants are prone to.

3. The upload

a) Before uploading the page directly to Wikipedia from one of my many Wikipedia accounts, I perform some final checks. I check the wikitext by eye, and I manually check the article’s verification routes and neutral wording.

Then I perform a simulated upload. Each private client space in WikiNative Studio has a built-in Wikipedia simulator. I used the edit histories of the most ruthless and pedantic Wikipedia editors and new page reviewers to simulate their consciousness and behaviour. I got the idea from the Black Mirror episode USS Calister. Playing pranks on simulations of my least favourite Wikipedia editors got boring after a day but SimSpace provided a solid testing ground for my client's Wikipedia content so I bundled it into WikiNative Studio.

Each SimSpace is private, but when I move a draft into SimSpace, any number of things might happen. If the client and I have created the page robustly and in line with Wikipedia’s content policies and manual of style, then SimSpace’s virtual editors will approve the page, in which case it is good to go live on Wikipedia. If the page contains original research or promotional language, they will tag it, report it on the discussion pages, and they may even simulate a deletion nomination and discussion.

The simulation’s activity is logged, a report is generated, and I use those insights for improving the draft. Then I repeat the process until the draft is perfect.

b) When the draft is perfect, I publish the Wikipedia page on the English Wikipedia from one of my many accounts. I do not declare a conflict of interest because COI disclosure only applies to rookie editors who don’t know the rules.

WikiNative Studio strengthens compliance with Wikipedia’s content policies, guidelines and manual of style. Sources go in one end, and high-quality human-created encyclopaedic content comes out of the other end.

Who is WikiNative Studio for?

Like WikiNative, WikiNative Studio is for clients who have already earned considerable media attention. Studio provides a space clients who have the earned media to support a credible Wikipedia entry or realistic updates to write, plan and refine content that enriches Wikipedia. Clients who wish to misuse Wikipedia as a shortcut to credibility or reputation laundering won't gain any benefit from WikiNative Studio. I built my software to speed up workflow and facilitate compliance with Wikipedia's editorial guidelines and formatting standards. Clients who wish to make meaningful contributions to Wikipedia will benefit from my editorial guidance on one, organised platform. If you are looking for a yes man, a budget service or a passive page uploader then there is not a Wikipedia publishing service in the world who can guarantee positive outcomes for you.

Welcome to the future of paid Wikipedia editing. Welcome to WikiNative Studio.

My manifesto