How I identified a $98 billion gap in the datacenter market

The hackathon flyer said “no experience required” and promised pizza. Three hours. Free API credits. Build something with Subconscious’s TIM agents. Win prizes if the thing was cool. The kind of event where half the projects become chatbots, and the other half become chatbots with more specific nouns attached.¹

I built a market analysis tool for data center site selection.

The market bottleneck it points at was about $98 billion in blocked or delayed data center projects in a single quarter of 2025. That is not a TAM slide number. It is actual stuck capital.

The tool is called SiteScope. It screens candidate data center markets and produces a structured dossier across power, incentives, community sentiment, natural hazards, connectivity, recent development activity, and regulation.

The product description is simple enough. The more interesting part is how I got from “free pizza hackathon” to “maybe the first two weeks of data center site diligence are exactly the sort of thing this agent should automate.”

Most of that path was just asking better questions in the right order.

§ 01Start with the tool

Most hackathon advice says to start with a problem. Usually, that is good advice. It gets worse when someone hands you a weird new tool you do not fully understand yet.

Starting with the problem too early can waste a lot of time. You might pick something the tool cannot do. More commonly, you pick something the tool can technically do, but has no particular advantage at. That is worse, because it lets you spend the whole hackathon building something mediocre without ever hitting a hard no.

So my first question was simple: what is this tool actually good at?

TIM agents are built for long, structured tool-use chains. The useful mental model is not “smarter chatbot.” It is closer to a research process that can keep going after a normal model would start losing the plot.

The practical advantage is breadth plus structure. Search, compare, filter, synthesize, repeat. Twenty or thirty steps deep. No individual step needs to be genius. Most useful research work is not genius work anyway. It is stamina work.

That ruled out a lot immediately.

No poems. No joke generator. No generic productivity wrapper. No “AI assistant for X” unless X had some unusually painful research loop hiding inside it.

The tool wanted a problem where the reasoning was manageable, the information was fragmented, and the first pass was boring enough that humans avoided doing it carefully.

That narrowed the search to a specific shape: tedious, structured research that saves a human from doing the first pass manually.

§ 02The useful band is narrow

A tool like this loses in both directions.

If the task is too easy, a normal LLM is cheaper and faster. If the task is too hard, a human expert still wins. The useful band is the middle: work a human could do, but does not want to do, because the volume is annoying and the steps are repetitive.

That also changes the product ambition.

“Replace the expert” is usually a bad claim. It sounds impressive in a demo and gets less believable every time someone asks a concrete follow-up question.

The better target is the part of the expert’s workflow the expert is already tired of doing.

This made the search less glamorous and more useful. I stopped looking for impressive problems and started looking for expensive boredom.

§ 03Chase stuck money

My first pass went through the obvious hot markets: AI policy, climate, longevity, agent tooling, finance.

Most of those were bad fits. Some were too vague. Some were too crowded. Some were already full of tools that only needed a regular LLM call and a decent landing page.

So I changed the question:

Where is the money flowing? Or just standing, preferably standing?

That question did real work. Hot money attracts tools. Stuck money exposes bottlenecks.

If capital is sitting still, the problem is often not that nobody has money. It is that the people with money are unsure where it should go. If the uncertainty comes from fragmented information, research agents become more interesting.

Capital stuck because there is no capital is not useful here. Capital stuck because nobody can assemble the right facts quickly enough might be.

§ 04The obvious idea was investment research

The natural version of this was an AI investment research tool.

Large market. Obvious user demand. Lots of fragmented information. Retail investors already use AI for financial decisions. Easy demo. Easy story.

Probably a trap.

The question that killed it was whether people use these tools to find truth or to get permission.

A lot of AI investment tools are basically permission machines. The user already wants to buy the stock. The tool gives them a professional-sounding paragraph that makes the decision feel less like a guess.

That is not always useless, but it creates a structural problem. A tool that genuinely challenges the user can feel worse than a tool that agrees with them. A tool that never challenges the user becomes a better-looking confirmation bias engine.

The best customers for adversarial investment research are institutional investors, and they already have analysts, terminals, data feeds, and procurement processes I was not going to beat in a three-hour hackathon.

So I dropped it.

The capability still seemed right: multi-source synthesis in a fragmented, fast-moving market. The user was wrong. I needed a domain where bad news was valuable.

§ 05Data center siting fit better

The pivot was data centers.

This was not random, exactly. I had watched a bunch of videos about data center deployment for fun, because apparently that is something I do now. Enough of the requirements had stuck in my head that the connection was available when I needed it: power, land, fiber, water, permitting, heat, local opposition, utility timelines, all of it awkwardly dependent on where the thing gets built.

That is the nice part about having a weirdly broad intake diet. Most of it sits around doing nothing. Then one day a hackathon agent needs a problem, and some video you watched for entertainment turns into a product surface.

The question was: what if the agent screened where companies should build data centers?

The fit was better for four reasons.

First, the money is large and blocked. Data center infrastructure needs are enormous, and a meaningful amount of planned development is delayed because teams cannot get sites through power, permitting, community, or regulatory constraints.

Second, the bottleneck is partly informational. Site selection depends on power availability, utility constraints, tax incentives, natural hazards, community sentiment, zoning, fiber, water, and local politics. None of that lives in one clean database. Much of it lives in local news articles, county documents, utility announcements, and scattered public records.

Third, the user wants to be challenged. If a site looks good on paper but has a local moratorium forming, a developer wants to know that before spending real money. In this market, “avoid this place” is useful output.

Fourth, community opposition is exactly the kind of signal a patient agent can find. Local pushback often appears before it becomes a formal blocker. It shows up in town meetings, local reporting, advocacy pages, and zoning debates. A human consultant can find it, but they may bill weeks for the privilege. A web-trawling agent can at least do the first pass.

That was the first point where the project felt real.

The tool did not need to solve data center development. It needed to save time in a narrow, expensive part of the workflow.

§ 06Scope is where the product becomes believable

The next question was the important one: what can this actually do?

Not what would make the demo sound good. What can the agent actually know from public information?

The answer split into three tiers.

That table is basically the product.

Most bad AI demos die because they pretend Tier 3 does not exist. They claim the whole workflow, which makes the whole thing unbelievable.

The stronger claim is narrower: SiteScope does not replace the consultant. It replaces the first two weeks of the consultant’s process.

Before the private conversations and relationship work start, someone has to screen markets. Someone has to read the local news. Someone has to find incentive programs, policy changes, opposition groups, utility updates, and hazard risks.

That work is valuable. It is also not the highest use of an expert’s time.

So the tool does not need to close the deal. It needs to tell the expensive humans where to look, and where not to waste their time.

§ 07What SiteScope does

SiteScope takes a natural-language site search request: target capacity, desired energization timeline, geographic preference, and how much the user cares about power, incentives, community risk, hazards, and connectivity.

Then it returns a structured market dossier.

Each candidate market is scored across seven dimensions.

Each dimension gets a signal: favorable, mixed, or constrained.

The output also includes a narrative brief, key risks, recommended next steps, and markets to avoid.

Technically, the stack is simple: FastAPI, React, and Subconscious’s tim-claude engine doing the research. The output is typed JSON validated against a schema, so it can drop into a dashboard or CRM without someone copy-pasting prose from a chat window.

The build was not the hard part. Once the problem was narrow enough, the product was almost mechanical.

§ 08The actual lesson

The portable lesson is not “build for data centers.”

The lesson is that useful AI products save a specific person a specific kind of time.

Not “save time” in the vague productivity-tool sense. Specific time. In SiteScope’s case, the time is early market screening. The person is someone doing site selection or diligence. The output is a better shortlist.

That framing gave me a filter for ideas.

1. What is the tool unusually good at?
2. Whose time does it save?
3. Is that time expensive?
4. Does the user want the truth?
5. Can the tool be honest about its boundary?
6. Is there a number that makes the pain concrete?

The main thing I got right was not the code. It was spending the first part of a three-hour hackathon deciding what kind of problem the tool deserved.

That sounds slow. It was not. It prevented me from building the obvious thing badly.

Most hackathon projects start with “what would be cool?”

This one started with a less fun question: what kind of boring work is suddenly worth automating because this tool exists?

That was the better question.

The flyer was technically right. No experience was required. Just some patience, some free API credits, and a willingness to treat “what should I build?” as the last question, not the first one.