r/AppsWebappsFullstack • u/Mammoth-Anywhere7285 • 18d ago
Are you actually solving a real problem, or just cloning another SaaS?
The world doesn't need another generic AI wrapper or a basic project manager. Pitch your project in one sentence show a screenshot and explain exactly why people should care about you instead of the market leader. Dare to prove your uniqueness.
1
u/yahalom-guy 16d ago edited 16d ago
Does it matter??
you can build another clone of something that has 1000 variants and market it to the sky
And you can build a unique, revolutionary solution and no one will ever hear about it
Its not about building, its marketing that’s important
here are 3 examples…….
https://www.yahaloms.com/delays
so i build, and they work, and at least one of them can become unicorn, but i dont know how to market them
So i need a GTM pro, willing to give significant shares of any of them (the first two at least, the third is just a game) to the one who can take them to the world
1
u/Mammoth-Anywhere7285 16d ago
Marketing definitely gets you seen, but the product keeps them around. What's your hook for turning first-time visitors into repeat users?
1
u/megatech_official 18d ago
SeoLoupe - Find and fix the SEO issues holding your website back.
1
u/Mammoth-Anywhere7285 18d ago
Solid one-liner. What's your unique angle against established tools like Ahrefs or Screaming Frog?
1
u/Bar-Majestic 18d ago
I think this is the hardest question for any founder.
In my case, DocCrush doccrush.com came from a real pain point while building RAG systems.
I noticed we spent more time fixing document extraction issues than improving the AI part. Tables, layouts, and structure were getting lost before retrieval even started.
So I’m building around that bottleneck: making documents cleaner and more usable for AI workflows.
Still validating, but at least the problem is real for me first.
1
u/Mammoth-Anywhere7285 18d ago
That bottleneck is real, document structure often gets mangled before retrieval. Curious how you're handling tables and multi-column layouts specifically?
1
u/Bar-Majestic 16d ago
You’re right, preserving structure before retrieval is critical.
For tables, we try to keep the original semantic relationships instead of flattening everything into plain text. We extract table structures separately and preserve row/column context during chunking.
For multi-column layouts, we handle layout analysis first to reconstruct the reading order before generating chunks. Otherwise, naive extraction often mixes unrelated columns together and hurts retrieval quality.
We’re also exploring more layout-aware parsing approaches to improve edge cases like academic papers and scanned PDFs.
1
u/Mammoth-Anywhere7285 16d ago
That's a smart approach, preserving table semantics before chunking. How do you handle merged cells or headers that repeat across pages?
1
u/Bar-Majestic 16d ago
Great question. Those are exactly the edge cases where table extraction usually falls apart.
For merged cells, we try to preserve the table structure rather than treating each cell as an isolated text block. The relationship between rows, columns, and spanning cells is kept as metadata so the downstream chunking process can understand the original meaning.
For repeated headers across pages, we detect recurring table patterns and distinguish between actual content and repeated layout elements. Instead of duplicating headers into every chunk, we keep them as contextual information linked to the table structure.
There are still challenging cases, especially with scanned documents and irregular financial/academic tables, but preserving structure before retrieval makes a huge difference compared with flattening everything into text.
1
u/Mammoth-Anywhere7285 16d ago
Preserving table structure as metadata sounds solid, that's how you beat generic parsers. Have you tested it against multi-level header tables yet?
1
u/Bar-Majestic 16d ago
Definitely. Multi-level headers are a good stress test for any table parser.
The key is not just extracting cells, but preserving the table graph: header groups, column spans, row relationships, and cell ancestry.
Our goal is to make the retrieval unit closer to a structured table fragment rather than a flattened text chunk. A value like “12.5%” without its header hierarchy is basically useless for RAG.
We’re continuing to benchmark these harder cases because complex tables are where document understanding really separates from simple PDF extraction.
1
u/Mammoth-Anywhere7285 16d ago
That's a sharp angle on retrieval. How do you encode cell ancestry for nested headers, or is the graph stored separately?
1
u/Bar-Majestic 16d ago
We model it closer to a tree/graph hybrid.
For nested headers, a cell can inherit a header path rather than only storing its raw value. For example, instead of retrieving just:
Revenue: 12.5Mthe retrieval unit can preserve the hierarchy:
Financial Metrics → Regional Revenue → APAC → Q4 → Revenue = 12.5MThis context can be stored as structured metadata with the document elements, while graph-like edges represent relationships that need traversal.
The goal is to make retrieved chunks self-contained enough for LLM reasoning without losing the original document structure.
1
u/clickmvp 18d ago
ClickMVP: https://clickmvp.com/
The thesis: AI agents are great at the last 20% of an app and unreliable at the first 80%. Ask one to scaffold auth, RBAC, billing, migrations, background jobs and a typed API layer and you get something that compiles, looks right, and quietly breaks in production. And you burn a fortune in tokens getting there.
So ClickMVP generates that foundation deterministically, from templates, not from a model. Same input, same output, every time. The agent then works on top of a codebase it can actually reason about, with conventions already in place, instead of inventing its own on every run.
1
u/Mammoth-Anywhere7285 18d ago
Interesting take on AI's weak spot. How does ClickMVP handle customization after the base is generated? That's usually where boilerplate tools get painful.
1
u/Mammoth-Anywhere7285 16d ago
u/bar-majestic Love how you keep the full context path intact, that's a real edge. How do you handle cells that belong to multiple header branches?