Innerlogic / Customer enablement / July to October 2026
A help site for a small team
Innerlogic helps organizations run employee surveys and act on the results. A lot of the people using it are HR folks who log in a few times a year. Every time, they needed someone from our team to walk them through it again.
We were giving every customer the kind of custom onboarding you’d normally save for your biggest accounts. That doesn’t scale for a small team, and it doesn’t really help the customer either. They’d rather just figure it out. So I offered to lead a knowledge base project.
I led the project: strategy, platform choice, scope, content, build, and QA, using Codex and Claude Code. The help site has been live in English and French at docs.innerlogic.com since October 2026, with eleven guides and a weekly accuracy check.
Deciding what to build
I went back through six months of customer meetings and pulled out every request for self-serve help. One obvious option was in-app tours. I didn’t want that. I’d rather fix the product so it doesn’t need one. With our customer success lead, we settled on three parts: make the product more intuitive, publish guides anyone can find, and keep private resources for the enterprise customers who need them.
Our engineer suggested building the site ourselves. I thought the upkeep would cost more than it saved, so I put the numbers side by side, including how many maintenance hours it would take before building stopped saving money. We went with a hosted platform that works from files in GitHub, which meant the AI tools I was already using could keep it up to date.
Did a customer ask for this?
By September the plan had grown. One item was a benchmark comparison guide, and I couldn’t remember anyone asking for it. When I asked where it came from, the AI agent I was working with admitted it had added it on its own. No customer had asked.
A university customer had already sent us the list of guides their HR partners needed before a training session. I made that list the source of truth, rewrote the backlog against it, and dropped the extras. For launch, we checked whether we’d covered their list.
Making sure it’s right
AI wrote help articles quickly, but it sometimes described screens that didn’t exist. So every claim got checked against the product’s code, and then I walked through it in the browser as a first-time user. That caught real mistakes, like a survey described as closed when it was open, which hid a whole step.
I also had the agent record the how-to videos itself by scripting the browser, after my own recordings missed the cursor and exposed details that shouldn’t be public.
The week after launch
About a week after launch, another customer told our customer success lead they’d looked in the help site and found only sign-in help. They wanted guides on tracking survey participation and creating automated reports. It was the first sign that a customer was using the site, and it told us what was missing. We published both guides, in English and French, the same day.
The first draft wasn’t right, though. The agent had checked the guides against the screens, but not against the rules behind them, like who’s allowed to change a report. I had it recheck every sentence against the backend, and made that the rule from then on: check the code before writing anything.
Keeping it true
Help sites go stale, because every release can make a page wrong. A small team can’t spend its time rereading guides. So I set up an automated Claude project that runs every Tuesday morning. It looks at what changed in the production code, then opens a draft change saying what’s different and whether any guide needs updating or adding. I review it, and that’s most of the maintenance: a weekly check, plus anything ad hoc.
Its first run found a troubleshooting step that a September product change had left out of date. If a feature is still being tested, it stays out of the guides until it ships.
The same week, our customer success lead had their own AI review the site and sent me twelve issues. I had each one checked against the code and the live product. About half needed fixing. A few described plans from meetings rather than what customers could see, and the agent wrongly flagged something deliberate as an error, then took it back.
I’m proud of this part. Keeping the help site right doesn’t take time away from building the product, and it’s heading toward maintaining itself. That’s the promise of an AI startup with a small team: automate the manual work as far as it reasonably goes.
Where it landed
The help site is live in English and French, with eleven guides. Every change is tracked in Linear, the content lives in GitHub, and colleagues who don’t use GitHub review it through a synced copy. The weekly check keeps it in step with the product.
A customer has already used it, found a gap, and asked us to fill it. Someone also searched for how survey takers sign in with SSO, and we don’t have a guide for that yet.
What I took from it
Working with AI agents let me take this from an idea to a live site mostly on my own. A lot of my job was asking whether a customer had asked for something and whether it was true.