I’ve been working on a full-stack scaffold:
\- React frontend
\- tRPC backend
\- DB + storage wired
\- Docker deploy ready
\- test suite included
Goal is to go from idea → deployable app immediately.
Curious:
Would this actually be useful to you, or do you prefer building from scratch?
If anyone wants to try it, I can share access.
I’m a frontend developer and lately I’ve been feeling pretty uncomfortable with what’s happening on my team.
I originally built and structured the frontend repo I created reusable components, set up patterns, and tried to keep everything clean and scalable. Recently, one of the backend devs started contributing directly to the frontend using my repo.
The issue isn’t that they’re contributing ,I actually welcome that. But the way it’s being done is worrying. There’s very little thought around structure or scalability. I’m seeing files going 800+ lines, logic mixed everywhere, and patterns that don’t really fit the architecture I had in place.
What bothers me more is that I know this could’ve been done much simpler and cleaner with a bit of planning. Even when I use AI, I don’t just generate code blindly , I first think through the architecture (state management, component structure, data flow), and only then use AI for repetitive parts. Then I review everything carefully.
It feels like AI is being used here just to “make things work” rather than “make things right,” and the repo is slowly becoming harder to maintain.
I don’t want to gatekeep frontend, but at the same time, I feel like the code quality and long-term scalability are getting compromised.
Is this something others are experiencing too? How do you handle situations where non-frontend devs start contributing in ways that hurt the codebase?
If you've ever needed to embed Office documents in a web app, you know how hard it is. Your usual options are limited to:
Use a JS library to convert to HTML — but lose rendering fidelity
Convert documents server-side — adds infrastructure complexity and a mandatory upload pipeline
Pay for an enterprise viewer — expensive, often heavyweight, and usually comes with lock-in
I've been building docMentis as a different kind of solution: a universal document viewer for the web.
What makes it different:
- a rendering engine built from scratch for high-fidelity viewing across PDF, DOCX, PPTX, SVG, and images
- a Rust/WebAssembly engine that runs in the browser, with client-side viewing by default
- an MIT-licensed, open-source viewer layer, with a closed-source rendering engine that is free to use in commercial products when shipped with the viewer
The result is one viewer and one integration path across formats, instead of stitching together separate tools with different rendering behavior.
Links:
- Website:
- GitHub:
- npm:
If you've dealt with this problem before, I'd be interested in how you approached it. Happy to answer technical questions about the rendering pipeline, the document model, or the tradeoffs between client-side viewing and server-side conversion.
