Specify.app: SDLC documentation that stays aligned with code
Documentation should change when the code does. Specify.app connects code and business context to generate SDLC documentation and trace change impact.
Initial segment
Timing condition
Operating principle
Project Overview
Where the problem started
While working directly with medical-device software certification documentation, I experienced how quickly code and evidence drift apart. When features and architecture changed, requirements, design, test, and operational documents still had to be found and updated separately, with no reliable way to know what had been missed.
The problem is not limited to certification. The same code-documentation gap appears in onboarding, customer and audit responses, and delivery to public agencies or large enterprises.
Product hypothesis
Specify.app is being designed to connect code with business context, generate SDLC documentation, trace which requirements, designs, and tests are affected by a code change, and preserve the resulting review and approval history.
The current validation focuses on three hypotheses:
- Software teams without dedicated documentation staff face substantial rework when they reconcile evidence immediately before certification or delivery.
- Ongoing change-impact detection, revision proposals, and approval history create more operational value than one-off document generation.
- Trustworthy evidence and auditable state transitions matter more to a buying decision than generic AI-generated documentation.
Initial validation segment
The first segment under validation is Korean software teams with all of the following conditions:
- 10–100 people
- A GS Grade 1 certification or public/enterprise delivery deadline within 3–6 months
- No dedicated documentation team
- Fragmented ownership and approval history between code changes and document updates
This is a working ICP being tested through customer interviews and paid commitments, not a claim of proven market traction.
Target workflow
- Connect source code, requirements, and existing documentation.
- Detect which design, test, and operational documents are affected by a change.
- Propose revisions with traceable evidence.
- Preserve human review and approval history.
- Surface missing or stale evidence before certification or delivery.
The priority is not autonomous text generation. It is evidence that a reviewer can inspect, explicit approval boundaries, and an auditable change history.
Business-model hypothesis
The entry point is a certification or delivery documentation project that reveals the customer's process and evidence. The longer-term model is a subscription for change-impact detection and continuous documentation maintenance, with a potential channel for consulting partners who deliver these projects.
Current status and evidence standard
Specify.app is in market validation. This page does not present unverified customer counts, conversion rates, or time savings as results. The status will change only when supported by evidence such as:
- Repeated observations from real customer interviews
- Concrete reactions to price
- A paid pilot or purchasing commitment
- Before-and-after operating metrics measured on the same basis