Rune · Kaiapoi, North Canterbury
Rune is one person, Josh Jagger. Online stores, paid course and membership areas, and the plumbing that stops you typing the same order into three different systems. Rune runs all of it every day for a shop in Kaiapoi, so none of it is theory.
On now: a paid course area and booking flow for a Rangiora coaching business. See it.
Rune takes on work it can finish well, and quotes by the job so you know the number before anything starts.
New builds, and the messy ones fixed
New shops, and tidying up existing ones that have got out of hand. Product pages, the way things are grouped so people can find them, postage rules, and the checkout itself. The shop Rune looks after every day has 2,817 things for sale in it, so a big range is nothing new.
Turn on what your platform already has
Putting content behind a paywall on a site you already own, with card payment set up and properly tested. Most small-business platforms include a membership feature nobody has ever switched on. Often the whole job is getting that working, with no rebuild needed.
One stock number, everywhere
Your till, your website, your marketplace listings and your courier all working from the same stock number, updated without anyone retyping it. This is the work that quietly gives you your evenings back.
Set up in the build, kept up after it
Getting your products described properly, so they turn up when someone searches, is part of every store Rune builds, and it carries on after the build. The first job is usually making sure Google can read your shop at all: on the Kaiapoi shop the share of products with a proper Google title and description went from about 4% to about 46%. Search is slow work, so expect nine to twelve months before a ranking really shifts, and Rune reports what changed as it goes.
A gift shop in Kaiapoi with a website that couldn't take an order, and a business still being run on paper behind it.
The shop opened in early 2019 as a home-based side project selling crystals locally in North Canterbury, and grew on local support alone into a main-street store on Williams Street. It is a family business, and Rune runs it day to day rather than working on it at arm's length.
It wasn't invisible online. There was a basic brochure website, and a Facebook page where new stock was posted by hand every time a box arrived. Neither could take an order. The business itself ran the way it always had: sales written down by hand, stock counted on paper, and nothing online connected to either.
So the honest description is an online presence with no online operations. Rune was brought in with one brief: replace the manual processes with digital ones.
One piece of software does all of it: the website, the till on the counter, and the jobs that used to be done by hand out the back. All three read and write the same set of records, so the shop floor and the website have never disagreed about how many of something is left.
None of it was bought off the shelf. Passwords and keys are kept out of the code itself, which a security review confirmed, and there are 263 checks that run by themselves before any change reaches the shop, so a change that would break something gets stopped before anyone sees it.
The share of products with a proper title and description for Google went from about 4% to about 46%, and all 65 groupings of products picked up both, where before they had neither. Rune built 16 new groupings around how people actually shop, and found one that had quietly swollen to 4,064 products.
The photo backlog fell from roughly 1,800 products to 1,331 of 2,817 active ones. That's 47.2%, down from about two in three only three weeks earlier, and the figure comes from a full bulk export rather than a sample.
Online orders moved from about 3 a week to 9 in the week of 24 August. Visitor numbers stayed flat, so that came from more of the same visitors deciding to buy: out of every thousand people who came to the site, 22 bought instead of 8. Two checks sit behind those numbers. Rune compared 425 counter sales against the website's own records one by one and every single one matched, and after Google complained about the product information, went through all 4,151 items to see which barcodes were real.
The 9-order week was a spike, not a step change, and the weeks either side sit nearer two. And when the traffic was checked properly in September, about 39% of recent sessions turned out to be overseas bot traffic, so the real visitor numbers are lower and flatter than the analytics first suggested. Better you hear that here than find it later.
This is the part worth reading if you are deciding whether to hire someone. Everything below happened in production.
The picker was not broken. It was starved. Incident 05, where the first fix was wrong
Order #2892 was paid for and recorded correctly, then sat unfulfilled in the queue with no error anywhere. Shopify's fulfilment API was rejecting an empty tracking-URL field, and failing quietly when it did.
The root cause was fixed by leaving the field out entirely instead of sending it empty. Rune then went looking and found the same hidden fault in the path used by ordinary online orders. It hadn't fired there yet. It would have.
One order kept returning "no courier options for this parcel or address", including with a hand-typed custom size, which ruled out the parcel. The real cause was the address: street, suburb, city and country had all been typed into a single field, leaving the suburb blank, so the courier couldn't match it to a delivery zone.
Rune shipped an editable address block that flags that exact shape, so staff catch it at the counter before they book.
Meta descriptions drafted by the model ran 8 to 30 characters over Shopify's 160-character limit, despite the instruction saying 160 maximum. A model treats "maximum" as a strong suggestion.
Rune stopped rewriting the instruction and put a hard limit in the code itself, cutting at the last whole word. The limits have been built into the code everywhere since.
The staff member doing the photography reported that adding a good photo left the bad one in place, with no way to remove it without going into Shopify directly. Three causes had stacked up: uploads appended instead of replacing, the editing screen only knew about one image, and the single delete button deleted every photo on the product, so the one control that looked like the fix would have destroyed her new photo too.
Rune replaced it with a proper gallery, one delete per image and a "make main" control. Then it took three refreshes to appear, which turned out to be a second bug: the cache headers covered the photo pages but not the main app pages.
The tool that picks a product to post kept choosing pendulums. The picker wasn't broken, it was starved: staff had photographed two large batches of pendulums back to back, about 57 of them, and they filled the entire pool of newest products it drew from. The first fix widened the pool and shipped. It didn't work, and the person using it said so.
The second fix went at the mechanism instead of the symptom, capping how many candidates can share the same product type before the shuffle happens. The first attempt was wrong, and it was the feedback from the person using it that caught the mistake.
Search Console flagged bad barcodes right across the shop's products. The theme was publishing the shop's own internal 8-digit till codes as if they were global product numbers. An audit of all 4,151 products found 3,762 internal codes, 43 genuine barcodes and one value pasted in from somewhere else entirely.
The till codes had to stay, because the shop scans them, so the fix was to stop publishing them: hand-written structured data that only emits a barcode when it's genuinely 12 to 14 digits. Confirmed on the live site.
A paid course area that only members can open, and a way for people to book time with her, both built inside the coaching website she already had.
Living by Design is a Rangiora coaching business with a retirement-transition programme that already existed in two parts: a published book and a workbook of 30 exercises. The third part, the guided digital version people pay for, is what Rune was engaged to build. The business is named here with written permission.
She already had a website she pays for monthly, and no appetite for a second one. So the whole build sits inside her existing site, on the platform she was already paying for. That cost her nothing extra and saved moving everything onto a new site, which she did not need.
Before quoting, Rune went through what the existing platform could actually do. Several things the client wanted turned out to be built in and switched off, which is the usual finding. Some things genuinely weren't possible, and Rune said so in writing before any money changed hands.
Trust what the system does, not what the company says about it. When the payment gateway closed mid-build
The payment gateway we'd agreed on stopped accepting new New Zealand signups partway through the build, after the company behind it was acquired. Their public announcements still said New Zealand was supported. What actually happened when the client tried to register was a redirect and a message saying the country wasn't ready yet.
Rune trusted what the system actually did over what the company said about it, told the client the same day, and moved the build to Stripe instead. It turned out there was already a verified Stripe account nobody had remembered, which removed the signup step entirely. Card payment is connected and live on the site now.
None of this was what Rune was hired for, and it was worth flagging while the pages were still empty and cheap to change. One lesson tells the reader to assess six areas of their life, and the exercise that follows gives them eight, so anyone following along hits two questions they weren't prepared for. A lesson heading also had a typo in it, which matters more than it sounds: headings become page titles and web addresses, so that one would have gone live and been picked up by Google with the mistake in it.
The structure is finished and tested. Her written content started arriving on 4 September, beginning with the whole of module one and the first two exercises. The videos aren't recorded yet, and she's starting on those now. Nothing is public until she's clicked through it herself and signed it off.
This build isn't finished and hasn't launched, so there are no sales figures, no completion rates and no traffic numbers to show. When there are, they'll go here. Rune is not going to estimate them in the meantime.
The client has agreed in writing to this being a public case study. Rune will ask for a testimonial once the work is done and she has used it herself.
Everything above was built by directing AI development tools instead of typing every line by hand. Rune treats that the way a builder treats a nail gun: it decides nothing. Rune decides what gets built, reviews what comes out, tests it, ships it, and takes the call when it breaks at four on a Friday.
That's why the incident log in the Simplyb case is there. Anyone can show you a finished screenshot. What tells you whether someone can actually run a system is what they did the day it failed in front of a paying customer.
Most of Rune's work arrives by word of mouth. If someone has passed on the name, this page is here so you can see what has actually been built before you ring.
Rune quotes by the job, not by the hour, because you can judge a finished thing and you can't reasonably judge an hourly rate for work you don't do yourself. If something turns up outside what was agreed, you hear about it before the work happens, not after.
Email is the best way to reach Rune. Say what you sell and what's going wrong, and you'll get a straight answer on whether this is the right fit and what the job would cost. Every email is read by the person who would do the work, and you'll hear back within one working day. No charge for the conversation.
Online stores & membership sites