Long before “one-shot” became a popular phrase in AI prompting, we were pursuing the same practical outcome in real estate feasibility:

Get to a strong first answer immediately—then refine it through fast, interactive edits.

That’s been TestFit’s approach from the beginning. A decade ago we set out to make feasibility feel less like a handoff and more like a live planning session. 

TestFit is built to deliver a strong first layout quickly—good enough to react to immediately—then stay responsive as you refine it. You can adjust goals, constraints, and assumptions on the fly and see the design evolve in real time. The point isn’t a perfect first answer, it’s a credible starting plan in seconds that’s easy to change.

Back when “generative design” mostly meant “set it up and wait”

When generative design arrived, AEC had a compelling promise: let software explore possibilities faster than any team could by hand. The idea was solid. What didn’t work, for most teams, was the fit between how those systems operated and how decisions on real projects actually get made.

And for a long time, the practical way to access that promise wasn’t “out of the box” at all. It often meant bringing in a specialist—someone who could script in tools like Dynamo or Grasshopper—to stitch together a one-off workflow for a specific project or studio. Powerful, yes. But rarely repeatable, rarely easy to share, and not something most teams could rely on day-to-day.

In practice, this forced teams to formalize the design in the way a computer prefers, pushing generative design into a corner of the industry: available to the teams with the time, budget, and technical talent to build custom setups, and less accessible to everyone else who still needed answers quickly.

Modern development teams tend to need the opposite experience: tools that behave the way projects behave. Interactive. Constraint-aware. Grounded in real requirements. Easy to steer as priorities shift mid-meeting—without turning every feasibility question into a scripting exercise.

So we built TestFit around a different rhythm:

Generate then edit.

What “one-shot” means in TestFit

One-shot doesn’t mean “perfect.” It doesn’t mean “final.” It means the first output is already useful. It’s not staring at a blank screen with ‘builders block’, it’s starting with a plan that lets you react immediately.

When you generate in TestFit, you should be able to answer questions like:

• Can my site fit what I want?
  
• How much optionality do I have? (unit mix, parking approaches, massing, etc.)
  
• Will this pencil? (at least enough to know whether it’s worth the next step)
  

All in the time it takes to sip your tea.

Then you do what humans do best: judgment.  edit.

Relying on real-world experience, you are in the best position to make complex decisions while wielding powerful tools.  You: Move a building. Adjust parking. Change the unit mix. Tighten a constraint. Loosen another.  See the results and consequences of those edits immediately.

That loop is the product. The value isn’t just the output. It’s the ability to explore.

Why speed changes everything

If a tool takes long enough that you have to context-switch, you use it differently. You run fewer tests. You save “what if” questions for later. You stop experimenting.

But when the loop is quick, something flips. You start using feasibility as a true creative and decision-making surface—where you can test ideas as they come up, compare tradeoffs while everyone’s still aligned, and keep momentum through the messy middle of early design. 

That’s why we’ve always treated speed as a core product decision, not an optimization project. The way TestFit is built—our building engine-first approach and performance-focused implementation—lets us run these iterations dramatically faster than prior automation approaches. Those stacks still carry overhead that shows up right where it hurts: in the feedback loop. For real-time feasibility, that difference can be 30x faster in practice.

When feasibility is that responsive, teams don’t just go faster—they go wider. They explore options they simply wouldn’t have time to explore otherwise.

Why “generate then edit” beats “generate” or “edit” alone

A giant list of options you can’t control does a disservice to the intelligence held within our community.

Spending hours or days to get to something usable does a disservice to your time.

Because in real projects, “best” is rarely a single score.  It’s a shifting mix of goals and constraints that change the moment someone asks a new question.  No one can fully spell out upfront every preference, zoning, politics, priorities, practicality, etc..

That’s why we focused on giving you presets, proven defaults of how projects actually get done, plus the controls of the most common constraints.  All in an effort to generate the outcomes you actually want, a strong starting point and making iteration effortless.

Instead of forcing users to become constraint experts before they can get value, we aimed for:

• Strong defaults you can trust
  
• Outputs grounded in reality
  
• Flexibility to adjust without restarting
  

Generate, then edit is how you move quickly without oversimplifying the real world.

Making “real” plans, not just pretty ones

It’s easier than ever to generate something that looks like a plan. But feasibility isn’t about looking right. It’s about being actionable.

Early design has to survive contact with reality:

• Rules and requirements
  
• Practical layouts and circulation
  
• Buildable assumptions
  
• The “this will never fly” instincts teams develop over the years
  

Those instincts matter. And they’re not always written down anywhere.

Over time, we’ve learned that great feasibility software doesn’t just draw fast. It helps you reach options that make sense for how projects actually get approved, priced, and built—and then lets you refine them quickly as new information comes in.

What we’ve been building for 10 years

TestFit isn’t a “push button, get perfection” machine.

It’s something more useful:

A one-shot starting plan you can immediately edit—fast enough to explore, grounded enough to decide.

That’s the approach we chose 10 years ago. And it’s still the approach that makes feasibility feel less like a waiting game—and more like a conversation with your project.