- Role
- Designer & Builder
- Users
- 7 developers at work
- Focus
- Natural-language search, question queue, document import
Overview
At work, I am rarely on one project at a time. On a typical week, two projects I have finished are in development, I am designing a third, and I am overseeing an intern's work on a fourth.
Every finished feature is handed over with a demo recording. Still, the questions come. How should this flow behave? What is the logic behind this rule? How is this stat calculated?
Each question pulls me out of the project in front of me and back into one I closed weeks ago. That constant context switching was costing me focus, and it was costing the developers time while they waited on me.
Our goal was simple: give the developers a place to get the answer I would have given them, without needing me in the room.
Here's how that went.
To begin, how do we define success?
Lushan exists to protect focus, so success had to be measured in interruptions, not features.
- Questions answered without me: the share of developer questions that Lushan resolves on its own.
- Interruptions per week: how often I am pulled back into a past project.
- Time to an answer: how long a developer waits between asking and getting what they need.
- Documentation coverage: how much of each shipped feature has its logic written down.
A place for my thinking
Lushan is where I document the reasoning behind my work. Every flow, feature, and product gets a doc that holds its logic, use cases, edge cases, and the business decisions that shaped it, with links to the exact Figma frames each piece refers to.
When a developer has a question, they ask Lushan the way they would ask me. In plain language, in their own words.
Search without the heavy cost
The obvious way to answer questions in natural language is to put a large language model behind it. That would have worked, but it would have been expensive to run on every question, and it risked the tool inventing answers I never gave.
I wanted something leaner. A developer will rarely use the exact words I used when I wrote a doc, so plain keyword matching was not enough either.
The solution was a search that understands meaning without generating anything. If a developer asks how a buyer's trust score is calculated, Lushan can surface the decision I recorded about when ratings are triggered, even though the two share almost no words. Every answer they see is one I wrote.
When there is no answer yet
Sometimes the answer has not been documented. Rather than let that question disappear into a chat message, Lushan captures it and adds it to a queue for me.
I answer it once, inside Lushan, and the next person who asks gets the answer straight away. Each unanswered question becomes a gap in the docs I can see and close.
The documentation problem
A knowledge base is only as good as what goes into it, and I barely have time between features to document properly.
So I introduced uploads. A Markdown or PDF file can be dropped into Lushan and the content is extracted to populate a doc.
This works especially well for features I built entirely with Claude Code. Lushan stores a prompt I can copy into Claude, which then generates most of the documentation I need from the work it has already done. What used to take an afternoon now takes minutes.
What I am still deliberating on
The generated docs come with two problems.
First, they read like AI. That is not my voice, and the developers asking questions are used to hearing from me.
Second, and more importantly, the AI knows what was built but not always why. The reasoning behind a decision often lived in a conversation with a stakeholder or a trade-off I weighed in my head. Those are exactly the answers developers come looking for.
I am still working out how to close this gap without losing the speed that makes documenting possible at all.
The conclusion of the matter
I have shared Lushan with the seven developers at work, and the feedback has been positive. Questions that once came to me now go to Lushan first.
The measures above will be tracked next. Only then can we know for sure that we have solved the problem.