u/hironavalo

Not the WA government agency — I mean LandGate Corp, the parcel/energy data platform that Wood Mackenzie just acquired in June.
I work on land acquisition tooling outside the US and I’m trying to understand what actually got used in the field vs. what was marketing:

1. Did your team pay for PowerTools / PowerParcels, or did you just use the free property reports?

2. How accurate were the ownership and parcel records in practice? What % did you have to re-verify at the county?

3. Did it replace any part of your workflow, or just sit alongside your existing county research?

4. If you dropped it, what made you drop it?
   Happy to share what I find back here.

I'm building something in this space, so I'll say that up front. There's no link in this post and nothing to sign up for. I'm trying to work out whether my premise is wrong before I spend another few months on it.

Here's the premise. Planning artifacts live outside the work. The story map or the roadmap is in a whiteboard tool, the work is in the tracker, and the only thing connecting them is a person copying between the two. I think that single fact causes two separate problems, and I'd like to know whether either is real for you, or whether I'm just describing my own bad habits.

The first is staleness. The map is accurate for exactly as long as someone keeps doing that hour of copying. The week nobody does it, it quietly stops being true. Nobody ever decides to abandon the map — people just stop opening it.

The second is that you are paying for the copy. In my case: source control, a whiteboard tool to think the product through, a tracker to run the week. Three subscriptions, and one of them exists only to hold a duplicate of what already lives in another one. I'm pre-seed and paying out of my own pocket, so I feel that sharply — though I'm aware that if you work somewhere with a budget, tool spend is someone else's problem and this second point may read as noise to you.

There's also an asymmetry I keep coming back to. Plenty of teams ship without a story map. No team ships without tickets. The map is optional and the tracker is not, which makes it strange that we keep putting the map somewhere the tracker can't reach. Whatever else a team does, the work passes through the tracker. That's the one artifact nobody gets to skip, and it's the only place a map could live and be guaranteed to stay true.

I built mine on GitHub, where the issues already sit next to the code, the pull requests and the releases. That's a narrower bet than I'd like, and I know it puts this outside where a lot of you actually work.

So, honestly:

1. When your map or roadmap went stale, did it cost you anything? Or did it do its job in the room, and going stale was simply fine?

2. Does tool sprawl register as a real problem where you work, or only as a line item procurement worries about? I genuinely can't tell whether "one fewer tool" is a benefit anyone but me cares about.

3. If planning lived directly inside the tracker — journeys across the top, releases as rows, moving a card changes the real issue — what would you lose? My guess is speculative planning: you'd want to shuffle things around to think out loud without touching the actual work. But I've only tested that on myself.

4. Is the reason this doesn't already exist that it's hard to build, or that it's been tried and teams didn't want it? That's the answer I'm most afraid of and the least able to find out from the inside.

For calibration: it's been quietly available for a while and almost nobody has signed up. From where I sit, "the marketing is bad" and "the idea is wrong" look identical, and I'd rather be told the second one now than in six months.

Sharing this for critique rather than clicks — I have three specific questions at the bottom and I would rather hear the hard version.

Your GitHub issues are a flat list. Fervio lays them out as a map of your product: user journeys across the top, the steps under them, cards below, release rows down the side. Drag a card into another release row and it reassigns the milestone on the real issue.

Hi from Japan, and apologies if the English reads a little stiff.

I am building a tech startup, pre-seed, and the part nobody warned me about was the subscriptions. GitHub for the code. A whiteboard tool to think the product through. An issue tracker to run the week. Revenue was zero, but the invoices showed up every month anyway.

So I tried to live inside GitHub Projects alone. That did not work either. My issues sat there in one flat list, and I still could not answer the only question that mattered that week: what do we build next?

What I wanted was the shape I kept drawing in the whiteboard tool, but built out of the issues that already existed instead of copied by hand into yet another place. People who do agile call this a story map. I just wanted mine to stay in sync with the real work.

So there is no database of my own. It reads live from GitHub every time you open it, and the map cannot quietly drift away from reality.

I used it alone for a while. Then I showed it to a friend and they asked if they could use it too. That is the only reason it is a product and not a script sitting on my laptop.

They have not actually signed in yet, though. Sign-up only opened a few days ago. I am still the only account this thing has ever had, and nobody has stress-tested it but me. That is the honest state of it.

This week it also grew sprint rows and a status board. Sprints map onto GitHub's iteration field, and the board groups every column into journey and step swimlanes, which is the one thing GitHub's own board view never shows you.

About the permission, before anyone has to ask. GitHub's consent screen will say "Full control of private repositories." I like that as little as you do. GitHub has no issues-only scope, so touching an issue in a private repo means asking for the broad one. The token can technically read your code — Fervio does not, because the program never calls that API. That is a "does not," not a "cannot," and there is a page that spells the whole thing out. If you would rather not, there is a public-repos-only sign-in, and on that path GitHub itself blocks private repos, so it is not a promise from me.

It also writes two single-select fields, Journey and Step, on the Project you pick, plus an Iteration field if you use sprints. That is the only structural change it makes, and deleting those fields puts the Project back exactly as it was.

Stack: Cloudflare Pages and Functions, KV, React and dnd-kit. Strict CSP with zero external calls, so no analytics, no CDN, nothing.

Three things I would genuinely like to hear:

1. First ten seconds. Does the map make sense without me explaining it?
2. Would you actually grant that scope? Does the public-only option change your answer?
3. What is the one missing thing that would stop you using this on real work?

Free while in beta. There will be a paid tier one day, but I have not decided what belongs in it, and working that out is part of why I am posting.

https://fervio.co
https://fervio.co/permissions/

Thanks for reading this far.

Japan is dealing with a massive "phantom queue" crisis on its power grid due to extreme capacity hoarding for Battery Energy Storage Systems (BESS).
The grid application rule used to be "first-come, first-served" with zero requirement to actually own the land. Speculators exploited this to reserve capacity they could flip later.
It got so bad that developers were submitting connection requests using public disaster parks, active construction sites, and random people's private homes. They literally just picked spots on a map.
The result? A staggering 110 GW of fake applications jamming the queue, while actual connected capacity is just 0.23 GW. Legitimate clean energy developers are completely blocked.
The government is finally forcing developers to prove land ownership this year to purge the queue, but it's insane it got this far. Has any other grid seen speculative hoarding this bad?