Things I built

The problem

Document requests leave legal teams and their clients guessing about what is still missing.

• Requests go out by email and replies return to different inboxes.
• Staff cannot quickly see whether a matter is waiting for the client or the firm.
• Clients email the firm because they cannot see what arrived or what they still owe.

What I built

MatterFlow puts every request and case status in one shared workflow.

• Staff get one queue, sorted by who needs to act next.
• Clients open a private link without creating an account and see only what they still need to provide.
• Each upload moves the matter forward and creates the next review task automatically.

What changed

MatterFlow now handles the follow-up work.

• MatterFlow sends the reminders that staff used to send by hand.
• Clients can confirm that their files arrived without sending another email.
• Every upload, approval, and change stays in one clear history.

The problem

Community legal centres serve people in crisis, but conveyancing-shaped software does not fit their work.

• Tenancy, family violence, and Centrelink casework have no property, no fee, and no settlement to track.
• Tools built for commercial firms tend to imply compliance checks these centres never asked for and cannot promise.
• Overclaiming to an organisation serving vulnerable people is worse than doing less.

What I built

I retargeted MatterFlow's engine at community legal work, not its payment plumbing.

• The same no-account client portal and audit trail, re-skinned for tenancy, family-violence, and social-security matters.
• Every conveyancing-only step, ID and AML checks, fees, settlement, was removed rather than relabelled.
• The eligibility step stays an honest hand-advanced workflow stage, never a real compliance or means test.

What changed

The same handoff layer now works for an audience the original demo never served.

• Case status is legible to a caseworker managing crisis-driven, not property-driven, matters.
• Client-facing copy stays calm and plain, tested against the family-violence use case first.

The problem

A staged building contract is paid in instalments, and the paperwork around each instalment is where the money stalls.

• Progress claims go out as email attachments, so nobody can say which claim is still waiting on the client.
• Variations get agreed on site and priced later, and unsigned work is hard to recover in NSW.
• The homeowner cannot see what they have paid, or what the next stage will cost.

What I built

Construction Flow splits the contract into priced stages that the builder and the homeowner read from the same page.

• Each stage carries its share of the contract, and the final stage takes the exact remainder, so the stages sum to the contract to the cent.
• Every claim prints its response date, ten business days under the NSW Security of Payment Act.
• The homeowner opens a private link with no account, approves or queries the claim, and signs variations before the work starts.

What changed

The chasing is now the system's job.

• One dashboard shows what has been claimed, what is overdue, and which stage is ready to claim next.
• A signed variation bills on exactly one claim, so it cannot be lost or charged twice.
• Approving the final claim closes the site, and the ledger ends on zero.

The problem

Jen had plenty to share, but no single place where it all belonged.

• She was developing several themes, including travel, career coaching, and Sydney food.
• Her work was spread across a blog, social media, video, and a bookshop page.
• Building a separate site for every theme would split her readers and create more work for her.

What I built

I brought her work together in one site that she could update herself.

• One navigation system connects her career guides, travel writing, and food content.
• The site reads from the blog she already uses, so she does not need a new publishing routine.
• A map turns notes from 77 Sydney restaurants into a quicker, more visual way to browse.

What changed

Jen liked the site and was happy to use it.

The problem

Every model page said its model was good. None showed which one worked best on my laptop.

• I wanted models that could run locally without sending data to the cloud.
• A single test could take hours, which made comparison impractical for most people.

What I built

I tested 54 models on one laptop and published the results.

• Every model was compared by score, speed, and memory use.
• Long tests ran overnight, including one that took more than 12 hours.
• The full dataset stays public, including the models I stopped using.

What changed

The tests gave me a short list of six and showed that bigger was not always better.

• A 43 GB model scored 80%, while a 19.5 GB model scored 93%.
• Other people can use the published results instead of repeating every test.

What I built

I built this one for fun.

• I am a big fan of Final Fantasy VII. I played it as a child, so the subject picked itself.
• I also wanted to know how powerful AI tooling is at building a 3D model, so I chose this object as the work.
• The Ultima Weapon is the strong sword you get close to the end of the game. I just wanted to replicate it in the web world, working from the picture.