I'm validating a B2B idea and want honest reactions.
Problem: data center developers sink millions into land that later gets blocked in local permitting or can't get grid power for years. $130B in projects stalled this year alone.
Idea: an AI that scores any US site on approval probability and time to power before they buy, as a paid per site service, with a free national risk map as the front door.
Two questions:
Would a developer or infra investor pay for this, or is it a "nice to know" they'd never buy?
What would make it a must have vs a curiosity?
Not selling anything, genuinely want to know if this is real.
Trending on Indie Hackers
The willingness to pay probably depends less on the score itself and more on whether the buyer can defend the decision internally. For a multi-million-dollar site, an opaque AI probability will feel like a curiosity. A report that shows the underlying permitting records, grid constraints, assumptions, confidence range, comparable projects, and when each source was last updated could become part of diligence.
I would position it as an early screening tool rather than a replacement for feasibility work: eliminate weak sites before exclusivity or expensive studies. The fastest validation may be to produce five reports manually for developers and ask whether each report changes a real shortlist or next action. If it does not change a decision, improving the model will not create urgency. I would also identify who has to defend the recommendation internally, because that person may be the real buyer.
You're right that the score on its own is the weak version, nobody's going to defend a multi million-dollar call on top of a number they can't see inside. So the deliverable isn't the probability, it's the record behind it: the actual permitting history, the grid constraints, the assumptions, a confidence range, comps, and a last updated date on every source. The score is just the cover page.
Early screening rather than a feasibility replacement is exactly where I've landed too, kill the weak sites before anyone spends real money on exclusivity or studies. And "who has to defend the recommendation internally" is the line I'm taking away from this. That person is probably the actual buyer, not whoever requests the report.
So the test you're describing, five reports done by hand, does each one change a real shortlist or a next action, that's what I'm going to go do. If it doesn't change a decision, no amount of model tuning fixes it. Appreciate you laying it out that clearly.
I think the problem is real. For infrastructure projects, avoiding a bad decision before committing millions is a strong value proposition.
The challenge I’d think about is positioning. “Approval probability” sounds interesting, but buyers may pay more for a clear business outcome:
How much time/money can this save before acquiring land?
How much risk can it remove from the investment decision?
Can it help compare 10 potential sites quickly?
The biggest question is probably data trust. If developers are making multi-million dollar decisions, they’ll need confidence in where the scoring comes from and how accurate it is.
If the tool can become part of the site selection process rather than just a research dashboard, I could see it becoming valuable.
This is the positioning I needed spelled out. "Approval probability" is the input, not the pitch, what a buyer actually weighs is how much time and money it strips out before land is committed, how much risk it takes off the investment decision, and whether it can rank ten candidate sites fast instead of one at a time. So I'm leading with the outcome, not the number. And you're dead on about data trust: for a multi-million dollar call they have to see where every input came from and how current it is, or it's just another dashboard they ignore. The goal is to sit inside the site selection process as a gate, not next to it as a nice to have. Thanks for this.
Not in your space so take this as an outsider's view, but the "nice to know vs. must have" question is the one that matters most. From what I've seen with our own product, people pay for things that remove risk from a decision they're already about to make, not things that just inform them.
If investors/lenders already do diligence on these sites anyway, the real test might be whether your score changes what they'd approve or how much they'd lend, not just whether it's accurate. A free scoring report on a site that already failed vs. one that's about to be greenlit could be a good way to see if it actually shifts a real decision.
People pay to take risk out of a decision they're already making, not to be informed in the abstract. So the real test isn't whether my score is accurate, it's whether it changes what a lender approves or how much they'd advance. I like your failed vs greenlit idea: run the report on one site that already died and one that's about to get a yes, and see if the output would have moved either call. If it doesn't move the decision, accuracy is beside the point. Doing exactly that. Thanks
That's great to hear, that test should tell you fast whether this is a "must have" or not. Good luck running it, would be curious to hear what you find either way.
1] data center is not small game mostly big players enter here why they need to use your web to check they already have researchers developers layears so they may use that why they gonna use you and pay you if your web done any mistake but showing wrong proof means do you think 🤔 you can pay off them so I think they won't take risk blindly . But the idea is nice
Fair challenge, and it's the one I have to beat. Big players do have teams and counsel, so I'm not trying to replace their judgment. I'm the independent early screen that kills weak sites before they spend on exclusivity and studies, and the outside read the finance side wants but didn't commission. On the accuracy risk you flagged: the deliverable isn't a bare number to take on faith, it's the evidence with a source and date on every line, positioned explicitly as decision support, not a guarantee. If it's ever wrong, they can see exactly why. Appreciate you giving me the hard version.
The hard part isn't the tool, it's mapping who feels the pain vs who controls the budget. Data center developers feel the risk, but often land decisions are driven by capital availability / financing windows rather than site intelligence.
Strongest validation signal: Find someone who lost $20M+ on a bad site choice, show them your tool would have caught it, see if they'd pay per site. If that person doesn't buy, it's a curiosity. If they do, you have your wedge.
Second validation: Talk to the finance teams approving $200M+ projects. Do they mandate site risk review before land acquisition? That's your must-have indicator.
For a $50M+ decision, "72/100" isn't defensible, they need to see the inputs and be able to defend them to an investment committee: interconnection queue position, permitting precedent, zoning history, utility capacity. So the number is just the cover; the product is the evidence file underneath it, with a source and a date on every line. If they can't defend it upward, it's dead on arrival. Building for exactly that. Thank you :)
The evidence over the score point in the comments is the real unlock here. I would go one step further and skip the survey question entirely. Find three developers who are mid diligence on a real site right now, hand them a full detailed report for free, and watch what they actually do with it instead of asking if they would pay. If it changes which properties they pursue or how hard they push a term in negotiation, that is your signal it is worth paying for, and if they read it and keep doing what they were already going to do, no price point fixes that.
You know what, this is the exact test I'm going to run, and you've said it better than I had it in my head. No more "would you pay." Find developers mid diligence on a real site right now, hand them the full report free, and watch what they do, drop it, push a term, order the study sooner, or read it and change nothing. If behavior doesn't move, no price fixes it. Going to go get those three sites. Appreciate you cutting straight to it.
A few good angles already covered here (existing spend, backtesting against
known sites, concierge reports). One thing I'd add: "would they pay" often
depends less on total spend and more on whether there's one specific person
inside the developer's org who gets blamed when a permit falls through months
after land is bought — the site selection lead, or whoever signed off on the
purchase. If that person exists and can point to a deal that went sideways on
their watch, they'll fight internally for a budget line even without one
existing today. If it's more of a shared/diffuse risk with no clear owner, it
tends to stay a "nice to know."
I'm chasing a similar question for a different kind of data product right now,
so genuinely curious how this goes for you.
It's not about total spend but it's whether there's a single named person who takes the hit when a permit falls through after the land's bought: the site-selection lead, whoever signed the purchase. If that person exists and can point to a deal that went sideways on their watch, they'll push for budget even where none exists today. If the risk is diffuse with no owner, it stays a curiosity. So my job is to find the person with the scar, not the org with the problem. Good luck with your data product, im also curious how yours goes too!
Risk map doesn't seem valuable here. But if you somehow help them choose proper sites with evidence and reasoning, this may help a lot. They may even pay for that.
Fair hit, the bare map on its own is the weak version, and I don't think anyone defends a multi milion dollar buy on top of a shaded state. Where you landed is exactly right: the value isn't the map, it's helping them choose a specific site with the evidence and reasoning attached, permitting record, grid constraints, comps, the whole file. The map's just the front door that gets them to send me a real parcel. That's the part im going to test with a few manual reports on live sites. Appreciate you cutting to it.
This sounds valuable, but the buyer probably won’t pay for a “score.” They may pay for reducing the risk of wasting millions on the wrong site. I’d validate it with the people responsible for site selection and due diligence and ask what evidence they currently need before approving a purchase.
Another sharp version of what I keep hearing: nobody buys a score, they buy not blowing millions on the wrong parcel. So I'm leading with the risk it removes, not the number. And your validation step is exactly the one I'm running, going straight to the people who own site selection and due diligence and asking what evidence they already need in hand before a purchase gets approved, instead of asking if they'd like my thing. Clarifying, thank you Nadia
That sounds like the right direction. Framing it around the financial risk makes the value much clearer than leading with the score itself. Speaking directly with the people who approve sites should also show which evidence would make the product credible enough to use in a real decision.
Exactly where I've landed, the value is the financial risk it removes, not the score, and the only way to know which evidence makes it credible enough to use in a real decision is to ask the people who actually sign off on a purchase what they need in hand first. So that's the question I'm taking into every conversation now: not "would you use this," but "what evidence do you already require before a site gets approved, and is any of it missing today." Thanks again Nadia, this clarified it :)
The free national risk map as a front door is the right instinct — that's exactly how you separate tire-kickers from buyers. The person who spends 30 minutes on your risk map exploring sites they're already evaluating is the person who'd pay for the full report.
On your core question: "nice to know" vs "must have" comes down to whether it replaces something they already pay for. If data center developers currently spend $5K–$50K on site feasibility consultants per project, your AI isn't a new budget line — it's a cheaper alternative to an existing expense. That's an easier sale than creating a new behavior.
One thing I'd test: instead of asking "would you pay?", ask "what do you pay today to solve this?" If the answer is "consultants" or "6 months of due diligence," you have a market. If the answer is "we just take the risk," you have an education problem, not a product problem.
Two things I'm taking from this. First, "what do you pay today to solve this?" is now my opener on every call instead of "would you pay?". If the answer is a $5K–$50K feasibility consultant or six months of diligence, I'm a cheaper line against a budget that already exists, a far easier sale than inventing a new one. If the answer is "we just eat the risk," that's an education problem and I want to know now. Second: the person who actually opens the map on sites they're already chasing is the buyer; everyone else is browsing. That changes who I chase. Thanks.
This sounds buyable, but only if the score changes an actual acquisition decision. “Approval probability” alone risks becoming an interesting report that nobody trusts enough to stake millions on.
To make it a must-have, I’d show the evidence behind the score: grid interconnection constraints, permitting history, zoning conflicts, water availability, local opposition signals, and comparable projects nearby. Then turn that into a clear recommendation such as proceed, renegotiate, investigate further, or walk away.
The strongest validation would be getting a few developers to give you sites they already evaluated and testing whether your system would have identified the same risks earlier. If it catches one expensive mistake before land acquisition, the value is obvious. The harder question is liability: how will you position the product so buyers use it as decision support rather than treating the score as a guarantee?
You're right that a bare probability becomes a report nobody stakes millions on, the deliverable has to be the evidence: interconnection constraints, permitting history, zoning conflicts, water, local opposition signals, nearby comps, resolving into one of four calls: proceed, renegotiate, investigate further, or walk away. I'm adopting those four verbs directly.
The validation you described is the one I'm actually going to run: get developers to hand me sites they've already evaluated and test whether the system flags the same risks earlier than they found them. If it catches one expensive mistake before land is tied up, the value stops being theoretical.
On liability, I'm positioning it explicitly as decision support and early screening, never a guarantee. Confidence ranges on every score, a last updated date on every source, and language that says "this changes what you investigate next," not "this is safe to build." Thanks for laying it out this cleanly.
That’s the right framing. The next layer should be an audit trail: every recommendation shows the source, date, confidence level, and what new evidence would change the verdict. That makes it defensible in an investment committee rather than another black-box score.
For the pilot, I’d measure false negatives especially closely. Flagging a few extra risks is tolerable; missing one fatal constraint is not. If the system consistently surfaces deal-killers earlier and documents why, buyers can operationalize it.
The audit trail is going straight in: every verdict shows its source, the date, a confidence level, and what new evidence would change the call, so it holds up in an investment committee instead of reading like a black box. And you're right that false negatives are the ones that kill me. An extra flag is cheap; a missed fatal constraint is fatal for the buyer and for my credibility. So the pilot metric I care about most is whether it catches the deal-killers earlier than they did, not whether it looks polished. Appreciate the precison.
The "would they pay" question turns on whether the score changes a decision or just describes one. Land teams already know permitting is the risk; what they'd pay for is a number they can put in front of an IC or a lender. That's the difference between curiosity and must-have, and why the supports for such numbers are crucial.
There are a few more pieces I'd add to your formulation, the most salient of which is the potential of power generation on site. This already creates an optimisation for geographies that support solar arrays, wind turbines, geothermal, etc. Beyond this, however, there is a question of the larger power usage in a certain municipality's grid, because an over served grid is more likely to support a data centre effectively.
Another thing to note: data centres are themselves somewhat overbuilt, especially as hardware continues to optimise. So there are several considerations: power use, cost for the data centre itself, and the most difficult, that of water. Water management relating to data centres concerns not only environmental issues and the protection of surrounding groundwater and water supplies but the water usage of the data centre, which requires additional optimisation.
All of these things can influence the score, but what I'd suggest if you are going to build this out is to create several sub-domains, each of which you develop individually: power (grid and generation), water, land, and zoning/political considerations on a local level.
For each sub-domain, you can develop hybridised approaches that increasingly utilise AI to conduct and check research, integrating new tools as they become available. However, developing them as separate sub-domains provides a much more compelling offer for investors. Each of the sub-domains, when developed adequately, can be applied to additional use cases and is potentially an acquisition target in its own right.
So the must-have version is probably the one where a lender or IC actually accepts the number — which is why the substantiation matters more than the breadth of coverage.
Good luck!
Thank you for the depth. The sub domain structure, power (grid and generation), water, land, zoning/political, is something I hadn't laid out cleanly, and you're right that building each as its own module is both a stronger product and a better story for investors, since each one stands alone and could matter beyond this use case. The on site generation angle, solar, wind, geothermal shifting the optimization by geography, and the over vs under served grid point are going straight into how I think about the power module. Water I'd underweighted, both the groundwater exposure and the facility's own usage as an optimization problem. And the through line I'm keeping above all of it: the must have version is the one where a lender or IC actually accepts the number, which means substantiation beats breadth. Genuinely grateful :)
The interesting part is that the product could potentially influence a multi-million dollar decision before capital is committed.
What would convince you that developers would treat this as a required diligence step rather than just another data point they consider alongside existing feasibility studies?
The only thing that would convince me is behavior. A developer sends me a real site they're actually evaluating, gets the score, and then does something different because of it: drops it, moves faster, renegotiates price, orders the study sooner. If the score never changes what they do next, it's a "nice to know" they'll nod at and ignore, and I'd rather find that out now.
The "required diligence step" version probably only happens if it slots into a gate they already have to clear, something an investment committee or a lender expects to see before capital's committed. So the real question I'm chasing isn't "is this interesting," it's "does it change your next move, and does anyone above you require it." Going to test exactly that with a few free reports on live sites.
The reproducibility question is the one that decides whether this survives diligence. A site that scored 72 in March and 61 in July is not a new answer, it is either a real change in the permitting record or drift in your own pipeline, and the buyer has to be able to tell which one it was. Freezing the source snapshot and the model version into every report is what makes that answerable later, and it is also what lets someone re-open a report six months on without re-running anything.
The other half is extraction. Whatever you pull out of permitting dockets and interconnection queues is the weakest link, because a claim nobody can trace back to a specific line on a specific document is exactly what gets pulled apart in an investment committee. I treat that as a deterministic verify step after the model rather than something the model gets to assert: every extracted fragment resolves to a page and a position, or it does not ship.
When a score moves between two runs, can you currently show which input changed?
https://gist.github.com/renezander030/7780cbc0b3ad4e802e8fba8bfc1c3a66
Right now, no. I can't cleanly show which input moved a score between runs, and you've correctly identified that as the thing that fails diligence. Freezing the source snapshot and model version into every report is going straight in, so a change resolves to either "the record changed" or "my pipeline drifted," and someone can re open a report six months later without re running it. Same for extraction: every claim resolves to a page and a position in a named document or it doesn't ship, verified deterministically rather than asserted by the model. Thanks, this moved my roadmap.
The risk factor is a real consideration, but certainly not the only one. Often, large businesses select specific locations because of other factors such as public visibility, political points, or just bias on the part of decision makers. As much as we like to pretend otherwise, humans are not nearly as rational as we pretend to be, and that can outweigh other factors even in huge decisions such as where to put a multi-billion dollar datacenter.
Fair, and it's the honest limit of what I'm building. Tax incentives, political optics, an executive's preference, none of that is in a zoning docket, and a model that pretends otherwise is lying. What I can do is bound the knowable part: whether this board has approved projects like this before, whether the queue supports the timeline, whether the water right can legally transfer. Then say plainly where the model stops and human judgment begins. A screen that narrows the field, not an oracle that picks the site.
An investor would do a search on your question and be looking at your top 4 competitors right now. You want to vet the idea, first and foremost. Get the lay of the land. Find out if it EXISTS first. Do a Google search in AI mode of your idea (or any LLM). Always get the facts, before opinions. Land development and commercial real estate has been rich in data analytics and predictive modeling for decades. These folks jumped on the AI bandwagon in its earliest stages. Hospitals, airports, malls, casinos, stadiums, race tracks have all been high stakes, HIGH-FRICTION all along, so it's been flush in high tech long before the data center gold rush. Unfortunately, your exact business model has some major well-established competition. We all have to vet our ideas with data.
You're right and I should have led with this. I did the sweep: Paces is funded and shipping a permitting predictor with a data center product line; Enverus already scores county level regulatory and community risk across millions of parcels; LandGate, PVcase, datacenterHawk and DC Byte cover land, interconnection engineering, and leasing. So no, the space isn't empty, and "nobody's doing this" was lazy of me. Where I think there's still a gap: those tools read static ordinance and zoning data, not the live decision record, nobody has coded the actual votes, published a base rate, or published their own accuracy. That's a narrower claim than I started with, which is probably a good sign. Thanks for making me check.
Interesting idea. If I were in the target market, I'd see value in it, but only if the predictions are backed by reliable data and explain why a site gets a particular score. Developers and investors usually make decisions worth millions, so they'll want transparency, not just an AI-generated number.
You could also consider expanding it beyond a simple approval score. Things like utility availability, zoning risks, permitting history, environmental constraints, and comparable projects could make it much more actionable. That would turn it into a decision-support tool instead of just a risk indicator.
I've seen companies like FATbit Technologies build custom B2B platforms around niche business workflows, and one thing that stands out is that customers are more willing to pay when the software solves a specific operational problem rather than simply providing data.
If your tool can genuinely help users avoid costly land purchases or reduce project delays, I think it has the potential to become a "must-have." The next step I'd take is talking directly to a handful of developers or infrastructure firms and validating whether this would save them enough time or money to justify paying for it.
Agreed on both counts, and the expansion you describe is where I've landed , availability, zoning risk, permitting history, environmental constraints and comps, resolving into a decision rather than a number. On transparency: every line carries a source and a retrieval date, and the report states what evidence would change the verdict. Your closing point is the one I'm acting on: go talk to actual developers and infra firms rather than tuning the model.
I would validate it as a paid diligence product, not as a map. The must-have version is a short memo that helps someone say no to a bad site before they spend legal, land option, and interconnect money. If 5 developers will pay for one site review manually, the AI/risk-map wrapper is worth building.
The map isn't the product, the memo that lets someone say no before they spend on legal, land option and interconnect is. And your bar is right: if five developers won't pay for one manual site review, building the AI wrapper is premature. That's the sequence I'm running.
Honestly the investor/lender pivot feels like the real unlock :) a developer knows their own pipeline, but someone doing diligence on a deal they didn't build has no independent read. That's the person who'd pay.
And +1 to what others said: I wouldn't buy a "score," but I'd absolutely pay for "here's the permitting record + grid constraint that says don't touch this parcel." Show the evidence and it goes from curiosity to must-have real fast.
Cool space, would love to see where this goes :)
This matches what several people landed on independently, which is usually a sign it's true. The developer knows their own pipeline; the party diligencing a deal they didn't build has no independent read and carries the loss. And I've stopped selling the score, the deliverable is "here's the permitting record and the grid constraint that say don't touch this parcel," with sources attached. Appreciate it, will report back on how it goes.
On who pays: the developer probably won't, the investor might. Anyone big enough to be buying sites already has a site selection team doing this in-house, so to them it's a nice-to-know competing with people they already employ. The infra investor running diligence on someone else's pipeline is the opposite. They want an independent read they didn't commission, and that's a real wallet. I'd point the paid product at the money, not the builders.
Must-have vs curiosity comes down to two things imo. Lead with time-to-power over permitting. Local approval risk is knowable if you know the county, but interconnection queue timing is genuinely opaque with no clean national source, so that's the part they can't already get. And don't ship a bare score. Someone committing eight figures wants to know why it's a 68, and if the reasoning isn't visible the demo falls apart with exactly the buyer you're after. The score's the headline; the evidence is the product.
The developer already employs the people who'd do this, so to them I'm competing with their own team, a nice to know. The infra investor running diligence on a pipeline they didn't build wants an independent read they didn't commission. That's the wallet. Pointing the paid product at the money, not the builders. Thank you.
Glad it landed. The flip side of aiming at investors: their demand is lumpy. They buy when there's a live deal on the table, not on a subscription cadence. So the next thing to pin down is whether this is a recurring product or per-deal work dressed as a subscription. That fork, SaaS vs consulting, changes how you'd price it and whether it's even the business you want to be in.
Investor demand is lumpy, like they buy when there's a live deal, not on a monthly cadence so pretending this is SaaS when it's really per deal work would set the wrong price and the wrong expectations. My read: it starts as per site work priced against the millions a dead parcel burns, and only becomes a subscription if the monitoring piece, a moratorium filed, a queue position that frees up power near a site they hold, earns its own recurring value. Two different businesses, and I'd rather be honest about which one it is early. Appreciate you pushing on it Sergey :)
The buyer here is not the developer, it's whoever carries the risk of a dead site: the lender, the IC, the REIT. Sell it as underwriting support priced per site against the millions a blocked parcel burns, and "nice to know" becomes a required document in the deal file. Quick validation test: ask three site-selection or infra-debt people if they'd attach your report to a deal memo, and at what price.
The buyer is whoever carries the risk of a dead site, not the person who picked it, lender, investment committee, REIT. That's the shift I needed. Sold as underwriting support priced per site against the millions a blocked parcel burns, it stops being optional and becomes a line in the deal file. And your test is concrete enough to run this week: ask three site-selection and infra-debt people whether they'd attach my report to a deal memo, and at what price. If they won't attach it, I don't have a product. Going to go ask. Appreciate this.
The pain is real. Developers losing millions to blocked permits is a genuine problem worth solving.
But here's the thing. Your buyer has to find you before they buy the land, not after. That's the hardest part of this business. By the time they know they have a problem it's too late for your product to help them.
What's your plan for getting in front of them at the right moment?
This is the hardest part and you named it, by the time they feel the pain, the land's bought and I'm too late. My plan for catching them at the right moment: the free county level risk map is the top of the funnel, and the person who opens it on a region they're actively evaluating is self identifying as mid diligence. That's my trigger to reach out with a free full report on their specific parcel. I'm also going straight to the finance side, since lenders and ICs see the deal before capital's committed, earlier in the timeline than even the developer's own regret. Curious whether you think there's an earlier trigger I'm missing.
The lender angle is smart, I had not thought about that. Finance side sees the deal earlier than the developer's regret does. On earlier triggers, what about title companies or surveyors? They touch the parcel before diligence even starts. Might be worth exploring whether they can refer or flag deals heading into active evaluation.
your two questions have the same answer, and it's about WHO you sell to, not whether the pain is real. the pain obviously is — but developers have in-house site teams + brokers they already trust for exactly this, so a third-party AI score stays a curiosity to them until it's decision-grade. the must-have version isn't the one with the widest coverage, it's the one a lender or IC will accept as independent diligence. that points at a different first buyer: the people financing the site, not the ones picking it. the developer thinks they already are the number; the lender actually needs an outside one.
also worth a competitor sweep — datacenterHawk / DC Byte and the interconnection-analytics folks are adjacent; good to know what a funded incumbent already puts in front of these buyers.
Two things im taking. One: the must-have version isn't the widest coverage, it's the one a lender or IC will accept as independent diligence, which points me at the finance side as the first buyer, not the builders who think they already are the number. Two: I did the competitor sweep. datacenterHawk and DC Byte own leasing and market data, the interconnection analytics tools own the grid engineering, but none of them score defensible time-to-power at the parcel level from the actual decision record. That gap is the wedge. Thanks for pushing on both.
I think the legal risks need to be considered very carefully first; otherwise, it could potentially bankrupt you.
Taking this seriously, because you're right that liability could end me faster than any competitor. My B2B service is positioned as decision support and early screening, never a guarantee, every score carries a confidence range and a last updated date, and the language says "here's what to investigate next," not "this is safe to build." I'm also getting a proper opinion on disclaimers and data source terms before anything goes paid. Thanks for the warning.
the $130b stalled number does most of the convincing here honestly, that's not a nice-to-know problem. my instinct is it only becomes must-have if the score is trusted enough to kill a deal, not just flag it.
Agreed , the $130B stalled is the part that makes this a real problem and not a nice to know. And your bar is the right one: it's only a must have if the number is trusted enough to kill a deal, not just flag one. A flag gets noted and ignored; a kill changes behavior. That's the standard I'm buildng the evidence to clear. Thanks
the flag vs kill line is a good way to hold yourself to it. curious what evidence gets you there, past deals that actually died the way the model predicted?
Exactly that, backtesting against deals that already died. I take sites that got blocked or stalled, run the model on the state of the record before the decision, and check whether it flagged the actual killing constraint and how early. If it only works in hindsight it's worthless. The harder half is false negatives: an extra flag is cheap, a missed deal killer destroys the buyer and my credibility. So the metric I care about is whether it catches the fatal constraint earlier than they did, not whether the overall accuracy looks good.
@AlexDeGreat false negatives being the real bar is the right call. same reason we backtest bunzee's output against what actually shipped, not what looked plausible. how many dead deals until the pattern holds?
Appreciate the swing on these. The distributed micro data center idea is real, edge and modular builds are growing, but the ones on abandoned buildings and casino land still hit the same wall my whole thesis is about: power availability and local permission. Smaller footprint doesn't automaticaly mean faster interconnection, and reservation land adds its own jurisdictional layer. The consulting angle is interesting though, because it points at something I keep circling: the water and generation sub domains might have standalone value beyond scoring sites. If I can map where recycling or on site generation actually makes a parcel viable, that's consulting grade knowledge whether or not it lives inside the software. Taking the water piece more seriously because of comments like this. Thanks
the water piece having standalone value is interesting, that might be the wedge more than the score itself. sometimes the sub-domain is the actual product.
This is where I've landed after the whole thread: the water and generation sub domains might be the real wedge, not the score. On site generation and water recycling are the two things that can flip a dead parcel into a viable one, and almost nobody maps that cleanly today. So even if the overall scoring product takes time to earn trust, here's where water or self generation makes this site buildable is standalone, consulting grade value on its own. Sometimes the sub component is the actual business. Thanks for pushing me all the way to that, rlly love this thread :)
My ideas are radical so take with a grain of salt: 1. Network small data centers on private properties like abandoned buildings / shopping centers / Indian Reservation Casinos; think SpaceX Satellite data centers except on Earth 2. Become an expert / consultant on building water recycling and electrical generation; give Ted talks get street cred; do grass roots shows in communities to enhance public relations; perhaps petition; then go to state officials with proposals; name your consulting group; get paid for consulting which uses your software to map prospective sites.
The split between who feels the pain and who controls the budget is the thing I have to get right. Developers feel the risk, but land timing is often driven by financing windows, and the budget sits with finance. So my strongest validation is what you laid out: find the person who ate a $20M+ loss on a bad site, show them the tool would have caught it, and see if they'd pay per site. And on the finance side, the question I'm taking into every call is whether they mandate a site risk review before land acquision, because if that gate exists, I want to be the document that clears it. Thank you.
This is a real problem, and I think the honest answer is: it depends entirely on which half of your idea you lead with.
The free national risk map is a nice to know infra investors and developers already have in-house GIS/permitting teams for that, or pay for existing data providers like, grid interconnection queue trackers, zoning data aggregators. A map alone won't get paid.
The per-site score is where it gets interesting, but only if you can answer the diligence-grade question: "Why should I trust this score over my own team's judgment?" For a $50M+ land decision, "an AI scored it 72/100" isn't enough they need to see your inputs (interconnection qu3ue position, local permitting precedent, zoning history, utility capacity studies) and be able to defend the number to their investment committee.
The map is just the surface but the actual product points a developer at specific parcels worth pursuing with the evidence attached, and flags the one they're chasing if it doesn't clear the bar. A recommendation with reasons, not just information. Thanks.
Love the idea. With your startup can you identify locations and then start recommending.
Yes, that's exactly where it's headed. The map is just the front door. The real product points a developer at specific parcels worth pursuing with the evidence attached: permitting record, grid headroom, comps. Not "here's a shaded map," but "these three sites clear the bar, here's why, and the one you're chasing doesn't." A recommendation, not just information. Appreciate it.
Building on the must-have thread — I'd look hard at which of your two metrics is actually the wedge. "Approval probability" is contestable; the first time it's wrong, a skeptical analyst discounts the whole tool. "Time to power," though, plugs straight into a pro forma — it's a schedule input that moves IRR. If you can defend a months-to-energization number, that's the line that ends up in the model, and de-risking the model is what people pay for.
On the free national risk map: watch that it doesn't anchor the category as free. I'd keep the free layer at region/county resolution (directional only) and put parcel-level precision — the part they'd stake millions on — behind the paywall. The free map earns trust and SEO; the paid report is where "nice to know" turns into "can't close without it."
You're right that approval probability is the contestable one, the first time it's wrong, a skeptical analyst writes off the whole tool. Time to power plugs straight into a pro forma and moves IRR, so that's the number that survives in the model. I'm leading with months- o energization as the defensible line and treating approval odds as supporting evidence, not the headline. And keeping the free map directional at county resolution while parcel level precision stays paid, that stops the category from anchoring as free. Taking all of it. Thank you very much :)
The 'nice to know vs must have' question is the real crux here. With PLEBS — a verified luxury club I'm building — we hit something similar: everyone loves the idea of proof/verification in the abstract, but paying for it is a different commitment. What made the difference for us was targeting the people who get hurt by the lack of it (in your case, probably the investors who eat the $130B in stalled projects, not the developers who caused it). Who bears the cost of getting it wrong in your model — the buyer of the report, or someone else downstream?"
Congrats on PLEBS, sharp parallel, everyone loves verification in the abstract until the invoice shows up. Your question is the one I have to answer: who eats the cost when a site goes sideways. In my model it's split, the developer sinks the land spend, the fund or lender eats the delay on their return. But you're right that the person who got personally burned is the one who fights for a budget line. So I'm going to find whoever at a developer signed off on a site that later got blocked. That person already has the scar. Thanks for this.
This feels real if you can turn uncertainty into a decision, not just a report. Developers and infra investors pay when the output helps them kill bad sites early, prioritize the right ones, or negotiate with confidence before they spend serious money. The free map is a good front door, but the paid product becomes a must-have only if it saves them months of diligence or one expensive mistake.
"Turn uncertainty into a decision, not just a report" is the line I needed. The output can't stop at information, it has to kill bad sites, rank the good ones, or give someone the confidence to negotiate. And the bar you set is the right one: it has to save months of diligence or catch one expensive mistake, or it stays a curiosity. Building toward exactly that test. Appreciate it
This comment was deleted 9 days ago.
This comment was deleted 9 days ago.