Professional method

How John Finnerty builds practical technology systems

Practical technology work is rarely about one dramatic fix. It is usually a sequence: understand the real problem, make the smallest reversible change, document the handover, and leave the next person with a clearer system than the one you started with.

Published . About 7 min read.

Illustrated technology systems and project documentation checklist.

Start with the real-world problem

The first step is not choosing a tool. It is working out what is slowing people down. A website may look like a design problem, but the cause might be unclear contact details, missing service pages, weak local signals, broken analytics, or a confusing handover from an earlier provider.

John Finnerty's current work focuses on practical support areas: websites, SME systems, DNS and email, technical SEO, automation, documentation, networking, VoIP, and support workflows. The aim is to make the next step obvious rather than adding complexity.

  • What outcome does the business or project actually need?
  • What evidence shows the current system is failing?
  • Which change is useful, reversible, and easy to explain?
  • What should be documented before the work is handed back?

Make changes reversible

Good technical work leaves a trail. Before changing DNS, metadata, redirects, content, account access, or public project pages, capture the current state and write down how to reverse the change. That habit matters on small sites because one wrong redirect, canonical, noindex tag, or mailbox setting can be hard to diagnose later.

This is the same approach behind the technical SEO audit checklist and SME DNS and email checklist: measure first, change carefully, validate, and keep notes that a non-specialist can understand.

Connect profile, project, and source evidence

A useful public profile should not rely on vague claims. It should connect visible pages: an About John Finnerty page, a New Zealand technology consultant profile, a Projects hub, and project-source context such as the finnerty.me source archive.

The wording matters. A private prototype should be described as a private prototype. An in-development project should not be framed as a launched product. A project note should explain what is visible, what is still experimental, and which related pages support the context.

Document the handover, not just the result

Handover is where many small technology projects become fragile. A clean website, email setup, source archive page, or automation is much easier to maintain when the owner knows: which accounts matter, which settings were changed, which checks passed, and what to watch next.

Before

Record the baseline: current URLs, DNS records, sitemap entries, account owners, and known issues.

During

Make small changes, keep rollback notes, and avoid mixing unrelated fixes into one change.

After

Validate public pages, update internal links, note what changed, and list the next review date.

Where to start

If you are trying to understand John's current work, start with the profile pages and then follow the project notes. For service context, the services hub explains the practical support areas. For search and site-structure work, the SEO consulting NZ page explains the measurement-led approach.