BEFORE

• 

  BEFORE’s core interface — stress-test an idea before building it.

• 

  Start with the problem. BEFORE turns an initial idea into a structured stress test.

• 

  BEFORE separates the real problem from the first solution, then identifies who experiences it.

• 

  The problem is clear. Now BEFORE begins challenging the assumptions behind the solution.

• 

  BEFORE simulates the people affected by an idea, revealing the goals and constraints that a single viewpoint can miss.

• 

  Different stakeholders expose different constraints, revealing where the proposed solution faces pressure or breaks entirely.

• 

  BEFORE separates what works, what creates friction, and what breaks when the idea meets real-world constraints.

• 

  BEFORE reveals what works, where friction appears, and exactly where the solution breaks under real-world constraints.

• 

  BEFORE exposes the assumption beneath the solution and links it to the stakeholder perspective that challenges it.

• 

  BEFORE changes one real-world condition and reruns the pressure test to see whether the idea still holds.

• 

  The changed condition exposes the pressure point: the solution cannot control transportation uncertainty.

• 

  BEFORE transforms the exposed failure point into a constraint-led solution that can survive real-world conditions.

• 

  BEFORE turns the broken assumption into a root constraint and reframes the original solution around what actually matters.

• 

  BEFORE brings the entire stress test together—idea, people, friction, assumption, failure point, and reframe—into one actionable impact map.

• 

  BEFORE ends with actionable validation questions and a clear stress-test result: your idea survived—but it changed.

Inspiration

Most tools that help people build ideas are designed to make those ideas better.

We wondered: what if the most useful thing an AI could do was try to break an idea first?

A solution can look convincing while being built on a hidden assumption about the people it is meant to help. For example, reminding students to leave home earlier sounds reasonable—until the real constraint is an unpredictable bus.

That led us to build BEFORE: a pre-build reality test that stress-tests an idea before time and resources are spent building it.

What We Built

BEFORE takes an idea through a structured pressure test:

IDEA → UNDERSTAND → PEOPLE → SIMULATE → FRICTION → ASSUMPTION → FAILURE → WHAT IF? → REFRAME → IMPACT STRESS MAP

Instead of simply suggesting features, BEFORE:

1. Separates the underlying problem from the proposed solution.
2. Identifies people who may experience the solution.
3. Simulates their goals, constraints, and possible perspectives.
4. Maps what works, what creates friction, and what breaks.
5. Detects a potentially high-leverage hidden assumption.
6. Links that assumption to the simulated scenario that challenged it.
7. Runs a structured What If? experiment by changing one condition.
8. Reframes the solution around the constraint that actually matters.
9. Produces an Impact Stress Map with evidence, validation questions, and the history of the stress test.

The key interaction is:

SIMULATE → STRESS → EXPOSE → WHAT IF? → REFRAME

BEFORE is intentionally not a generic chatbot, brainstorming assistant, or SWOT worksheet.

How We Built It

We built BEFORE as a modular web application using:

• Python
• FastAPI
• Pydantic
• Uvicorn
• HTML5
• CSS3
• Vanilla JavaScript
• Pytest

The backend uses a provider abstraction with two modes:

• Fixture Mode — deterministic and offline, making the hero demonstration reliable and repeatable.
• Live Mode — an optional OpenAI-compatible provider for structured AI analysis.

The reasoning pipeline is divided into independently testable engines for idea analysis, stakeholder simulation, friction detection, assumption detection, failure analysis, What If experiments, reframing, and stress-map generation.

Structured outputs are validated with Pydantic before continuing through the pipeline.

For the MVP, sessions are stored in memory. No API credentials are placed in the client.

The Challenge

The biggest challenge was avoiding the trap of building another AI tool that simply tells users their idea is good.

We wanted the product behavior itself to demonstrate skepticism.

That meant designing a deterministic reasoning pipeline where a stakeholder perspective could challenge an assumption, the assumption could become a concrete failure point, and a changed condition could be tested again.

We also had to make the AI's limitations explicit. Simulated perspectives are hypotheses, not real user research or predictions. The final product therefore ends with questions for real-world validation instead of pretending that an AI simulation proves an idea will succeed.

What We Learned

We learned that an AI product can be more useful when it does not immediately agree with the user.

The most valuable output is sometimes not a new feature or a better idea—it is discovering that the original problem was being approached from the wrong angle.

We also learned the importance of making AI behavior inspectable. By structuring the reasoning into explicit stages and linking assumptions back to the scenarios that challenged them, BEFORE turns an abstract AI judgment into a story a builder can examine.

The Result

In our hero scenario, a student-arrival idea begins as:

“Remind students to leave earlier.”

BEFORE identifies the hidden assumption that lateness is primarily a time-management problem.

A simulated student perspective challenges it:

“I already leave early. The bus is unpredictable.”

A What If? test then asks what happens when the bus is delayed.

The original solution breaks.

BEFORE reframes the opportunity as:

Create an adaptive arrival system that accounts for transportation uncertainty.

The result is not simply a “better” version of the original idea.

The idea survived—but it changed.

Responsible AI

BEFORE uses AI-generated simulated perspectives to stress-test ideas. These are hypotheses, not predictions of how real people will behave.

BEFORE does not replace interviews, user research, accessibility testing, or domain expertise.

Its purpose is to help builders discover what they should validate before they build.

Built With

• ai
• artificial
• css3
• fastapi
• generative
• html5
• intelligence
• javascript
• pydantic
• pytest
• python
• uvicorn