FinCalcHub is a small, named operation — not a content farm. Every calculator, every guide, and every blog post on the site is written by hand by a real person whose byline is attached to it. We don't publish AI-generated content, we don't accept ghost-written articles from product issuers, and we don't run anonymous contributors. Today that means one author; if the team grows, every new writer will appear here first.
This page is the directory. It exists so that anyone reading a calculator or guide on the site can see, in one click, exactly who wrote it, what they do (and don't) claim expertise in, what their potential conflicts of interest are, and how to reach them. Every author profile carries the same structure: background, areas of focus, sources used routinely, editorial responsibilities, what they explicitly don't do, where to find them elsewhere, and a contact link. Schema-level author and about properties on every article point back to the relevant author's profile here.
Every calculator and every article on FinCalcHub is written and reviewed by a named person. The byline appears on the page itself, in the JSON-LD author property in the page's structured data, in the OpenGraph metadata served to social-media previews, and (where a credentialed reviewer is added in future) in a reviewedBy property that names both the writer and the second-checker. There is no "Staff Writer" credit, no anonymous "FinCalcHub Team" byline, and no AI-generated content published under a fictitious author's name.
What attribution means in practice: if you read an article about UK National Insurance on this site, the byline tells you who chose the figures, who wrote the explanation, and who is responsible if anything in the article is wrong. The same person's name is in the schema, on the author profile page, and on the email you'd send if you wanted to report a correction. Attribution is not a vanity exercise — it's how a small publication earns the right to be trusted on tax tables and retirement math.
The site is structured around a two-role model: author and reviewer. Today, both roles are filled by the same person — James Blanckenberg — because FinCalcHub is a single-author publication. Every article is written by James, and every article is re-read against the primary source by James before it goes live. That's the current state.
The planned future state adds a second, credentialed reviewer. Most likely a chartered tax adviser (CTA) for tax content and a chartered financial planner (CFP) for retirement and pension content. When that happens, the reviewer's name and credentials will appear on this page, on the relevant author profile, in the article byline ("written by … reviewed by …"), and in the article's reviewedBy schema property. The reviewer's role will be to second-check the figures, the formula, and the explanation against the published rules of the relevant regulator. The reviewer will not be allowed to change the editorial line of the article — their job is verification, not authorship.
Why bother distinguishing the roles before the reviewer exists? Because the structure makes the future state easy to slot into. The article schema already has a reviewedBy slot waiting for a name. The author profiles already have a section explaining who reviews what. When the credentialed reviewer is hired, the only thing that needs to change is the name in the slot.
FinCalcHub doesn't currently accept external contributors, but the door isn't permanently shut. If we ever do, the bar a new writer would need to clear is the same one the site is built on. A prospective contributor would need:
If that describes you and there's a topic you'd want to write about on FinCalcHub, email [email protected] with a short pitch and links to two or three pieces of your published work.
Every author on this page works to the same set of editorial standards. The full version is on the editorial policy page, but the short version is four rules: real numbers (every calculator runs the actual published formula); primary sources only (HMRC, SARS, the IRS, the Bank of England, the ONS); no commission take (no affiliate fees from product issuers); plain language (no jargon without a glossary entry). Every article carries a visible "last reviewed" date, every figure is checked against the primary source before publication, and every reader-reported correction is acknowledged within 24 hours.
The current state of AI in financial publishing is that many sites generate large volumes of content with minimal human review, attached to plausible-sounding fictitious bylines. FinCalcHub does not. Generative AI is used at the site for routine editorial scaffolding — generating headline variations, cleaning prose pass-throughs, and suggesting structural improvements to drafts — but every published article is written, fact-checked, and bylined by a named human. No article is ever auto-published. Every figure is verified against a primary source by James personally before going live, regardless of whether an AI tool was involved in any drafting step.
Where AI is explicitly not used: choosing the tax bands or contribution limits for any calculator; selecting which figure to cite from a regulator's data set; writing legally sensitive content on the privacy, disclosure, or terms pages; or generating any image, infographic, or chart that appears on the site. The reason for these guardrails is simple — these are the places where a generative-AI hallucination could mislead a reader on something material to their financial decisions, and a human reviewer is the only reliable safeguard against that.
When a reader emails about a possible error, the workflow is the same regardless of the article. Within 24 hours the message is read and the cited page checked against the regulator's current published value. If the reader is right, the correction is made on the live page within 48 hours, the "last reviewed" date is updated, and a brief note is added to the article footer for material changes (anything that would shift a calculator's output by more than 1%). If the reader is mistaken — for example, citing an outdated PDF when the regulator has since updated its rates — we reply explaining what we believe the current correct figure is and link to the primary source. Either way the email gets a personal reply.
Substantive corrections that affect multiple pages (a UK tax band change at Budget, a US contribution limit announcement in November, an SA bracket update in February) trigger a sweep rather than a one-page fix. Every related calculator, blog post, and reference page is checked against the new figure, the affected pages are updated in a single coordinated change, and the corrections log records the date and the reason. This is the same workflow used by editorial teams at much larger publishers — at this site's scale, it just runs through one person rather than a chain of editors.