ContractIQ × SOW Maker
AI that reads requirements and writes contracts and SOWs - so agencies stop bleeding hours on documents.
- Timeline
- 2026
- Role
- Founder / architect
- Team
- Solo
- Status
- building
Technology Stack
✦Overview
ContractIQ x SOW Maker is AI that reads a requirements exchange and writes the documents that usually eat an agency's week - SOWs, BRDs, payment schedules, meeting checklists. One engine, many document types, data-driven rather than hardcoded per format.
It is deliberately architecture-first: the entire system was specified in a master SRS before the first line of code. Every freelance and agency deal drowns in the same documents, written by hand and inconsistently, every single time - ContractIQ turns that repeated manual work into a generated, versioned artifact.
✦Key Features
Requirements → client-ready SOW - An AI-assisted drafting flow turns a requirements conversation into a statement of work a client can sign - already used on real engagements.
One engine, many documents - BRDs, payment schedules and meeting checklists come out of the same data-driven template system, not a separate hardcoded generator per format.
Spec-first discipline - Database schema, API contracts, security framework and delivery roadmap were written up front - engineering executes against a blueprint, not vibes.
Versioned document control - Distribution and access levels on every document - consulting-grade discipline applied to my own product.
✦Technical Implementation
01Master SRS v2.0
The system is defined by CIQ-SRS-2026-001 - 14 functional modules, each with personas, product pillars and acceptance criteria fixed before implementation. The build is executing that spec, not discovering it.
| Layer | Spec artifact | Purpose |
|---|---|---|
| Requirements | SRS v2.0 · 14 modules | Personas, pillars, acceptance criteria |
| Data | Schema + ER model | Documents, templates, versions, clients |
| API | Contract-first endpoints | Stable surface the UI builds against |
| AI | LLM drafting pipeline | Requirements → SOW / BRD generation |
| Security | Access + distribution levels | Versioned, controlled document release |
✦Design Decisions
Specify before building
For a document engine, ambiguity compounds - a vague SOW schema means every generator downstream is guessing. Writing the SRS first turned the hard thinking into a blueprint, so implementation is mechanical instead of exploratory.
One data-driven engine
Rather than a bespoke code path per document type, ContractIQ treats every artifact as data over a shared engine. Adding a new document format becomes configuration, not a new subsystem.
Want the full walkthrough - architecture, decisions, war stories?
ask me about it
