She had tried already. Her organisation needed to replace an ageing WordPress site, there was no budget for an agency, and the obvious move in 2025 was to reach for one of the AI app builders. She used Lovable. It did not work.
Not because the tool is bad — it produced something that looked plausible fairly quickly, and she launched it. The problem did not show up until months later, when she noticed the new site was not showing up in Google at all. Lovable had built it as a single-page application — everything rendered by JavaScript in the visitor’s browser, with nothing for a search engine to actually read — and for a marketing website, invisibility to search is close to a fatal flaw. She had never heard the terms “SPA” or “SEO,” so there was no reason she would have caught it before launch. The tool did not surface it, and nobody reviewing the output with her did either.
The premise
So we did the thing that sounds harder and is actually easier: taught her the real workflow. Git. Branches. Pull requests with review. Continuous integration that refuses to merge broken code. Environment separation and secrets handled properly. An AI coding tool doing the typing, inside a process built on the assumption that it will sometimes be wrong — and inside a pre-deploy checklist that actually asks whether the thing being shipped can be found by the audience it is for.
The bet was that the professional workflow is not harder to learn than the toy one — it is just less marketed. The guardrails that engineering teams use exist precisely because competent people make mistakes constantly. A beginner needs them more, not less. Handing someone a tool that removes the guardrails in the name of accessibility gets the causation exactly backwards.
| # | Stage | What it establishes |
|---|---|---|
| 01 | Repository setup and a first commit | Version control as a safety net, not a chore |
| 02 | Branches, pull requests, review | Nothing reaches production unreviewed |
| 03 | Thinking in structure | Reasoning about data and layout before building |
| 04 | The first real feature | Directing an AI coding tool at a specific, scoped change |
| 05 | Continuous integration | Automated checks that block a broken merge |
| 06 | Deploying safely | Environment separation and handling secrets |
| 07 | Teaching it forward | Onboarding the next person on her own team |
The scaffold matters as much as the teaching
She did not start from an empty folder. She started from a repository that already had the guardrails installed: branch protection requiring review before merge, a continuous integration workflow blocking merges on failure, a pull request template, a pre-deploy checklist, and a written conventions file explaining not just the rules but why each one exists.
That last piece did more work than I expected. An AI coding tool reading a conventions document behaves substantially better than one guessing at house style — so the same file that taught her the standards also enforced them through the tool she was using. The scaffold teaches in two directions at once.
Where it ended up
About three weeks separate “I don’t know what GitHub is” from managing a production website she built in Claude Code and deployed herself, on Vercel — and unlike the Lovable attempt, this one shows up in search. The WordPress site is gone. That is the smaller half of the outcome.
The larger half is that she is now training her own colleagues on the same workflow — running them through GitHub, reviewing their pull requests. The organisation did not acquire a website. It acquired an internal technology capability, resident in a staff member who was already there and already understood the mission.
The same pattern held inside Aclymate, where our Chief Marketing Officer took a production website project end to end under the same setup. Two people, different organisations, neither with an engineering background, both now shipping.
~3
Weeks from no coding background to a deployed production site
0
Prior engineering experience, in either case
2–3
Colleagues she has since onboarded herself
Why this is the offer, not a side effect
Most organisations with a technology problem do not need a permanent engineer. They need one person on staff who can be responsible for their systems — who understands what changed and why, who can direct an AI tool at a real problem, and who will not let unreviewed work reach production.
That person almost always already works there. They know the domain, they care about the outcome, and they are not going to leave in eighteen months. What they are missing is the workflow and the scaffold, and both of those are teachable in weeks.