Hi everyone,
I built ForgCV, a simple CV builder that lets users create resumes instantly without signup.
The goal was to remove friction and make it fast and accessible.
I’d really appreciate your feedback on usability and features.
Wow, encoding the entire state into the URL itself is an absolute galaxy-brain move for a privacy-first tool. I love this idea.
It completely solves the cross-device issue while keeping the architecture 100% serverless and zero-database. A user could literally just bookmark their unique URL or email it to themselves, and boom—instant backup. I'm definitely adding this to my R&D backlog to see how it handles the character limits for longer resumes. Thank you for flagging this technique!
On the ATS front, you are 100% right. Claims mean nothing without hard proof. I’ve been validating the templates against real, standard industry parsers (like the ones used behind Workday and Greenhouse) to make sure the linear reading order, semantic headings, and selectable text hold up perfectly. But I agree—I need to document this testing rigorously and make the proof visible. Once it's bulletproof, it will definitely become the leading angle.
Thanks for the solid feedback and the killer URL suggestion!
Removing signup is a nice first step, but I think the real opportunity is reducing the time between "I need a resume" and "I'm confident enough to apply."
That's the moment users actually care about—not how many fields they had to fill out.
That’s a really good way to frame it.
I agree — no signup is only useful insofar as it helps reduce the time between “I need a resume” and “I feel confident enough to apply.” The real goal isn’t saving users from filling out a registration form, it’s helping them get to a resume they’re actually comfortable sending as fast as possible.
That’s also how I’m starting to think about ForgCV: not just as a resume builder, but as a tool for shortening the path from intent to application.
Interesting.
Reading your reply made me think less about shortening the application process and more about what the product quietly commits itself to once confidence becomes the thing it's really optimizing for.
I don't think I can explain that line of reasoning properly in a thread without oversimplifying it.
If you're interested, what's the best email to reach you on?
The localStorage tradeoff is a real one, losing your resume the moment you switch devices kills a lot of the "no signup" convenience it's supposed to offer. The reframe about shortening the gap between needing a resume and feeling confident applying is a sharp way to think about it though, that's a much better roadmap compass than just more templates. Are you leaning toward some kind of optional sync without full accounts, or does that break the whole pitch?
You’ve hit the exact tension point of building serverless, privacy-first utilities. The device-switching friction is real.
To answer your question: a full account system absolutely breaks the core pitch and the "zero friction" philosophy I want for ForgCV. However, I am strongly leaning toward optional, frictionless sync methods that don't require personal data.
In fact, someone else in the thread just suggested a brilliant approach: encoding the entire resume state directly into the URL itself (like a compressed Base64 string). The user could simply bookmark that link or send it to their other device to resume editing. No database, no emails, just pure data portability.
Alternatively, a simple "Export/Import JSON backup" button is another lightweight way to let users move their data without creating an account.
I love your point about the roadmap compass. Shortening the time-to-confidence for an applicant is the real North Star. Additional templates are just aesthetic variety; solving the seamless mobility of their data without breaking privacy is the real engineering goal.
Thanks for pushing the thinking on this!
Encoding the whole resume into a compressed URL is a clever workaround, no database and no account, but still gives people a way to move between devices. Export/import JSON as a fallback covers the people who don't want to deal with a long URL too, having both options seems like the right call. Curious which one ends up getting used more once people actually have the choice.
This comment was deleted 2 months ago
The strongest part is not “free CV builder” — that space is crowded. The sharper hook is “no signup, your CV data stays on your device.” I’d move that much higher, probably into the hero/subheadline, because it answers the exact fear people have with resume tools.
A few UX fixes I’d test:
1. Hide the “0 CVs created / 0 rating / 0 countries” counters until they become proof. Right now they create doubt.
2. Make the first CTA only “Build my CV free — no signup.” Cover letter can be secondary.
3. Be careful with the testimonials section if the visible counters are still zero; it creates a trust mismatch.
The product promise is good. The page just needs to make privacy + speed impossible to miss.
This is incredible feedback. You are 100% spot on about the trust signals and the hierarchy of the landing page.
1. "No signup, your data stays on your device" is absolutely the real hook. I am moving that straight into the hero/subheadline today. You're right—competing on "free" is a race to the bottom, but competing on absolute data privacy and immediate speed is where ForgCV actually wins.
2. On the UX fixes: You caught me red-handed! Those counters ("0 CVs created...") were a leftover placeholder component from my initial setup. Leaving them at zero absolutely kills trust and creates a massive mismatch, especially next to placeholders or testimonials. I am removing or hiding them entirely until they represent massive, undeniable proof.
3. Streamlining the CTA to strictly "Build my CV free — no signup" makes perfect sense to keep the user laser-focused on the primary action. The cover letter option can easily sit cleanly inside the app dashboard once they are in.
The page needs to make privacy and speed impossible to miss, and your notes give me the exact checklist to achieve that. Truly appreciate you taking the time to audit this so deeply!
Glad it helped, and yeah, privacy + speed is way more defensible than a “free CV builder.” Just watch out when you update the hero: don’t make the privacy promise too vague. “Your CV data stays on your device” hits harder than just “privacy‑first” because it tells people how it works right away. When the new version goes live, drop me a link, I can give it another quick look.
nice idea, removing signup friction is actually a big win, especially for something like resumes where people just want to get in and out fast
curious how you handle saving though, like if someone closes the tab do they lose everything? that’s usually where no-signup tools struggle
overall feels like the right direction, just comes down to how smooth the experience is end to end
Thanks! You're totally right—the "get in and out fast" mindset is exactly what I'm aiming for.
To answer your question about saving: your data is completely safe! Because ForgCV utilizes the browser's LocalStorage, a user can close the tab, crash their browser, or shut down their computer, and everything will still be right there waiting for them when they reopen the site.
The only time they would lose it is if they explicitly clear their browser cookies/cache or use an Incognito tab.
To make the end-to-end experience even smoother and solve the device-switching issue, I’m currently looking into adding an optional "Export/Import JSON backup" button, and another builder in this thread suggested a slick way to encode the data state directly into a shareable URL.
Keeping it bulletproof and frictionless is the goal!
The client-side, no-account setup is the right call here, but the localStorage choice has a trap you'll hit fast: the CV lives on exactly one browser. Someone drafts on their laptop, wants to tweak it on their phone on the way to an interview, and it's just gone. You can keep the zero-cost, zero-signup promise and still fix that — let people export their data as a small file (or a URL that encodes it) and re-import later. That's the returning-user problem solved without a database.
On the ATS claim: I'd test that before putting "parses perfectly on Workday and Greenhouse" on the page. Clean semantic HTML and a clean ATS parse aren't the same thing. The usual killers are multi-column layouts, tables, text baked into an image, and unusual fonts. Running one of your generated PDFs through an actual parser (even pasting it into a plain-text extractor and reading what falls out) shows you exactly what Greenhouse sees. If it survives that, the claim is a real edge worth leading with.
Features next: whatever shortens "blank page to something I'd actually send". A few starter templates by role beats another export format.
Spot on from start to finish. You just perfectly outlined the exact two challenges I'm tackling right now.
1. The device-switching trap is real. To keep the zero-cost, zero-signup promise while solving this, I am actually implementating exactly what you suggested: an "Export/Import JSON backup" button, along with an absolute galaxy-brain idea shared earlier in this thread—compressing and encoding the entire state right into a shareable URL. No DB, no accounts, just pure data portability.
2. On the ATS side, I appreciate the warning. Clean HTML is just step one; a real parser is a completely different beast. I've been actively testing the generated PDFs through standard text-extractors and actual parsing simulators (mimicking the exact multi-column and layout traps that Workday and Greenhouse use) to ensure the reading order doesn't break. I completely agree with you—I need to document this rigorous testing and make the hard proof visible on the landing page.
3. "Blank page to something I'd actually send" is my new favorite definition of a feature roadmap. Shifting focus toward role-specific starter templates rather than just random layouts is a killer advice to shorten that time-to-confidence.
Thanks for the precise critique and the solid roadmap direction!
Glad it landed. One flag on the shareable-URL idea before you ship it: a CV is basically a bundle of PII — name, email, phone, work history — and once that's encoded into a URL, it leaks in ways people don't expect. Server access logs, proxies, browser history, any analytics that grabs the full path. For a tool whose whole pitch is "no signup, no DB", that's the one place the promise can quietly break.
Two cheap fixes if you go ahead. Put the state in the URL fragment (the bit after #) so it never reaches the server or shows up in logs. And add a line telling people a shared link contains their data, so nobody pastes it into a public channel by accident. The JSON export doesn't have this problem, so that stays your clean path.
That is an incredibly sharp and crucial catch. You're 100% right—encoding PII directly into the standard URL query parameters entirely contradicts the "privacy-first / no-signup" promise due to server logs and analytics leakage.
Using the URL fragment (the hash
#) is the perfect solution here, since anything after the#stays strictly on the client side and never touches the server access logs.I'm definitely going to lean on the local JSON export/import as the primary clean path, but if I do roll out the shareable link feature, I'll implement the URL fragment method along with a clear warning on the UI.
Appreciate you flagging this before it became an issue!
Sounds right. Two small gotchas for when you build the fragment version, so they don't bite later. Fragments still land in the user's own browser history, and in anything that syncs that history across devices, so the "this link contains your data" warning still earns its place. And a full CV, once base64'd, can blow past URL length limits in some browsers and mail clients, so compress before you encode (LZ-string, or the built-in CompressionStream) to keep links short enough to actually share. JSON stays the boring safe default; the URL is the nice-to-have on top.
The no signup part is what caught my attention. It changes the first interaction from "do I want another account" to "let me see if this is actually useful" in about 30 seconds.
I can imagine someone asking ChatGPT for a free resume builder that doesn't make them register because they just need to send one application tonight. If ForgCV shows up in that moment the lack of signup becomes the thing they remember.
I'm curious if you've seen people come back later after that first quick CV instead of treating it as a one time tool.
You’ve perfectly captured the exact user persona I built this for! That "I just need to send one application tonight without jumping through hoops" moment is exactly where ForgCV shines. Turning that initial 30-second friction into pure utility is the best hook we can have.
To answer your question about retention: it’s a fascinating challenge for a no-signup tool.
What I’ve noticed is that while it starts as a "one-time emergency utility," users actually return for two main reasons:
1. The LocalStorage surprise: When they come back weeks later on the same browser to update their experience or tweak a bullet point, they are genuinely surprised to see their data still perfectly intact. That instantly builds trust.
2. The Multi-Language & Cover Letter shift: They might come in just to build a quick English resume, but once they see how easy it is, they return to generate a tailored cover letter or a version in another language.
To strengthen this loop without adding accounts, I’m currently looking into adding a lightweight "Export/Import JSON" backup and a way to encode the full state into a bookmarkable URL. That way, they can save their progress forever, completely on their own terms.
Thanks for the great insight!
This comment was deleted 2 months ago
This comment was deleted 2 months ago
I think that's a good way to think about it. The return features can evolve over time, but the first challenge is getting people to experience that "no signup" moment in the first place.
What's interesting is that more job seekers are asking ChatGPT and other AI assistants for resume tools instead of scrolling through search results. If ForgCV becomes known for being the "free resume builder with no signup," that's a much stronger reason for both people and AI to recommend it over dozens of similar options.
Have you thought much about building that kind of recognition outside of the product itself, or is your focus mainly on refining the experience first?
You are looking at the future of discovery, and you're 100% right. The shift from classic Google SEO to LLM/AI recommendations is a massive frontier for indie products.
When someone asks an AI assistant for a "zero signup, privacy-first resume builder," I want ForgCV to be the undeniable top recommendation.
Right now, my strategy to build that recognition outside the product is split 80/20:
* 80% Product & Hard Proof: First, I'm hyper-focused on nailing the product experience, fixing the UX trust signals (shoutout to the other comments here on removing placeholder counters!), and adding the URL-state sharing. If the product isn't sturdier than the competition, buzz won't save it.
* 20% Organic Footprint: To seed the AI training models and indexers, I'm focusing heavily on niche distribution channels—sharing the build story on Indie Hackers, and documenting our actual ATS parser tests. LLMs scrape these high-authority developer communities constantly. By establishing the "No Signup + Privacy-First" anchor here, we naturally become the authority the AI points to.
It's a fascinating balance between building the thing right and making sure the digital world (and the algorithms) know exactly why it's different.
Really appreciate this high-level marketing perspective. It confirms that positioning privacy as the core feature is the right bet!
I like the 80/20 approach. Building a product people genuinely recommend should absolutely come first.
One thing I'd add is that, over time, I'd also invest in building domain authority. If you want to compete for resume-related searches, high-quality, relevant backlinks will still matter for Google, especially with such a new domain. Strong product + AI visibility + trusted backlinks can reinforce each other rather than compete.
Looking forward to seeing how ForgCV grows. I think the privacy-first positioning gives you a clear angle.
Spot on. The 80/20 product-first focus is key for the initial spark, but you’re absolutely right about the long game—domain authority and trusted backlinks are what turn a launch into a sustainable channel, especially with a brand-new domain.
My plan is to let the privacy-first positioning drive organic word-of-mouth and indie community visibility first, which should naturally start bringing in those high-quality, relevant context backlinks from tech and career blogs. Combining a highly-recommended product with targeted SEO will definitely be the formula to chip away at the bigger players over time.
Thanks for the solid advice and for following the journey of ForgCV! 🚀
Glad the advice resonated! Since you agree on the importance of domain authority and premium backlinks, here is a practical shortcut: don't just wait for organic word-of-mouth to bring those links.
Journalists and tech writers love covering tools that break the corporate mold, and your "no-signup, zero-tracking" angle is perfect media material. Proactively pitching ForgCV to career, productivity, and tech publications can land you featured articles. A single mention on a high-authority tech site will instantly give you the kind of domain authority that usually takes months of standard SEO to build, while firmly anchoring your tool in AI search datasets.
I actually specialize in structuring these types of media outreach and PR campaigns to fast-track authority for indie products. If you want some ideas or specific angles on how to pitch ForgCV to journalists for those high-quality backlinks, feel free to drop me a line at mumar @ growwithmumar . online. Wishing you the best of luck with the growth! 🚀