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
Top comments (0)