hukukcy.com

Not a legal chatbot — a legal workflow product.

hukukcy.com is built around a practical job: help a person move from an ordinary-language legal problem to a structured, grounded and usable next step. The product serves citizens, legal professionals and public-institution workflows rather than treating every user as the same chat session.

The public experience also makes the law itself accessible. Users can browse legal material and verify generated documents without entering the authenticated application.

Public legal access and authenticated workspaces are separated.

The production product uses two surfaces with different responsibilities. hukukcy.com hosts the public landing experience, law library, help and document verification. app.hukukcy.com hosts authenticated workflows such as login, document creation, drafts, profiles, lawyer tools and administration.

• Citizens: describe a legal problem, answer targeted questions and prepare a formal petition or complaint.
• Lawyers: work with their own cases, legal research, saved material, reusable text blocks, editing and document versions.
• Officials: use institution-specific workflows for formal documents rather than a citizen-style petition flow.
• Public users: browse laws and verify a document code without authentication.

The architecture follows the legal workflow.

The product is a Next.js application backed by a FastAPI service and a stateful data layer. The web, API, retrieval, orchestration and infrastructure responsibilities are kept separate so legal search, document generation and user-facing product flows can evolve independently.

Authentication, document state, legal corpus metadata, citations, research traces and versioned application data live server-side instead of being hidden in browser-local state.

The legal corpus is deterministic; the model does not write the law.

Legal source material is ingested from law PDFs into structured records. The ingestion path is intentionally deterministic: a hallucination inside the corpus would be more dangerous than a bad generated sentence because it would be mistaken for a source of truth.

Search is hybrid. PostgreSQL lexical signals and title-aware ranking are combined with dense retrieval through Qdrant. The retriever nominates candidate articles, but the text returned to the application is read from the canonical PostgreSQL record. Repealed or superseded material can be excluded before it ever becomes a citation candidate.

Research and drafting are separate steps with explicit gates.

The document pipeline uses LangGraph to make legal research inspectable instead of hiding everything in one prompt. A planner breaks the requested document into legal elements; research branches can run in parallel; retrieval finds candidates; a selector checks whether an article actually applies to the facts; gaps remain explicit when the system cannot ground an element.

The drafter cannot freely invent citations. Its citation keys are constrained to articles found by research, and a second guard checks them again. Dates, amounts, names and other factual details are also checked against the user-provided source data so the generated document cannot silently manufacture case facts.

A generated document should remain verifiable after it leaves the app.

Formal documents can be exported as real PDF and DOCX files. The platform also implements its own integrity seal — explicitly not a national digital signature — so a document can be checked later without exposing its contents publicly.

• The document payload is canonicalized and hashed before signing.
• An Ed25519 signing key is held in AWS KMS; the private key does not leave KMS.
• A public verification code and QR route to the /barla verification flow.
• If a signed document is edited later, the previous seal is revoked instead of being silently reused.
• Public verification returns the seal verdict without exposing the document body or personal data.

The prototype became an actual production system.

The production deployment runs on AWS in Frankfurt on a single EC2 host using Docker Compose. Caddy terminates HTTPS and routes the public and application domains to the same Next.js and FastAPI containers. PostgreSQL, Redis and Qdrant remain private to the host network.

The server exposes only web traffic; operational access is handled through AWS Systems Manager rather than SSH. Production configuration is also fail-closed: unsafe authentication, missing secrets or invalid signing configuration can prevent the API from starting.

The roadmap is defined as much by what I removed as by what I built.

Building hukukcy.com forced product-management decisions around scope, trust and sequencing. I removed features such as fee calculators, deadline calculators and external institution integrations when they distracted from the core workflow. I also separated the public legal-information surface from the authenticated application instead of turning every visitor into an account funnel.

• Trust before breadth: grounding, citations and verification matter more than adding more AI features.
• Different jobs, different workspaces: citizens, lawyers and officials should not share one generic UX.
• Public law is part of the product: users should be able to inspect the underlying legal source, not only trust an AI answer.
• Production constraints shape product: privacy, auditability, deployment and failure modes are product requirements, not backend cleanup.

This project is where my engineering and product-management interests meet most directly: defining the user workflow, choosing what not to build, designing the retrieval and generation system, and carrying the same product into production.