A week ago, I launched RamenHire — a job board only for bootstrapped, profitable startups. This week was less about building new features and more about the internet doing what the internet does best: finding the gaps I didn't know I'd left.
Here's what actually happened.
The verification question that wouldn't go away
RamenHire's whole pitch rests on one promise: every listed company is genuinely bootstrapped, not VC-funded. So when someone commented on Product Hunt asking, essentially, "okay, but how do you actually verify that?" — it wasn't a gotcha, it was the single most important question anyone could ask.
The honest answer at the time was: manually, by me, checking Crunchbase and a Google search. Not glamorous, but true. Saying that out loud publicly forced me to actually think about whether that's good enough, and to start being upfront about it rather than letting "verified ✓" do more rhetorical work than it's earned.
Killing my own feature before it shipped to real users
The original plan for company profiles was: pre-populate profiles for the 13 companies whose jobs I'd already curated, then let them "claim" their profile via a magic link when I reached out.
Building it out, the framing started to bother me. These companies don't know RamenHire exists yet. Pre-building a profile for them — even a good-faith one — quietly implies a relationship that isn't there. So I scrapped the claim flow entirely and rebuilt it as pure self-registration: companies find RamenHire, register themselves, and I approve manually. Nothing gets built for anyone without them asking first.
It's slower. There's no clever growth hack of "look, you're already listed!" It also means the directory launches empty and stays empty until real companies show up on their own. But it's the version I can defend if anyone asks how it works — which, per the above, someone always eventually does.
Writing legal pages nobody will read, correctly, on the off chance someone does
Privacy Policy and Terms of Use are the least exciting part of any indie project, and the easiest to fake with a template. I didn't want to do that, partly because RamenHire has real EU visitors (GDPR isn't hypothetical), and partly because I'd rather the page be accurate than impressive.
So instead of filling in a template, I had the actual codebase audited first: what data gets collected, where it's stored, which third parties touch it, what cookies actually fire. Two findings from that audit mattered more than the policy text itself:
- Google Analytics was firing unconditionally, for every visitor, with zero consent gate. Not a documentation gap — an actual compliance gap.
- Admin notifications were quietly landing in a personal Gmail inbox instead of the project's real address.
Both got fixed as part of writing the policy, not just described in it. The cookie banner now genuinely blocks GA4 until you accept — verified by checking that no cookie appears at all pre-consent, not just that a banner shows up.
The comment that actually mattered
I wrote a separate post a few days back about a gnarly Supabase Storage RLS bug. A reader, Pon, left a comment pointing out that one of the example policies I'd shared — authenticated role, read access to an entire bucket — would let any signed-in user read any uploaded CV, not just their own. On RamenHire specifically, that policy is effectively admin-only today since there's no job-seeker account system, so nothing was actively exposed. But the policy itself didn't actually express "admin"; it expressed "anyone signed in," which is a landmine if that ever changes without someone remembering why.
Then, a day later, a sharper follow-up from the same person: even the write side has a gap — anonymous uploads to that bucket aren't tied to any real application, so nothing stops junk files from accumulating in storage that never came from an actual applicant. That's not a hypothetical either — it's the same category of risk as the rate-limiting and bot-protection work I'd just finished, just a door I'd left open on the Storage side instead of the API side.
That's now fixed — direct anonymous uploads have been replaced with short-lived, signed upload URLs tied to a specific application or company record, minted server-side. There's nothing left to upload to without a real submission behind it, and I verified this directly against production: a raw upload attempt using the public key now gets rejected outright.
Genuinely one of the more useful comment threads I've had on anything I've written. Public work gets public scrutiny, and this week that scrutiny made the product better twice.
Where things actually stand
- Company registration is live (self-serve, admin-approved, email-verified before it even enters my review queue).
- Privacy Policy and Terms of Use are up, grounded in a real data audit, not filler.
- Rate limiting, real bot verification, and (as of this week) signed upload URLs are in place across every public form.
- Real registered companies: 0. Real job seeker applications: 0. That's the honest number, and it's exactly why next week is about outreach, not more features.
What's next
I'm intentionally not chasing job seeker growth yet. A job board with no real employers isn't a job board; it's a list. So the next push is entirely about getting real, bootstrapped companies to actually register — cold outreach to the companies already featured, and direct conversations with hiring managers, before any push to bring in job seekers.
If you run a bootstrapped, profitable company and you're hiring, I'd genuinely love to hear from you — register a free company profile here and I'll take it from there. And if you spot something broken while looking, even better. That's basically been the whole engine of week 1.
Top comments (0)