I got tired of "that works there, not here." So I built a wiki that lets you check.
Twenty years in design and product, most of it in Turkey. One consultancy, sold. Four years inside a crypto exchange that grew faster than its org chart. In every one of those rooms I heard the same sentence wearing different clothes: "Sure, GitLab does that. We can't."
Usually nobody in the room had read what GitLab actually does. Me included.
So this summer I started reading the handbooks. GitLab, Netflix, Automattic, PostHog, Basecamp, 35 companies in the end. Not the blog posts about them, the documents they wrote for their own people. I pulled out every concrete claim I could find: how they run meetings, hire, pay, decide, work remote, use AI. 1,704 claims so far, each linked to where it lives.
Then I put them side by side. https://howtheydoit.co/
You ask a question in plain words. It answers with a comparison, not a verdict: here is how six companies handle it, here is where they disagree, here is the source for each. My rule was simple: if I can't link it, it doesn't go in.
Some things I learned building it:
Handbooks change. GitLab's is a living document; a claim that was true in March is gone by August. So every source has a "last verified" date, and re-checking is most of the work now. Average is 7 days.
Companies contradict themselves. The culture page says one thing, the engineering handbook another. I keep both and mark it.
The Turkish version matters more than I expected. Half my early readers are managers in Istanbul who never had a reason to open an English handbook.
What's not figured out: money. It's free and in beta. I'm looking at a few directions (a paid research tier for HR/people teams, sponsored deep dives, a video interview series, first guest I'm chasing is Jason Fried), and I'd rather hear from people here who've monetized a reference product than guess.
Honest question for the room: if you run a team and a tool showed you how 35 companies handle the exact problem you have this week, sources included, what would you pay for, if anything?
The Turkish traction is the least surprising part of this to me, and it might be the most monetizable.
I localized my own product into 21 languages before it had real revenue, arguably too many, but it taught me one thing clearly: competition for good professional content in English is brutal, and in most other languages it is nearly absent. An Istanbul manager searching for how GitLab runs meetings has almost nothing to read in Turkish. You do not just rank more easily, you become the reference.
The trap is that a wiki is not an app. Interface strings translate once, but your sourced claims drift, and a stale translation of a claim you re-verify weekly quietly breaks the one promise the product makes. So I would not translate the corpus. Translate the interface and the query layer, keep the claims in English with their source links, and localize only the summaries around them. Cheap where it wins search, untouched where staleness would hurt.
Do the Turkish users query different topics than the English ones? If they cluster on a few themes, you could localize just those pages first and charge for the depth.
That translate-the-shell-not-the-corpus split is exactly the plan — I don't want a Turkish fork of stale claims sitting next to a re-verified English one. Too early to say if Turkish readers cluster on different topics; we only launched last week and I want a few more weeks of real queries before I trust the pattern. My guess going in was remote work and pay transparency, since those come up most in the DMs I get, but I'll check the logs before committing engineering time to it. Appreciate you spelling out the trap this clearly — saved me from a fairly expensive mistake.
The source-first approach is probably what makes this much more valuable than a generic “how companies work” database. You're selling confidence in the information, not just access to it.
For monetisation, I'd be tempted to explore the research/workflow angle rather than charging for the reference itself. For example, letting a People/HR or leadership team ask a specific question, compare companies, save the comparison, and turn it into something they can actually use in a decision.
The 1,704 claims are the asset, but the workflow around them may be what people actually pay for.
That's a sharper way to say it than I'd been thinking about it — sell the workflow, not the reference. Charging for a lookup is a hard sell when the alternative is free (skim the handbook yourself); charging for "here's the comparison already built, saved, and ready to hand to your team" is a different pitch entirely. I like the People/HR framing especially — that's the audience that needs the sourcing to defend a decision upward, not just satisfy curiosity. Going to sit with this instead of jumping straight to a pricing page — thanks.
I'd consider paying for a comparison that helps with a specific team decision. Knowing the problem each practice was meant to solve and how the team was organised would help me judge what could work for us.
That's useful to hear stated that specifically — the "why" behind each practice, not just the practice itself, is exactly the layer I've been underbuilding. Right now the wiki mostly gives you the what and the source; the problem-it-solves framing lives in my head, not on the page. Is that something you'd want built into the comparison itself ("this exists because of X"), or more like an assistant that takes your team's specific constraints and tells you which of the 6 approaches fits? Trying to figure out which is worth building first.
The source-linked comparison makes this more useful than another “best practices” library. Have early readers used it to make an actual hiring, remote-work, or process decision, rather than just browse how other companies operate?
Since we only launched last week, we haven't collected enough data yet to see a real pattern in user behavior. Our primary goal is to build a knowledge base that lets people who spot growth potential in their internal systems form hypotheses with less cognitive overhead while doing their research — and then, with their input, turn it from a raw tangle of insights into a genuinely useful tool.
That intended use case is interesting. I’d be curious to see what decisions users eventually make with it. If you’re open to it, what’s the best email to reach you on?
you can reach me via htdi@tabularasa.email
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.