Skip to content
Kilavuz Kilavuz
Blog

Blog

Kilavuz Is Live Today

Kilavuz
Kilavuz

We released the first version of Kilavuz today. This post summarizes the parts the product was born with and what is coming over the next few weeks.

What does it do?

Kilavuz is a product for designing hierarchical question lists and exporting them as Markdown. A typical flow looks like this:

  • Everyone on the team edits questions under the same project.
  • A root question can host any depth of children.
  • Questions are reordered by dragging and dropping.
  • When the tree is final, the whole tree downloads as a single Markdown file.

This flow fits interview drafts, retrospectives, discovery notes, and QA checklists particularly well — which is why we use it in our own work.

What is in today’s release?

  • Three plans: Free, Individual, and Team. The plan comparison is on the pricing page.
  • Question-tree editing: Drag-and-drop reordering and soft delete. Deleting a question never orphans the children.
  • Markdown export: The whole tree, with hierarchical numbering, downloads as a single file. The endpoint is documented in the API reference.
  • Admin panel: User management, billing view, and audit records. Available only to admins.
  • Cookie consent and language selection: Turkish is the default; English is available; the choice is stored in the browser.

Where to start?

  1. Open https://kilavuz.app and sign up for an account.
  2. Follow the steps in the Getting started guide to build your first question tree.
  3. If you have a question, reach out via the blog comments or by email.

What is next?

  • Team collaboration: Conflict resolution for multiple people editing the same tree simultaneously.
  • Templates: Starter templates for common trees (interviews, retrospectives, discovery).
  • Export expansion: Beyond Markdown, export to JSON and OPML.

This roadmap will be shaped by feedback from the first teams using the product. We welcome your feedback through the blog comments or via hello@kilavuz.app; response time depends on volume.

Why Kilavuz Exists

Kilavuz
Kilavuz

This post explains the problem Kilavuz was born to solve and the reasoning behind its design decisions. Unlike the feature list on the product page, this post focuses on the “why”.

The starting point

When you want to take structured notes in a team, you usually have two common options:

  • A document editor: You write questions as free text, one after another; hierarchy collapses visually, and reordering is painful.
  • A project management tool: Each question becomes a ticket; then the tree structure is lost, and information scatters.

Between those two extremes there is a gap: keeping hierarchy while writing free text, moving it around, and turning it into other formats. Kilavuz was born to close that gap.

Design principles

When designing the product, we committed to three principles:

  1. Data structure first: Hierarchy is a first-class construct from the database’s perspective, not just a visual nicety. That is why parentId, sortKey, and depth are at the core of the model.
  2. Soft delete: Deleting a question should not cost you the information underneath. The softDeleteQuestion action stamps the target record without orphaning its children.
  3. A single owned export format: Markdown is a format our team and our customers already understand. JSON and OPML are on the roadmap; we did not introduce an extra format burden on day one.

Why is Turkish the default?

Our team speaks Turkish; a significant part of our customers work in Turkish as well. Shipping the product with Turkish as the default meant doing our own work with the least friction. English is not in place to fill a real gap; it is there to keep the product open to international use. The language choice is stored as a UI preference rather than as data, so server-side data stays language-agnostic.

What we deliberately did not do

  • We did not translate the SDK form controls. The internal form components of the Wasp SDK remain in English; that exception is a deliberate scope decision.
  • We did not translate server error messages. API error bodies stay in English; they are aimed at developers.
  • We did not write a custom invoice template. PDF invoices come from Stripe’s template.

This “did not” list keeps our scope honest. If you hit a boundary while using the product and you are not sure whether it is a deliberate decision or a missing feature, please reach out.

What’s next

Over the coming months we will shape the product with real-world usage data. We will continue to share the roadmap and changelog through the blog.