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.

ClauseQ, along with its companion projects, also serves a broader purpose: these are public repos where I can show the kind of engineering I do day to day, including work that would otherwise stay private in client or employer codebases. They're a space to try different practices and architectural approaches, experiment with AI integrations and third-party APIs, and learn by building - all while keeping a real, working application that can be run and inspected locally.

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 Ruby on Rails, chosen for its mature conventions, fast iteration speed, and battle-tested ecosystem for authentication, background jobs, and API development. Rails' "convention over configuration" philosophy and ActiveRecord's expressive ORM made it possible to move quickly while still keeping the codebase readable and well-structured as the domain grew.

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 integration used OpenAI for the core extraction workflow, transforming unstructured legal text from uploaded agreements into structured contract metadata - 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 Sidekiq-backed background jobs, using Redis as the queue backend, 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, one advantage of building solo was choosing the right AI provider for each job rather than defaulting to one across the board - OpenAI for the contract extraction pipeline itself, and Claude in my own PR review workflow, which meant I got hands-on comparison of both ecosystems in practice rather than in theory.

What I'm most proud of is that ClauseQ was built with production-minded engineering choices throughout - the kind of decisions I'd make on a team, not shortcuts I'd only take on a demo, while staying open enough as a public repo to show the reasoning behind them.