I build SaaS as a hobby, and when I launched Jurfi my revenue from these projects was still zero. That is slightly painful to write, but it is also part of the story: I keep building because I genuinely enjoy making products. Jurfi.com is the latest one.
Jurfi is a browser-based studio for creating structured legal-document drafts. I built it around a specific frustration. A blank page is slow, but a vague AI answer can create the opposite problem: plenty of text without a clear document structure or an obvious way to review it. I wanted a middle ground: clearer inputs, a defined shape for the document, and a working draft that can be inspected instead of simply trusted.
From a blank page to a structured draft
Many practical documents begin with the same awkward questions: what information belongs here, in what order, and what am I forgetting? Jurfi is meant to reduce that friction for website and SaaS policies, service agreements, rental documents, letters, claims, receipts, and other practical documents people actually need.
The basic idea is simple: start from a form or template rather than from an empty page. Provide the relevant inputs, produce a structured working draft, and then review or refine the result.
- Create legal-document drafts through simple forms and templates.
- Generate structured drafts directly in the browser.
- Keep drafts locally instead of treating every iteration as disposable text.
- Reduce document chaos and repetitive manual assembly.
I deliberately call the result a draft. A document can look polished and still be wrong for a particular jurisdiction, contract, business, or dispute. Good formatting is not proof of legal correctness.
The boundary matters more than the feature list
The most important product decision was not another template. It was deciding what Jurfi should not pretend to be. It is not a lawyer, and I do not present it as a system that can solve every complicated legal situation.
The value I am aiming for is narrower: speed, structure, and clarity. Get from an empty page to a coherent working draft faster, make the inputs explicit, reduce repetitive assembly, and then read the result critically. When a document carries meaningful legal or financial risk, professional review is still the sensible next step.
That boundary matters because generated text can sound confident while still being incomplete or wrong. For a legal-document tool, hiding that uncertainty would be a bad product decision. I would rather make the limits obvious than make the product sound magical.
What “browser-based” means here
The workflow is centered on the browser, and drafts can be kept locally. That mattered to me because document work becomes messy quickly when each revision is scattered across tabs, chats, and copied text.
I also do not want to turn that feature into a broader privacy claim than the source supports. “Drafts can be kept locally” is the concrete capability. It is not the same as claiming that every operation in every workflow necessarily happens only on the device. The practical point is simpler: the draft can remain a document you continue working on, not just another one-off answer.
Launching a product is not the same as being discovered
After launch, the most uncertain part is discovery. I put real effort into the wording, the review process, and the quality of the documents. Then comes the part I cannot control directly: whether people find the product.
The emotional version is “now Google has to do its part.” The technically precise version is less comforting. Google’s own documentation says that even a page that follows its requirements is not guaranteed to be crawled, indexed, or served in Search. Crawling, indexing, ranking, and traffic are different stages; shipping a careful product does not automatically produce any of them.
That distinction is useful for side projects. I can control what I build, what I publish, and how carefully I explain it. I cannot control how quickly search discovers it or whether that discovery turns into users.
What I am taking from this project
Even if growth is slow, I am glad I built Jurfi. The lesson for me is not that legal drafting is easy or that AI removes the difficult parts. If anything, the more consequential the document, the more important it becomes to make the workflow explicit and the limits visible.
- Use structured inputs when the output has a predictable shape.
- Treat generated text as a working draft, not proof of correctness.
- Make the boundary between software assistance and professional judgment obvious.
- Keep review inside the workflow instead of treating generation as the finish line.
- Separate product quality from search performance; one does not guarantee the other.
That is the standard I wanted for jurfi.com: less document chaos, less repetitive work, and a clearer path from “I need this document” to “I have a draft I can actually inspect.”