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
The "privacy as structural property, not policy" line is sharp — keep that as positioning, it's already half a landing page. On the zero-budget question: I'm solo-shipping a small iOS memo app (a Captio replacement) and the only thing that moved the needle in my first 30 days wasn't writing posts — it was answering one specific recurring question in three small subreddits (in my case, "what replaced Captio?"). It pulled around 40 installs, not huge, but it compounded because some of those people kept replying weeks later. Bigger writeups felt good but converted near zero at my stage. For the "where's your server?" objection — I'd just flip it into the headline. "Nothing leaves your browser" disarms it before users ask. Are you already tracking which subreddits or threads your earliest visitors come from?
Love the architectural honesty here — calling out that batch generation and team template sharing genuinely don't work is the part most "no backend" posts gloss over. Client-side-as-privacy-by-architecture is the right framing too; you can't leak what you never receive.
On the "but where's your server?" question — what worked for me was reframing it on the landing page from "no backend" (sounds like missing infrastructure) to "your file never leaves your browser" (sounds like a guarantee). Same technical fact, completely different reaction from non-technical users handling sensitive docs.
For the first-30-days question: the thing that moved the needle for me wasn't a single channel, it was being specific about the use case in the title. "Doc generator" competes with everyone; "contract / HR / legal brief generator that runs client-side" filters in exactly the people who care about the privacy property. Have you tried niching the landing page copy to one of those verticals first?
As the founder of an AI tools directory, I love seeing projects like this — especially when they come from a CS student who's thinking architecturally rather than just shipping another wrapper. The "privacy as a structural property, not a policy" line is exactly the kind of thing most early-stage founders overlook, and you've made it the foundation.
A few things stood out to me: the client-side docx assembly is clever, and the fact that you're being honest about what doesn't work (batch generation, team template sharing) earns a lot of trust. Early-stage transparency is rare.
I'm curious about two things. First, how are you handling the AI call? If the API key lives in the browser, how do you protect it — or are you using something like a proxy? Second, have you thought about letting users save their templates as shareable JSON configs that others can import manually? It wouldn't require a backend, and it could kickstart a small template ecosystem without breaking your zero-infrastructure philosophy.
Looking forward to playing with it and potentially featuring it. Brutal honesty: the positioning is strong, but "docreplacer" as a name might not immediately signal "AI document generator" — something to keep in mind as you grow. Congrats on shipping, Manickavasagan.
The client-side architecture is a genuinely underrated moat - you're right that 'we never receive your data' is structurally different from 'we don't store your data.'
Curious about something specific to the student angle: have you seen PhD students or research-track folks using it for structured research outputs - literature summaries, methodology sections, that kind of thing? I've been noticing a pattern where the hard problem for researchers isn't formatting the document, it's knowing what to prompt at each stage of the workflow. The gap between 'I have 30 papers to synthesize' and 'I have a coherent literature review' is a lot of prompt engineering most people reinvent from scratch.
Wondering if that's a segment you're seeing engage, or if your users are more on the professional/commercial doc side.
The constraint-driven architecture is really underrated as a strategy. No backend = no auth, no infra, no GDPR headaches. I took the same approach with Toolivoo (browser-based PDF, image and QR tools) and "we never see your files" turned out to be one of the most resonant things we say to users. The privacy angle sells itself once you frame it right.
The privacy angle is the strongest positioning here. I would lead with “your document never leaves your browser” before “free AI doc tool,” because that makes the no-backend choice feel like a benefit instead of a limitation. For first users, I’d test narrow templates: contracts for freelancers, offer letters for small teams, invoices/briefs for agencies. Specific templates are easier to distribute than a general document generator.
The 'but where's your server?' question is actually your best sales moment in disguise. Most users who ask it are trying to reassure themselves about a concern they haven't fully articulated. The answer that moves them isn't 'we use localStorage' - it's: 'The document is assembled in your browser and goes straight to your hard drive. Our server never touches it because there is no server in that part of the stack.' That framing makes privacy a structural property, not a promise - exactly the distinction you already identified as your real differentiator.
For first 30 days at zero budget: the thing that actually moves the needle is showing up in conversations where the problem already exists - legal team communities, HR forums, freelancer groups, anywhere 'I had to reformat the same document again' is a real experience someone just had. Not posting about the tool. Participating in the pain first, then mentioning it as the thing you built because of that exact problem. Conversion from that kind of comment is much higher than a cold post because the reader skips the 'is this relevant to me?' question entirely.
This is honestly really impressive. Shipping something useful as a CS student with zero backend and still making it work in production is exactly the kind of constraint-based building that teaches you the most.
What stood out most is how you kept it simple instead of overengineering — a lot of people would’ve immediately added auth, database, dashboards, etc. and never shipped.
Curious how you’re thinking about distribution next, because that’s usually the hardest part after the MVP 🙌
Browser-only with no backend is a bold choice. I went the same route for a tool recently and the tradeoff is real: zero server costs but you hit CORS and API key exposure problems fast. How are you handling the API key situation? Embedding it client-side or using a proxy function somewhere?
I'm impressed by your decision to build docreplacer.online without a backend or login, and I'd love to hear more about the technical challenges you overcame to achieve this, particularly in terms of handling large files or complex formatting requests. What inspired you to pursue a client-side only approach, and do you see any potential limitations or security concerns with this architecture? How do you plan to balance the need for additional features with the constraints of a serverless design?
The client-side-only architecture choice is underrated. I shipped a similar zero-backend tool and the biggest surprise was how much users value the privacy angle. People genuinely care about their content not passing through someone else's server, especially for documents like contracts or HR stuff. One thing I noticed: the free/no-login friction cut both ways. Some users trusted it more, others assumed it was lower quality because there was no paywall. Did you see that split?
The 'free, no login' angle is smart for early validation - you learn what people actually do with the tool before you try to monetize it.
One pattern I've noticed with AI tools for documents/research: the generic 'summarize this' or 'help me understand this' prompt gets most users to abandon after one try. The users who stick are the ones who figure out a very specific prompt structure for their actual workflow - 'extract all methodology claims from this paper and flag any that lack citations' vs. just 'summarize.'
The hard part for builders in this space: the tool works fine, but users don't know how to use it well enough to feel the value. The prompts that unlock the tool's real usefulness take real domain expertise to write.
Curious what use cases you saw people actually try vs. what you expected? The ones where people got a useful result tend to reveal where the real product-market fit is.
"They can't promise what they never receive" is the cleanest framing of client-side privacy I've read in a while. I'm a solo dev shipping a tiny iOS memo app — a Captio replacement that emails notes in one tap — and I've landed on essentially the same architectural call: no server, no account, the note never leaves the device until the user explicitly sends it. The funny thing is, the "where's your server?" question from users almost never came up. What did come up was "where do my notes live?" — and "on your phone, full stop" closes the conversation every time. On the zero-budget distribution piece: my first ~30 useful installs came from one specific niche subreddit reply, not from any keyword work. ASO impressions only started compounding around week 5, once a handful of reviews existed. Have you decided whether cross-device template sync is a hard line you'd never cross, or a future trade-off you'd accept under specific conditions?
"On your phone, full stop" — that's exactly the kind of closer I need to borrow. Clean, no follow-up needed.
The parallel is almost identical. I've had people ask "where does my document go?" and the honest answer is "it never goes anywhere — it's assembled in your tab and downloaded to your machine" — but I haven't found a punchy one-liner for it yet. You just gave me one to model from.
On the niche subreddit reply — which part of that worked, do you think? Was it the reply itself that drove installs, or the fact that the subreddit already had people actively looking for that exact thing? I'm trying to figure out if it's the channel or the framing that matters more at this stage.
On cross-device sync — honestly, it's not a hard line, but it's a deliberate pause. The moment I add a sync layer, I need auth, a database, a backend, and suddenly the whole architecture that makes the privacy angle real starts to erode. I'd only cross that if users were asking for it loudly enough that the trade-off was clearly worth it. So far, nobody's asked — which either means it's not needed yet, or I haven't found the users who'd need it most.
Curious what your ASO looked like before the reviews compounded — did you do anything to seed those first few, or just waited?
The no-backend, no-login constraint is a design forcing function - it eliminates a whole class of decisions you'd otherwise agonize over. Strong move for getting signal early.
The missing piece at this stage: you'll get feedback from users but have nowhere structured to put it. Conversations happen, insights surface, and they live in your memory or scattered DMs. Three months later you can't recall what the top 5 complaints actually were.
I've been building a Notion OS for solopreneurs (projects, CRM, decisions, revenue, weekly review) partly for this - a structured place to capture what you learn so it compounds instead of evaporating.
What's the main signal you're trying to capture from early users?
Firebase for feedback and ratings — that's the one exception to the no-backend rule, and honestly worth it.
Right now I'm not tracking what users generate, just what they feel about it. Early stage, that's enough signal for me.
Do you track feedback by source or by theme in your Notion OS?
The constraint-first approach is a good lens, and it applies beyond tooling decisions.
For solopreneurs operating at $0-5K MRR, every system decision carries the same weight - you can't afford 6 separate subscriptions (CRM, project tracker, revenue tracker, notes, task manager, analytics) when one system can handle everything. The constraint forces you to decide what's actually essential vs what just feels like infrastructure.
I'm building a Notion OS specifically for this segment - six linked databases: clients, projects, tasks, revenue, decision log, weekly review. One workspace, zero extra tools. The design simplicity isn't a compromise; it's the feature.
The 'built it for myself first' origin story is almost always where the best tools start. What use case are most people actually hitting your doc tool with - writing from scratch or reformatting something that already exists?
The constraint actually made the decisions easier, not harder. No backend means no auth, no storage, no infra cost. The scope just collapses to the actual problem.
Most people hitting the tool are generating from scratch — a prompt, not reformatting something existing. That surprised me a little.
One Notion workspace beating six subscriptions is the same logic honestly.
I like the approach - purely client-side with zero round-trip latency. Using the browser's memory for the assembly instead of a backend is smart. Structural privacy is a real differentiator here; it’s a lot more convincing than just a privacy policy. Great build!
Thanks! "Structural privacy" is exactly the right framing — that's going into the landing page.
The zero-latency part is an underrated side effect too. No round trip means the file is ready almost instantly, which feels surprisingly good as a user.
The no-backend, no-login constraint is smart for student projects - forces you to solve the actual problem instead of infrastructure. Nice build.
One pattern I've noticed with AI doc tools for academic contexts: the biggest friction isn't the tool, it's the prompts. Most students and researchers know Claude exists but don't know how to prompt it for research-specific workflows - literature review structuring, hypothesis stress-testing, methodology critique.
We've been looking at this gap from the supply side: is there real demand for pre-built Claude prompt libraries for research workflows? Not the tool itself, but the prompt 'recipe book' - buy once, use across any AI interface.
Curious if you've seen this with your users: do they struggle more with the tool or with knowing how to query it effectively?
The strongest part here is not “AI doc generation.” That category already sounds crowded. The sharper wedge is private, browser-only document generation for sensitive workflows where the user should not have to upload contracts, HR files, finance docs, or legal briefs to someone else’s backend.
That privacy line is powerful: server tools can promise they do not store data, but client-side tools can say they never receive it. That is much easier to trust, especially for documents people already feel nervous about pasting into random AI tools.
I’d probably position this less as a free AI doc tool and more as a local-first document automation layer. “Prompt to .docx” is the feature, but “private documents generated in your browser” is the trust hook.
One thing I’d watch is the name. docreplacer.online explains the function, but it feels narrow and utility-like. If this grows into a broader private document workflow product, Xevoa.com would give it a cleaner platform-style brand than a descriptive .online name.
Great approach. The client side architecture for document generation actually makes a lot of sense since the task is stateless. The privacy angle is also stronger than most AI tools because nothing touches a server. One thing I am want to know about though how are you handling the AI API call if there is no backend layer? Usually exposing an API key in the browser becomes a problem once traffic grows.
The key lives in the hosting server's environment variables — never shipped to the browser. The API call is made server-side, only the generated content comes back to the client. So the key stays hidden and the document still never gets stored anywhere.
Best of both worlds for MVP honestly.
This comment was deleted 13 days ago.