I'm a CS Student Who Built a Free AI Doc Tool — No Backend, No Login, No Budget. Here's What I Learned.

I'll keep the backstory short: I'm a computer science engineering student. I built docreplacer.online — a tool that turns a plain-English prompt into a formatted Word (.docx) file, instantly, entirely inside your browser. No server. No login. No account. Free.
It started as something I built for myself. It turned into the most interesting architectural decision I've made so far — and an ongoing experiment in whether you can grow something from zero without spending a single rupee.

The Problem I Was Actually Solving
I kept generating the same types of documents — contracts, briefs, structured reports — where the content changed but the format didn't. The workflow was always: open Word, fill in the blanks, save-as, send. Fine for one document. Painful for twenty.
AI solves the content part. But AI gives you text. Getting that text into a properly formatted .docx — correct heading levels, paragraph spacing, section structure — still requires you to manually touch Word. That gap is small but it compounds every single day.
Every existing tool that closes this gap has the same requirement: create an account, connect to their server, let your content pass through infrastructure you don't control. For a contract or an HR document or a legal brief, that's a real trade-off most people just accept without thinking about it.
I wanted to see if the trade-off was actually necessary.

Why No Backend At All
The docx JavaScript library can construct valid Word documents entirely in browser memory. No server. No conversion endpoint. The file is assembled client-side and downloaded directly — the same way a CSV export works, just more structurally complex.
So the entire architecture became:

User types a prompt
AI API returns structured content
docx library assembles the file in the browser
File downloads to the user's machine

Nothing touches a server. No file is stored anywhere. No authentication layer needed. No hosting costs beyond a static site.
The moment I realized this was possible, the backend decision made itself.

What "Client-Side Only" Actually Costs You
I want to be honest here because a lot of "I built X without Y" posts skip the real trade-offs.
What works well: Document generation is stateless. You have a prompt, you want a file, done. There's no meaningful state to persist server-side. localStorage handles recent templates. The browser handles the download.
What genuinely doesn't work: Batch generation at scale. If you need 500 documents from a pipeline, you need a backend — this isn't the right tool. Team template sharing also isn't supported without a sync layer.
These are real constraints, not oversights. The goal was to build the simplest thing that solved the problem without introducing infrastructure the problem doesn't require.

The Privacy Angle I Didn't Expect to Matter
When I started building, privacy wasn't the main pitch. It was just a side effect of the architecture.
But the more I talked about the tool, the more it resonated — especially for people handling sensitive documents. Legal teams. HR. Finance. Medical.
Here's the thing: any server-based tool can promise not to store your data. But they can't promise what they never receive. Client-side architecture makes privacy a structural property, not a policy. Your document exists in your browser memory and then on your local machine. That's it.
I didn't plan that as a differentiator. It became one.

Where Things Stand Right Now
The tool is live. It's free. It's an MVP.
Current state:

Single document generation from a prompt ✅
Basic formatting and section structure ✅
No login, no backend, no tracking ✅
Template saving (localStorage) ✅

What's missing:

Better handling of tables and complex layouts
More granular formatting control
Some way to share templates across sessions

I have no funding. No team. No marketing budget. I'm figuring out distribution entirely through writing and communities like this one.

The Honest Part
I don't have impressive traction numbers to share yet. This is early. I'm posting here because IndieHackers is where I've seen the most honest conversation about what early-stage actually looks like — and because I'd rather learn from people who've been here than pretend I have it figured out.
If you've built client-side only tools: how did you handle the "but where's your server?" question from users? And for those who've grown something with zero budget — what actually moved the needle in the first 30 days?
Would genuinely appreciate brutal feedback on the tool, the positioning, or anything else.
→ docreplacer.online