Working proof · Products, platforms, systems

Built

"I build systems that last" is a claim, and claims need receipts. This page holds them: the products, platforms, and systems behind that sentence.

01 1CARTON

1Carton.

SaaS accounting and operations software for small businesses, in build.

1Carton is small-business software with an accountant’s ledger underneath it, and I am building it myself, from the architecture down: Laravel on the back end, Svelte in front. It is designed for the businesses caught between entry-level bookkeeping apps and heavyweight enterprise systems: flat monthly fees, payment-processor costs passed through at cost and never padded, and Canadian client data hosted in Canada by design. Every pricing and architecture decision answers one founding question: is there a better, cheaper route to the same or better quality? What it proves: the diagnosis and the build come from the same hands.

Status In build, Canada first.

02 XFORGE

xForge.

The AI-assisted system that lets one builder deliver like a team.

One builder cannot match a team by adding hours; the hours do not exist. xForge closes the gap with a system: codified skills, repeatable delivery pipelines, and hard guardrails that hold AI-assisted work to the standard of reviewed work. Conventions, brand rules, and quality checks carry from one project to the next instead of being rebuilt each time. It is why a SaaS product, client platforms, a teaching load of 200+ students a year, and this site can advance in parallel. What it proves: Systems, Not Symptoms, applied to my own workload before anyone else’s.

Status In daily use on every build, this site included.

03 GOADEDOKUN.COM

goadedokun.com.

This site, run as a live demonstration of the method.

The page you are reading is an exhibit. The brand system lives in one canonical source and flows one way into this codebase; nothing downstream is hand-edited, and drift gets flagged before it ships. Colour, type, and spacing draw from a named token system, so the whole site can be re-themed from a single file. Even the house rule against em dashes is enforced by a script in the build. What it proves: the method is the message; the discipline described on this page is the discipline that produced the page.

Status Live. You are reading it.

04 OPERATIONS STACK

A self-hosted operations stack.

Automation and hosting on infrastructure I control.

The automation workflows behind my work run on n8n I host myself, and much of the hosting runs through Coolify on Hetzner servers I administer, assembled open-source first: self-hosted tools over subscription equivalents wherever the quality holds. That is a design decision twice over. Cost discipline, because recurring software fees compound the way interest does, and an accountant notices. Data ownership, because operational data should not live as a tenant in someone else’s product; the site analytics and the subscriber list move onto the same infrastructure as they launch. And cost discipline is not cost cutting: security, backups, and reliability stay non-negotiable.

Status In daily operation.

05 CRM AND OPERATIONS

CRM and operations platforms.

Custom systems for family businesses and co-founded ventures.

Client and related-party names stay off this page, but the work is real: a custom CRM platform for a travel and immigration advisory firm, in build now, and an operations stack for a moving and storage venture, queued in the same delivery pipeline, both for family businesses and ventures I co-founded. Related-party work is an honest proving ground: the requirements come from operators rather than briefs, and the accountability does not expire when an invoice is paid. Each build runs the same arc as everything above: diagnose the operation, build the system, hand it to the people who run it.

Status In delivery. The CRM is in build; the operations stack is queued in the pipeline.

House rules

How I build

Four house rules run through every item above. The framework behind them, the one this site is named for, is written up in the Ledger as "Systems, Not Symptoms: the diagnostic framework".

Diagnose first.

The root cause lives in the numbers; find it before building anything.

Systems over one-offs.

Tokens, templates, and pipelines, so fixing the system once fixes every instance.

Open-source first.

Self-hosted over subscription wherever the quality holds; the better, cheaper route usually exists.

Teach the owner to run it.

The handover is part of the build. A system only its builder can operate is a dependency, not an asset.

Read the framework

A problem that comes back after every fix is not a problem; it is a system asking to be rebuilt. Every entry above answers one: books a growing business keeps outgrowing, a workload no extra hour could absorb, brand drift no manual check would catch. If your business has a problem that keeps returning, tell me what it is.

Start a conversation