Two things happened this week that matter more than anything I built: I asked 13 real companies for permission, and a stranger's public feedback closed out a security thread that started three comments ago.
The security thread closes out
A reader (credited in the comments of my last post) found three real issues in RamenHire's Supabase setup over the course of a few days — an overly broad delete permission, a question about whether upload URLs were properly tied to real submissions, and, in the most recent round, a second broad delete grant I hadn't caught either. Each one got fixed and verified against the actual production environment, not just tested locally and assumed to carry over.
The full audit — including a proper security-audit-with-severity-ratings pass, an HTML-injection fix in outbound emails, and one deliberately deferred item I'm tracking rather than rushing — is public in the repo now. Prompted entirely by someone reading closely and asking good questions in a comment section. That's a better security process than I would have run on my own, for free, because I wrote honestly about what broke.
Outreach: 13 emails, 1 real response
This week's actual work: reaching out to all 13 companies whose open roles I'd curated onto RamenHire before they knew the site existed. Permission-first, not "you're already listed, come claim it" — I've written before about why I killed that model.
The honest tally so far: one response. Featurebase's founder (genuinely lovely exchange, handled by their own AI support tool, no less) asked me to take their listing down since they manage hiring through their own Notion board — and thanked me for asking first instead of just listing them. That's a real, if small, validation of the honest approach: even a "no" landed well, because it was actually their choice.
Twelve are still silent, which is the expected outcome of cold outreach in week one, not a bad sign yet.
What's coming next
Company self-service is next on the build list — specifically, a way for a company to edit or remove their own listing without emailing me directly, using the same verified-email pattern already built for registration. Directly prompted by the Featurebase exchange: watching a real company ask "please take this down" made it obvious this needs to be self-serve, not something that routes through my inbox every time.
What I actually don't know yet
Two honest, open questions, and I'd genuinely like real answers rather than assumptions:
For anyone who's looked at ramenhire.com cold — does the homepage explain what this is and why "verified bootstrapped" matters, fast enough? Or does it need to work harder before someone decides whether to keep reading?
For founders specifically — before you'd register a company profile, what would you want to see first? Proof of real traffic, other companies already listed, something else entirely? I don't have enough registered companies yet to learn this from usage, so I'm asking directly instead.
Happy to hear blunt answers on either.
Top comments (14)
The one response you got may be more useful than it looks.
It was a no, but it proved the permission-first version of the product can create a clean company reaction: they understood why they were listed, had a clear way to object, and left the exchange without feeling scraped.
For the founder registration question, I would not only ask "do they need proof of traffic?" I would ask what risk they think they are taking by registering.
If they think the risk is "will this send applicants?", traffic proof matters.
If they think the risk is "will this misrepresent our hiring process?", then verified control, edit/removal rights, and example company pages may matter more than raw traffic.
The tricky part is those are different promises. A founder may not need to believe you can fill the pipeline yet. They may first need to believe the listing will not create cleanup work.
That is also why the one clear "no" may be more useful than the twelve silences. It gives you an actual objection to read.
This is a sharper split than I'd made myself — I'd been treating "would you register" as one question, and you're right that it's actually two different risk assessments wearing the same sentence. Featurebase's decline was the "will this misrepresent us" flavor, not the "will this send us applicants" flavor — they didn't ask about traffic at all; they asked to control the listing.
Good timing too: the next real piece of work is exactly "verified control, edit/removal rights" — real per-company access instead of routing every change through my inbox. Your framing gives me a cleaner way to think about why that's the right thing to build next, versus building a traffic-proof page instead.
Agreed on the last point too — I've been quietly treating 1/13 as a disappointing number, when it's actually the only real signal in the batch. The twelve silences taught me nothing; the one no taught me what to build.
The status label clears one layer, but probably not the whole bar.
"Pending vs approved" tells them the state. It may not tell them whether the process is alive.
For a company, the worry is usually not just "what is the label?" It is "am I waiting on the system, on you, or on something I need to do?"
So I would add the smallest clue that answers ownership of the next move: last updated, next expected step, or who it is waiting on. Not necessarily all three.
The signal to watch is simple: after this ships, do companies stop emailing you to ask where the listing stands?
That's the gap exactly — the status view answers "what," not "whose move." I hadn't separated those. Right now it's a static label with no timestamp or next-step hint, so a company today genuinely can't tell if they're waiting on me or if something's stuck.
Your test is the right one, and it's honest that I can't answer it yet — zero real registered companies so far means zero real data on whether anyone still feels the need to email me. First real signal will be whether that question ever gets asked once someone's actually sitting in "pending." Adding a last-updated timestamp is a cheap first step even before I know the answer.
That is the right split. The label tells them what state they are in, but not who owns the next move.
A last-updated note is probably the right cheap first step. It does not prove company demand yet, but it does reduce the chance that the first real company becomes your status-checking loop.
Yes, that is the distinction to keep close while building the access layer.
For that next piece, watch not just whether companies register. Watch whether the first few can claim, edit, or remove a page without feeling like they have become your QA process.
If the control flow lowers that anxiety, it is doing real work even before the marketplace proves applicant volume.
Good timing — that access layer is exactly what just went into planning, and "does it feel like they've become my QA process" is a sharper bar than anything I'd written down for it. Easy to build, edit/remove, and call it done because the button exists; much harder to notice if using it still feels like reporting a bug to me. Stealing that as the actual test before I call it finished, not just "does it work."
That is the right bar.
The failure mode to watch is not just "can they find the edit button?" It is whether they can tell what state the listing is in without asking you.
If the flow makes ownership feel confirmed rather than requested, you have probably removed the first trust blocker. After that, applicant volume becomes a cleaner second question.
That's a sharper cut than mine — "find the edit button" is a UI question, "know what state it's in without asking me" is a trust question, and I'd been treating them as basically the same thing. Just built the piece that addresses this directly: a company will be able to log in anytime and see pending vs. approved on their own, no email needed to find out. It's built and tested locally, not live yet — running one more security pass before it ships. Once it's up, curious whether that alone clears your bar, or whether "confirmed vs. requested" needs something more explicit than a status label — a timeline, an estimate, something showing progress rather than just a static state.
Took the cold look you asked for. Headline plus the manually-reviewed line answered what and why fast, no complaints there. Where I stalled was the post-a-job button, it shows Free and $99 in the same breath, and I had to find the early-access line before I knew which one you meant.
Fixed and live. The hero button and the post-job submit button both just say "Free" now, unambiguous — the $99-later context is nearby as supporting text instead of stacked on the button itself. There's a pop-up modal elsewhere on the site that already had this right, so I matched its button style instead of inventing new copy.
While checking the page directly instead of just trusting the fix, I also found an unrelated regression on the same page — missing Open Graph/Twitter metadata that had silently broken on 6 pages sitewide (a Next.js quirk where a page's own metadata object fully overrides the layout's instead of merging with it). Fixed that too, plus built a shared helper so it can't silently break again per-page. Not what you flagged, but wouldn't have gone looking without your comment prompting a proper look at that page in the first place.
Shipped inside a day, with a bonus regression caught on the way. The override-not-merge thing is easy to miss because every page still renders, nothing looks broken until a share card turns up blank. The button read was the easy half, you did the rest.
Appreciate that — and honestly, four rounds in, I don't think I'd have developed the habit of actually checking pages directly instead of trusting the code without this whole thread pushing me to. Thanks for sticking with it.
One heads-up while I have you: there's a bigger piece of work coming up — real per-company accounts and access scoping, replacing the current "authenticated basically means admin" setup that's been sitting there deliberately unaddressed. Given the track record so far, I'd genuinely welcome another look once it's up.
Count me in when it ships. Access scoping is a meatier round than button copy, and naming the 'authenticated basically means admin' problem out loud before building is the right order to do it in. Write it up like you did this one and I'll show up.