Building Local Bridge because sharing a local folder still feels harder than it should
I’m building Local Bridge, a small developer utility for a very specific workflow:
You have a local folder, build output, docs folder, report, or client artifact, and someone else needs to inspect it in a browser.
In my own work, this moment kept becoming more complicated than it needed to be. I would either upload the folder somewhere, deploy something that was not really meant to be deployed, set up a temporary server, or explain files manually.
Local Bridge is my attempt to make that handoff simpler: choose a folder, create a temporary browser link, share it, and stop the session when the review is done.
I’m keeping the first version intentionally narrow. It is not trying to replace cloud storage, deployment platforms, or full collaboration tools. It is for the short handoff between “this exists locally” and “someone needs to see it now.”
Right now I’m testing it with developers, freelancers, small agencies, and people who send builds, docs, generated reports, or artifacts to clients or teammates.
The hard part is not building more features. The hard part is finding the exact people who already feel this pain often enough that they would pay for a focused tool.
I’m early, learning fast, and trying to stay honest about the signal.
This is one of those workflows that always ends up being more fragile than it should be in practice.
The gap between “local exists” and “someone else can view it instantly” usually gets solved with either overkill infra or manual sharing steps — rarely something purpose-built for just that handoff moment.
Curious how you’re thinking about handling expiration + access control in the first version.
Thanks Aryan, and sorry I missed this earlier. You described exactly the gap I am building for.
For v1 I am keeping expiration and access control simple and explicit:
- each public share gets a fresh temporary Cloudflare Tunnel URL
- the link stops working when the share is stopped
-
--expire 30m,--expire 2h, etc. can auto-stop the share-
--passwordorLOCALBRIDGE_PASSWORDcan protect access- after login, the browser gets a signed session cookie
-
.lbignoreand ignore patterns help keep the shared folder boundary intentionalI am deliberately not positioning v1 as enterprise file governance. It is for temporary handoff sessions: choose the folder you intend to expose, use password/expiry when needed, send the link, then stop it when done.
Curious from your side: would password + expiry be enough for the workflows you are thinking of, or would you expect one-time links / email allowlists before trusting it?
That's a good question.
I do have a view on it, but I don't think the answer is "passwords vs. one-time links." It depends on the trust model you're designing for, and that only really makes sense in the context of your product.
I'd rather explain it with LocalBridge in mind than reduce it to a few comments.
If you're interested, what's the best email to reach you on?
Thanks Aryan, that makes sense. I agree that the right answer depends on the trust model
you can reach me using email: support@theneritic dot com (links not allowed)
I would value your take on where the current v1 model feels sufficient, where it breaks down, and which access-control choices would actually change trust for this kind of temporary handoff workflow.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
Really interesting approach. I'm a final-year CS student with hands-on experience in Python, AI/ML, Flask, and LLM integration. I've built an AI-powered phishing detection system and enjoy working on data extraction and intelligent analysis systems. Happy to connect and contribute if you're looking for an extra pair of hands—I’d even be happy to help out on a volunteer basis to learn and contribute.
Thanks Aisha and sorry I missed this earlier. I appreciate the offer.
Right now I am keeping the codebase closed and focused because the main challenge is still validating the workflow with real users, not expanding the team.
The most useful help would be blunt product feedback: if you have a real case where you need to share a local build, docs folder, artifact, or project folder with someone through a browser link, I would value hearing what you currently use and what would stop you from trusting a tool like this.
Happy to connect on that basis.