Building LunaDocu: why document status should not be treated as a task

Anton Briukhanov — Thu, 04 Jun 2026 10:42:34 +0000

I’m building LunaDocu, a small Spring Boot / Thymeleaf B2B SaaS for document approval status visibility.

The original idea looked simple:

Track document approvals in one place.

But after working on the product and talking to other founders, I started to realize that this framing is too generic.

“Document approval tracking” sounds like a feature.
It also sounds like something a spreadsheet, SharePoint list, Airtable base, or project management tool could already solve.

The more interesting problem is different:

People keep asking “where is this document stuck?” because nobody fully trusts the current status.

That changes the product logic.

Storage is not the same as status

Most teams already know where their documents live.

They may use:

Google Docs
SharePoint
Dropbox
email attachments
internal storage
contract management tools

But the approval status often lives somewhere else:

a spreadsheet
Slack or Teams messages
email threads
meeting notes
one coordinator’s memory

So the document exists.
The file is not lost.

But the current state is unclear.

That is where repeated follow-ups start.

A document status is not a task status

A task status usually implies action:

To do
In progress
Blocked
Done

That works well when the main question is:

Who needs to do what next?

But document approvals often have a different question:

What is the current state of this document, and why is nothing happening right now?

For LunaDocu, I’m trying to separate these concepts.

The document is not always a task.
Sometimes it is a process object.

It may be active.
It may be waiting.
It may be completed.
It may be blocked by an external dependency.

But “waiting” should not automatically mean failure.

Waiting should be a valid state

In many systems, waiting starts to look bad.

If nothing changed for a while, the item feels stale.
If someone is assigned, it can look like blame.
If there is a due date, it can become pressure.
If there is an overdue label, it becomes escalation.

But in real document approval processes, waiting is often normal.

Waiting for legal review.
Waiting for a client response.
Waiting for a vendor document.
Waiting for internal confirmation.
Waiting for compliance.

The important part is not always to push someone harder.

Sometimes the important part is to make the waiting reason visible enough that people do not need to ask again.

The model I’m using

In LunaDocu, I’m trying to keep the core model small:

document
current status
steps
waiting reason
responsible side
last confirmed update
change history
read-only status page

The current status should be understandable without turning the product into a heavy workflow engine.

The goal is not to replace every workflow tool.

The goal is to create a calm status layer for documents where repeated follow-up questions are the problem.

Why read-only matters

One design choice I care about is read-only access.

Not everyone involved in a document approval process should become an active user.

A stakeholder may only need to know:

what is the current state?
who or which side is it waiting on?
why is it waiting?
when was it last confirmed?
what changed before?

If they can see that in a read-only page, the team may avoid another status meeting, chat message, or email thread.

That is the kind of value I’m trying to test.

What I’m validating now

I’m not trying to validate whether people like the phrase “document approval tracker.”

That is too abstract.

The better validation question is:

Are teams already losing time, trust, or client confidence because nobody knows where a document is stuck?

If the answer is yes, the next question is whether they already have a workaround:

a shared spreadsheet
a status template
a manual tracker
a recurring update ritual
a coordinator maintaining status manually

That is probably a stronger signal than someone simply saying “sounds useful.”

Current state

LunaDocu is still early.

It is built with Java, Spring Boot, Thymeleaf, PostgreSQL, Flyway, and a deliberately simple server-rendered UI.

I’m trying to keep the product narrow:

not a task manager
not a BPM system
not a performance tracking tool
not an SLA engine

Just a clearer answer to:

Where is this document stuck?

I’m sharing this because I think many small SaaS products fail not because the implementation is hard, but because the product category is framed too broadly or too generically.

For LunaDocu, the technical challenge is manageable.

The harder part is finding the exact operational pain that is sharp enough to build around.

I’m exploring this problem here: https://lunadocu.com

DEV Community: Anton Briukhanov