From zero to a production platform

I did not study computer science. I trained in physiotherapy, moved to Canada, and worked my way through operations: an executive assistant's desk, then running operations for a small agricultural company, then leading a warehouse team on SAP. In July 2024 I joined a publicly listed commercial-equipment company in international trade, where I look after logistics, warehousing, daily operations and customer service for one branch.

I started using AI in 2025. This is how it went, in order, with the mistakes left in.

Procedures came first

Before I built anything, I wrote the branch's operations procedure (more than 50 pages) and its customer-service procedure, using SCOR and SIPOC to map our own work. At the time it felt like paperwork. It turned out to be the specification. Six months later, the supervisor checklist in that procedure became the order platform's missing-information checks.

Software can only enforce a decision that someone has written down.

Small tools, built in a chat window

My first tools lived where I already worked: spreadsheets with Office Scripts, a Power Automate flow, then single-file web pages. The AI wrote most of the code. I brought the data, the rules and the complaints.

By mid-2026 I had a nine-module warehouse dashboard, a read-only SQL explorer with 47 templates so colleagues could pull their own data, a browser extension that kept the team's work board in step with the warehouse's pick and ship status, and document tools for pick lists and shipping manifests. All of it is on the work page.

Thirteen rounds to find one column

In June I needed to know which bin a serial-numbered unit sat in. I spent thirteen rounds guessing table and field names. Every wrong guess returned the same -1, which can mean a syntax error, a wrong column count, a missing field or no permission. Twice I called it a dead end because one table was empty or locked.

The answer came from one query against the database's own column catalogue: list every table that has a bin column. That should have been the first step, not the thirteenth.

What I kept: when you are looking for where something lives, search the metadata and never guess names one by one. An empty table is not proof that the thing you want does not exist.

A prototype, and a rule about guessing

In July I built a purchase-order intake prototype on a workflow tool. It had three ways in (a form, an email attachment, the email body), an extraction step that copies text exactly and never rewrites it, and a rule engine that checks every line against the full item master.

The rule I kept from it: an automatic correction needs exactly one candidate and a second signal that agrees, such as the size in the description. One item code in the test set had two real neighbours one letter away: a drawer model and a single-door model. Guessing there means shipping the wrong unit.

The trial ended and I let the prototype go. The copy-only extraction and the correction gate both live on in the platform. That month I also wrote my first four agent skills and set up two research tasks that run every week.

A coding agent on the work machine

In August I put a coding agent on the work machine. In one session it moved two jobs out of browser extensions into a single Node service that starts at sign-in and is checked every 15 minutes by a watchdog. The mistakes from that week became permanent rules:

• A heartbeat that rewrote the whole status file erased the cycle summary one second after it was written. The service was healthy and the status screen said it had never run.
• A guard that refused a second copy of the service wrote "failed" into the first copy's status.
• A setup script printed "watchdog added" after the scheduler had rejected the change. Now every script writes, reads back, and reports what the read-back says.
• A feature in the old code had never run in production, so copying it faithfully would have created a dozen wrong labels on its first real run. Only code that has actually run is a specification.

Four days, 28 work packets

In September I started writing work packets: a short contract with the goal, why it matters, what done means, and every red line with its reason. The agent decides how.

Over four days, 28 packets turned a single web page and a browser extension into a shared-folder store, a local server per person, a static desk app and a background service. The architecture has its own story. Midway, management decided the order desk must not depend on the work board. Four constraints were already in place (every feature a module, one transport layer, no shared dashboard, rules outside the code), so the change took 24 hours and nothing had to be rewritten.

On 28 September the platform went into daily production on the live ERP company.

October: a method, measured

With more than 100 packets behind me, I started measuring how I work: where the AI bill goes, which model does what, and how to prove a change before it ships. Most of what I know now came from something going wrong and being written down the same day.

What I would tell someone starting

• Write the procedure before the tool. The rules have to exist somewhere a machine can read them.
• Keep a lessons file and add to it the day something breaks. Mine holds 40 lessons and 72 anti-patterns.
• Never accept "nothing found" until the same check has found something you planted.
• Let the agent write the code. Keep the decisions about money, permissions and production for yourself.