Specify — Keeping Documentation in Step with Code

Half a day of document work after one feature change

At a medical-device software startup, I worked on both development and certification preparation. For more than six months, I helped structure, write, and maintain documentation against development standards.

The hardest part was not starting a document. It was keeping several documents aligned with code that kept changing.

After a feature changed, I had to find the relevant documents, identify the affected passages, and check whether the same explanation appeared elsewhere. When someone else had written a document, finding it could be a task in itself.

For one feature change, this work took about four hours. Finishing the code meant starting a separate round of documentation work.

The same search happened after every change

A carefully written document still needed checking after the next update. Maintenance depended on the person who knew where it lived and why it had been written. When that person changed, the search started again.

Developers in other small teams described similar pressure in conversations: little time to write documentation, updates only when something was urgently needed, or development continuing without enough documentation.

The problem I wanted to address became concrete: find the related documents, locate the passages that need changing, and bring them back into line with the code.

Making code changes the starting point

I built Specify from that experience. It connects GitHub changes with a team's developer documents to reduce the maintenance work that follows a code update.

The workflow has four steps.

1. Connect the sources. Bring together a GitHub repository, existing documents, and product information.
2. Read the change. Analyze what changed when code is pushed.
3. Find the affected documents. Locate relevant passages and prepare updates in their existing context.
4. Review and apply. Inspect the evidence and proposed changes. Automatic application follows the project's settings.

Existing material is retrieved through RAG to provide context for drafting and updating documents. API references, internal wikis, onboarding guides, and release notes can all be affected by the same code change.

One change makes the problem easier to see

Suppose a webhook policy changes from three retries to five. The code may be complete, but if the integration guide still says “three retries,” the next developer will work from the old policy.

Someone needs to find that explanation, compare it with the updated code, and correct it. I am building Specify to continue that work from the code change itself.

The screenshot below shows a manually written retry-policy demo document in the live editor. It illustrates editing, document status, and sharing controls; it is not a screenshot of an automatically applied update.

Documentation changes alongside code, both during certification preparation and throughout product maintenance. I want the searching and comparison I experienced to become work a team does not have to restart after every update.

Try Specify · Product documentation