ClauseQ

ClauseQ was born from a very real and surprisingly common problem: people and businesses routinely lose money because they forget about contract renewal deadlines. Whether it's a forgotten software subscription, an automatically renewing insurance policy, a vendor agreement with a 90-day cancellation clause, or a business SaaS contract buried in email, the result is the same - unwanted renewals, wasted spend, and frustration. Most people simply rely on calendar reminders or email search, which breaks down quickly when managing multiple subscriptions or contracts across different providers.

For businesses, the problem is even larger. Small and medium-sized organisations often have dozens or hundreds of recurring contracts spread across procurement, finance, software, and operations, but no lightweight, affordable way to track them. Enterprise contract management platforms exist, but they are expensive, bloated, and overkill for SMEs. On the consumer side, subscription trackers focus mostly on bank transaction monitoring rather than understanding the actual contract terms that matter.

ClauseQ aims to solve this by becoming a simple "never miss your cancel-by date" platform. Users can manually add contracts or upload documents for AI-assisted extraction, and ClauseQ identifies key contractual information such as renewal dates, notice periods, auto-renew clauses, and cancellation windows. The platform then proactively reminds users before deadlines so they can make informed decisions instead of reacting after money has already been committed.

This project also served a personal learning objective: I deliberately chose Python and Django because I wanted hands-on experience with a stack I expect to encounter in the UK market, where Python backend roles remain highly common alongside TypeScript frontend engineering.

ClauseQ was designed as a modern full-stack SaaS platform with clear separation between frontend experience, backend domain logic, background processing, billing, and AI integrations.

The frontend was built in Next.js with TypeScript, chosen for its strong developer ergonomics, server-side rendering support, SEO friendliness, and excellent React ecosystem compatibility. Since ClauseQ has both authenticated application flows and marketing/discovery pages, Next.js provided a strong balance between product application architecture and content delivery.

The backend was built in Python/Django, intentionally selected as a learning exercise while still leveraging a mature framework with batteries-included conventions. Django's ORM, admin tooling, authentication ecosystem, and strong developer productivity made it ideal for moving quickly while learning Python in a practical context.

PostgreSQL was chosen as the primary relational database because the application's data model - users, contracts, workspaces, reminders, billing state, AI extraction jobs - is strongly relational and transactional.

AI integrations used both Anthropic and OpenAI depending on the use case. The core AI workflow focused on extracting structured contract metadata from uploaded agreements, transforming unstructured legal text into actionable dates and clauses.

For monetisation, Stripe handled subscriptions, checkout, billing lifecycle events, and customer self-service management.

Architecturally, the system separated synchronous user-facing requests from heavier asynchronous processing. Contract uploads, AI parsing, and reminder dispatch workflows were isolated into background processing to keep the user experience responsive. The architecture intentionally prioritised maintainability, clear domain boundaries, and production realism over toy-project shortcuts.

The most interesting part of ClauseQ was turning messy, real-world contract language into structured, reliable product behaviour.

On paper, "extract renewal date and notice period" sounds simple. In practice, contracts are wildly inconsistent. Some explicitly state renewal terms, others imply them, many contain ambiguous wording, and legal phrasing varies dramatically between providers. Designing prompts and workflows that produced consistently useful AI outputs required substantial experimentation. One of the biggest lessons was that AI integration is far less about calling an API and far more about system design, validation, and graceful failure handling.

Another challenging area was balancing AI capability with SaaS reliability. AI models are probabilistic, expensive, and occasionally wrong, so the platform needed fallback paths, validation rules, and user correction workflows instead of blindly trusting extracted data.

Billing architecture was another rewarding challenge. Stripe's happy path is straightforward, but production subscription systems quickly become more complex once you handle upgrades, downgrades, failed payments, trial periods, customer portal flows, and webhook-driven state synchronisation. Building this properly taught me a great deal about event-driven backend design.

From a personal perspective, the biggest challenge was deliberately choosing unfamiliar backend technology. I'm already comfortable in Rails/Node ecosystems, so forcing myself into Python/Django meant navigating different ORM conventions, framework patterns, and deployment assumptions. That discomfort was exactly the point.

What I'm most proud of is that ClauseQ feels like a genuine SaaS product rather than a portfolio demo - solving a real problem with production-minded engineering choices.