DEV Community

Felipe Rodriguez
Felipe Rodriguez

Posted on

How I built an AI tool to stop guessing software architecture from bad requirements

Hey everyone! ๐Ÿ‘‹

We've all been there.

A client, stakeholder, or product manager hands you a two-paragraph document or a chaotic PDF and says:

"We need this system. Can you give us the technical estimation and architecture by tomorrow?"

Then comes the uncomfortable part: trying to understand the real scope, identifying the entities, figuring out the relationships, spotting missing rules, thinking about APIs, risks, data structures, and all the assumptions that were never written down.

I got tired of that "improvisation phase", so I built Noesor.

๐Ÿง  What is Noesor?

Noesor is a software engineering platform that transforms software requirements into a clearer technical foundation before development begins.

You can paste a requirement or upload a document, and Noesor analyzes the information to help you better understand the system before making technical decisions.

The goal is not to replace architects, developers, analysts, or technical teams.

The goal is to reduce ambiguity and give them a better starting point.

๐Ÿ› ๏ธ What does Noesor help you identify?

From a software requirement, Noesor can help structure and analyze areas such as:

  1. Requirements & Functional Structure

    Organizes the information in the requirement and helps identify the main functional elements, actors, rules, and relevant parts of the system.

  2. Entities & Relationships

    Identifies important business entities and the relationships between them, helping create a clearer view of the domain.

  3. Data Models

    Helps transform the analyzed information into a more structured foundation for understanding how the system's data should be organized.

  4. Architecture

    Provides technical information that helps teams reason about the structure of the solution based on the requirements that were actually provided.

  5. APIs & Technical Definition

    Helps identify and structure interfaces and technical elements that may be required to continue designing and developing the system.

  6. โš ๏ธ Risks, Gaps & Ambiguities

    Highlights missing information, contradictions, assumptions, unclear business rules, and points that should be clarified before implementation.

  7. Technical Documentation

    Organizes the analysis into technical artifacts that can help developers, analysts, architects, and technical leads continue working on the project with more context.

๐Ÿ’ก Why does this matter?

Many software problems don't start in the code.

They start earlier.

A requirement can look simple and still hide important questions:

  • What happens when a process fails?
  • Which business rules are missing?
  • Which entities are actually involved?
  • How are they related?
  • What information needs to be persisted?
  • Which integrations might be required?
  • Which assumptions are being made without anyone noticing?
  • What should be clarified before development begins?

Noesor is designed to help surface those questions earlier.

The idea is simple:

Understand better before you build.

๐Ÿš€ No Registration Needed โ€“ Try it right now

I wanted the first experience to have as little friction as possible.

You can try Noesor directly from the website without creating an account first.

Free without registration

Paste a software requirement or upload a supported document and explore the first analysis directly from the site.

Registered Free

If the first results are useful, you can create an account and continue working with saved projects and extended analysis.

Pro

For users who need the complete set of engineering tools, deeper analysis, project capabilities, technical outputs, and advanced features.

๐Ÿงช A simple example

Imagine receiving this requirement:

"We need a platform where users can book professional services, pay online, cancel appointments, and receive notifications."

It sounds simple.

But before building anything, a technical team may need to clarify:

  • What types of users exist?
  • How are providers and customers related?
  • What is the booking lifecycle?
  • What happens after a cancellation?
  • Are refunds automatic?
  • How is availability managed?
  • Can two users book the same slot?
  • Which payment events must be tracked?
  • What notifications are required?
  • What happens when an external service fails?

That is the kind of uncertainty Noesor is intended to help expose and organize before development starts.

๐Ÿ’ฌ I want real engineering feedback

I originally built Noesor around a problem I kept seeing in software projects: teams being forced to make technical decisions from incomplete or ambiguous requirements.

Now I want to see how useful it is for other developers, architects, analysts, and technical leads.

If you work with software requirements, I'd love for you to try it with a real example and tell me:

  • Did the analysis help you understand the project better?
  • Did it identify useful entities and relationships?
  • Did it surface risks or ambiguities you hadn't noticed?
  • Which technical outputs were most useful?
  • What would you improve?
  • What would you expect a tool like this to provide next?

You can try it here:

https://noesor.com

No registration is required for the first experience.

Feedback, criticism, feature requests, and technical opinions are all welcome.

Thanks for reading! ๐Ÿ‘‹
Go to noesor.com, throw your most chaotic, poorly written requirement at it, and tell me:

  • Did it catch the hidden technical risks?
  • Were the generated database entities accurate?
  • What other technical metrics or diagram formats (like Mermaid code) would you like it to output?

Drop your thoughts, feedback, or roast in the comments below! ๐Ÿ‘‡

Top comments (0)