Euboulia

Inspiration

The idea came from a feeling we kept having while building our own MVPs.

We would be moving quickly with AI coding tools. A feature would ship in an afternoon, and then we would pause and realize we had no clear idea what we had just built from a responsibility standpoint. A file upload feature was suddenly storing documents in a cloud bucket. An analytics SDK was sending user behavior somewhere whose terms we had not read. An AI provider was receiving data we had not thought carefully about.

We were not being careless. We simply had no system for thinking through these choices. Technical decisions were happening faster than our understanding of their consequences.

We started asking other founders and heard the same concern. People were using AI coding tools to build products that collect personal data, call third-party AI providers, store uploaded files, and make implicit promises to users, often without stopping to consider what those choices mean for the people using the product.

Existing tools either skipped the question or buried the answer in legal language that a solo founder may not understand or have time to research. We wanted a middle ground: a tool that could reason through the consequences of a specific product decision in plain language, ground important claims in authoritative sources, and still leave the founder in control.

That gap is what Euboulia is built to close.

What it does

Euboulia ( ancient Greek for “good deliberation” reasoning well about what to do before acting) helps student and solo first-time founders turn an early product idea into a responsibility-aware implementation plan. It surfaces privacy, legal, ethical, reliability, and trust consequences before those consequences are hidden inside shipped features.

A founder begins by describing the product in plain language. Euboulia converts that description into a structured responsibility model covering users, features, data flows, collected data, third-party providers, founder concerns, and unresolved questions. Each item is labelled as a founder-confirmed fact, an AI inference, missing information, or a decision that requires the founder's attention.

The founder reviews and corrects this model before it becomes persistent product memory. This prevents an AI assumption from silently becoming a product fact.

The Product Map then acts as a living implementation plan. It connects product features to unresolved questions, alternative implementation paths, technical requirements, founder decisions, next actions, and later code-change evidence.

Euboulia identifies the responsibility decisions hidden inside ordinary technical choices. Adding a file upload is not only an engineering task. It creates decisions about necessity, retention, deletion, third-party processing, user disclosure, access, and trust. Adding an analytics SDK may create a new data flow involving user identifiers, sensitive behavior, external retention, or advertising use that the founder did not intend.

For each material decision, the system retrieves relevant official guidance and provider documentation. It then presents several implementation paths and explains their privacy, legal or compliance-relevant considerations, trust and reliability requirements, technical effort, user impact, and unresolved uncertainty. The founder chooses the path. The AI does not.

After the discussion, Euboulia drafts a structured decision record containing the proposed path, rationale, accepted tradeoff, assumptions, unresolved questions, and revisit conditions. The founder can edit, reject, or explicitly confirm that record before it becomes persistent product memory.

When the founder reviews a GitHub push, Euboulia uses two complementary layers. Rule-based checks detect explicit technical signals such as storage operations, analytics dependencies, personal-data fields, or removed deletion logic. A semantic LLM pass independently examines the changed code and its context for implications that fixed rules may miss. The system merges the findings, labels each one by origin, and compares them with the founder's recorded decisions. A push may therefore produce no rule-based signal while still producing an AI-identified concern. Any possible conflict is presented as a review for the founder, not as a verdict.

The complete flow is:

Idea -> responsibility model -> Product Map and implementation plan -> evidence-backed paths -> founder-confirmed decision -> technical guardrails and next actions -> rule-based and semantic GitHub review -> founder action.

How we built it

Euboulia was built during the hackathon window using Lovable as the primary development environment and Gemini Flash through its API. Lovable accelerated implementation, while the team designed the product workflow, system architecture, prompts, structured outputs, responsibility model, and human decision points.

The system combines a structured Product Map, a bounded retrieval corpus, decision records, a Responsibility Coverage Ledger, uncertainty controls, and GitHub change-impact review.

The retrieval layer uses a bounded collection of official regulatory, enforcement, framework, and provider sources. Each source is stored with metadata and connected to the Product Map node or decision it informed. The source and its relationship to the finding are visible in the Resources tab. Retrieval supports the analysis, but the presence of a source does not by itself prove that it applies to the founder's situation.

The current MVP reviews individual GitHub pushes against recorded decisions. Rule-based checks detect explicit code patterns, while a semantic LLM pass can identify contextual implications outside the fixed rule set. The impact-reasoning stage receives only the reviewed change and the relevant product context; it does not assume that a single push represents the complete application.

Why an LLM and not only a rules engine

A rule can detect that the word "personalize" appears in a product description. It cannot reliably determine whether that means filtering by subject area, behavioral tracking, profiling based on sensitive information, or predicting a student's likelihood of acceptance. The consequences differ substantially even though the same word is used.

The LLM interprets incomplete product descriptions, asks contextual follow-up questions, compares founder statements with code evidence, generates alternatives that preserve the founder's goal, and explains multidimensional tradeoffs. Rule-based checks remain useful for explicit technical observations. The LLM handles context and ambiguity that those rules cannot represent.

Challenges we ran into

The false-confidence problem

Because Euboulia discusses privacy and legal consequences, an inexperienced founder could interpret a polished analysis, or the absence of a warning, as proof that the product is safe to launch.

We designed against this in several ways. The Responsibility Coverage Ledger shows what was reviewed, what remains unresolved, and what was not reviewed. The uncertainty gate prevents strong conclusions when essential context is missing. Important outputs distinguish founder-confirmed facts, rule-based observations, retrieved sources, AI interpretations, missing information, and unreviewed scope.

The system's strongest positive conclusion is deliberately limited:

"No additional concerns were detected within the reviewed scope. Some categories remain incomplete or unresolved."

Euboulia does not label a product compliant, legally approved, safe, or risk-free.

Keeping the LLM grounded

Legal and provider-policy claims need more than a plausible explanation. Important claims must point to a retrieved authoritative source and explain why that source may be relevant to the product context. Unsupported interpretations are labelled as unverified, converted into clarification questions, or escalated for qualified human review.

If sources conflict, appear outdated, or do not clearly apply to the founder's jurisdiction and situation, Euboulia displays that uncertainty instead of choosing one interpretation as fact.

Defining the scope

Euboulia is not a general startup adviser and does not decide whether a feature is commercially valuable. Its role is narrower: help a founder understand responsibility consequences, compare feasible implementation paths, record a decision, and notice when implementation may drift from that decision.

Accomplishments that we're proud of

The design decision we are most proud of is simple: the founder always makes the final choice.

The AI presents paths, consequences, tradeoffs, evidence, and uncertainty. It may explain which path appears more consistent with the founder's stated goal and constraints, but it never selects or implements a path automatically. It also never certifies a decision as legally correct.

This is deliberate. There is no universally correct implementation for every privacy or trust decision. The appropriate choice depends on facts the AI may not know, including jurisdiction, users, risk tolerance, available resources, technical constraints, and the founder's goals. The founder is accountable for the product, so the decision must remain theirs.

We are also proud of the structured decision record. Euboulia drafts the rationale, accepted tradeoff, assumptions, and revisit conditions from the discussion, but the founder must review and confirm the record before it becomes part of the Product Map.

The Resources tab makes the evidence traceable. Founders can see the source behind an important claim and the node or decision it informed, rather than receiving an answer with no visible basis.

The name also matters to us. Euboulia is an ancient Greek term for good deliberation: the ability to reason well about what to do before acting. That is the behavior we wanted the product to support.

What we learned

We learned that the hardest part of building this system was making uncertainty visible without making the product unusable.

Every choice that made the system more honest about its limits added friction. Every choice that removed friction risked creating false confidence. The Responsibility Coverage Ledger, uncertainty controls, evidence labels, and dimensional confidence model came from working through that tension.

We also learned that rules and an LLM should have different responsibilities. Rules are useful for explicit, repeatable technical signals. The semantic pass interprets those signals in product context and can identify implications that no fixed rule covers. Keeping their outputs separate makes the reasoning easier to inspect.

Finally, calling the founder's action a decision changed how we designed the product. A decision has a reason, an accepted tradeoff, assumptions, and a condition for revisiting it. That framing shaped the Product Map, the consultant conversation, and the GitHub review flow.

What's next for Euboulia

The immediate priority is improving source coverage and freshness. The current MVP uses a limited set of official U.S., EU, framework, enforcement, and provider sources. Future versions will add more provider policies, terms, data-processing documentation, and guidance for additional jurisdictions.

We also want to record when each source was published, retrieved, and last verified, and flag material that may have been superseded.

Beyond retrieval, we want to deepen the GitHub integration. The current system reviews individual pushes against confirmed decisions. A future version could detect cumulative drift, where several individually small changes collectively move the implementation away from the founder's recorded plan.

Longer term, Euboulia should follow a founder from idea through implementation inside the tools they already use. The goal is to make responsibility decisions part of building the product, rather than a separate review founders remember only after something goes wrong.

The name means good deliberation. We want founders to understand what they are choosing before they ship it.