New $100 million town in Texas focused on hard-tech
Ashlee Vance, a tech journalist, spent a few days inside Prototown, a Texas ranch where young founders are trying to build a hardware manufacturing hub from scratch. Partway through the tour he stops at Evan’s workspace, a shipping container full of solar-powered cooling panels, and asks him to explain what they do. It’s the kind of unscripted product walkthrough most technical professionals eventually have to give: a stranger stops by, and you have about thirty seconds to make something complicated land.
What makes the exchange worth studying is how Evan gets a complicated idea across without losing anyone. He skips the actual chemistry and hands the listener an analogy instead (“charges like a battery”), he names concrete markets instead of speaking in vague generalities, and he turns an obvious downside into proof that the product works. That’s the skill this post breaks down: the specific moves that make a technical explanation sound credible, not just casual. You can watch the entire video or just the clip.
What do you want to do today?
Watch the clip.
Type what you hear.
Now say it with them.
Five moments with colleagues overseas. Which phrase fits?
Cultural Notes
The battery analogy is doing more work than the chemistry.
When Evan says the panels “charge like a battery and then release it as cooling,” he isn’t simplifying because his audience is unsophisticated. He’s making a deliberate choice: skip the actual endothermic chemistry and hand the listener something they already understand completely. The strongest technical communicators aren’t the ones who explain the most. They’re the ones who find the right comparison and stop there.
Naming the market is a confidence move.
“These are meant for buildings. They’re meant for houses. So large infrastructure, warehouses, data centers, through the military.” Evan doesn’t say “this could be used for a lot of things.” He lists specific sectors, one after another, in ascending scale. Naming concrete verticals like this, instead of speaking in generalities, is what makes an early-stage idea sound like it already has a real market behind it.
“Good problem to have” turns a weakness into evidence.
Every product has a downside. Evan doesn’t deny that his workspace runs hot, and he doesn’t apologize for it either. Calling it “a good problem to have” reframes a real complaint as a byproduct of something working. It’s a standard move in professional English: acknowledge the issue is real, then connect it to why it exists, without sounding defensive or dismissive.