VISION

Inspiration

Every year, students, especially in places like Africa, pour months into a final-year project, submit it, and then watch it disappear into a drawer. The idea might be genuinely good. It might even be commercially viable. But there's no bridge between "I built this" and "someone who could fund, hire, or partner with me saw this." That gap isn't unique to students. Early-stage developers, researchers, and first-time founders everywhere build things nobody ever sees, not because the ideas are bad, but because visibility, connections, and access to the right people are unevenly distributed. On the other side, investors and companies are constantly looking for new ideas outside their existing networks and don't have a reliable place to find them at the earliest stage. We also kept coming back to a second, related frustration: even when a builder does find an interested investor or company, the next step, actually negotiating terms, is intimidating, opaque, and usually requires a lawyer neither side can afford yet. A first-time founder has no idea whether 8% equity with a board seat is normal or predatory. That gap between "we're interested" and "we have a fair, signed agreement" kills deals just as often as the discovery gap does. VISION exists to close both gaps at once. Don't let a good idea die just because nobody saw it, and don't let a good deal die just because nobody could tell if it was fair.

What it does

VISION is a social platform for projects and innovation. It's built around three account types: builders, investors, and companies, and everything on the platform is designed to move a project from "nobody knows this exists" to "someone who can help just found it," all the way through to a signed agreement.

The social/discovery layer:

Builders create a public profile (bio, country, languages known, software/hardware focus) and post projects at any stage: idea, prototype, in development, or live, with a cover image, demo video, GitHub/live links, and an honest account of what's working and what they're stuck on. Projects can be liked, commented on (with threaded replies), and saved, discovered through a browse/feed system, and gated as public, role-restricted, or password-protected for sensitive early-stage details. Anyone can apply to collaborate on an open project; owners accept or decline applicants and manage a capped team, with four explicit states handled (pending, accepted, declined, slots full). A transparent reputation system ranks builders by total project likes, investors by engagement and real collaboration/funding milestones, and companies by points and verified partnerships, with a public badges guide and a visible progress bar so nobody is guessing how to level up. A full messaging system supports 1:1 and group/team chats, replies, reactions, message starring, forwarding, file/image attachments, typing indicators, in-conversation search, and blocking. This is a genuinely complete chat product, not a stub inbox. A notification center covers messages, engagement, collaboration, profile views, and achievements, with cooldowns so no single action ever spams the same person twice.

The AI layer, VISION AI, powered by Groq running openai/gpt-oss-120b, is woven through every role on the platform, not bolted onto one page:

For Builders: Supercharge Pitch improves a project's overview live, while it's still being typed, before it's even saved. Project Review returns structured strengths, weaknesses, and missing-info feedback on a published project. Startup Roadmap generates an MVP to beta to launch plan. Risk Analysis surfaces critical, market, execution, and legal risks with de-risking steps. Scale Plan produces growth levers and milestones. Startup Score gives an instant scored assessment. Pitch Practice simulates a live investor Q&A so founders can rehearse. Weekly Advisor sends personalized weekly recommendations. AI Find Investors ranks real investor and company accounts already on the platform against a specific project; the AI ranks candidates, and the app attaches their real avatar, name, and reputation afterward, so the model never invents a user. AI Co-Founder is free-form startup chat grounded in one project's real details.

For Investors: Investment Analysis gives an investor-facing read on a project's investability. Due Diligence Questions generates the specific questions to ask before committing. Compare Startups runs a real side-by-side AI comparison across 2 to 4 projects an investor selects.

For Companies: Partnership Suggestions ranks live public projects as partnership or acquisition candidates. Outreach Writer drafts a company's first message to a specific builder, grounded in that builder's actual project.

Inside Messaging: tag @VISIONAI in any direct message or team chat, and VISION AI joins that conversation as a real participant, replying in-thread grounded in the last 8 messages of actual context. This is surfaced deliberately, with the chat composer's own placeholder text telling users "@VISIONAI to bring in the copilot."

Inside the Deal Room, the feature we're proudest of and the strongest proof AI is central to this product rather than decorative: a step-by-step wizard captures real deal terms (deal type, equity/investment amount, milestones, roles), and AI drafts a full section-by-section legal-style agreement from them. AI then produces a 0 to 100 fairness score with a 7-part breakdown (equity, control, financial risk, founder protection, investor protection, exit fairness, legal completeness) plus explicit "good for you," "warning," and "missing clause" lists. This is a structured, decision-relevant output that directly informs whether a founder should sign, push back, or walk away. Per-clause AI actions let either party explain, simplify, rewrite founder-friendly or investor-friendly, propose a counter-offer, or check fairness on any single clause mid-negotiation. Every new negotiation round gets an AI-written plain-English summary of exactly what changed from the last one. An AI Investment Proposal Writer turns a founder's raw funding ask into a polished, ready-to-send chat message. Once both sides are happy, the deal can be signed and exported as a clean, printable contract document, complete with signature blocks, the fairness score restated at the bottom, and a hard-coded disclaimer that it's a draft to help two parties talk, not legal advice.

How we built it

Backend: Python + Flask, with SQLAlchemy as the ORM (database.py holds a single shared db instance so every module imports the same one). Authentication uses Flask-Login, and every password, both user login and a project's optional "private view" password, is salted and hashed with Werkzeug's generate_password_hash/check_password_hash; nothing is ever stored in plain text. Database: SQLite locally, PostgreSQL in production. config.py reads Render's DATABASE_URL and transparently rewrites the legacy postgres:// scheme to the postgresql:// scheme SQLAlchemy 1.4+ requires, and sets pool_pre_ping/pool_recycle so long-lived gunicorn workers don't hand back a connection Render's Postgres has already dropped. Data model: roughly 18 tables covering users and role-specific profiles (Builder/Investor/Company), projects and screenshots, likes/comments/saves, collaboration requests, conversations/members/messages/reactions/stars/blocks, a full Deal/DealVersion/DealActivity schema for negotiations, and notifications. Frontend: Server-rendered HTML via Flask's Jinja2 templating (base.html as the shared shell, with reusable macros for the sidebar, topbar, project cards, reputation badges, and modals composed into role-specific pages), layered with vanilla JavaScript (main.js, deal-room.js, vision-ai.js) and hand-written CSS. There's no frontend framework; everything is deliberately dependency-light so it's easy to reason about and fast to load. The whole shell is mobile-considered too: a collapsible sidebar plus a bottom nav bar and hamburger overlay on small screens, not a desktop-only demo. AI: Groq's OpenAI-compatible API running openai/gpt-oss-120b, wrapped in a single service module (vision_ai.py) that every one of our 17+ AI features calls through, so the API key, prompt formatting, and error handling live in exactly one place instead of being duplicated across every feature. AI reliability engineering: openai/gpt-oss-120b is a reasoning model. Part of its token budget goes to internal reasoning before it writes the actual answer, which occasionally truncated JSON responses mid-object and got them rejected outright by Groq's strict validator. We built a real recovery pipeline: request lower reasoning effort specifically for JSON calls to leave more budget for output, give JSON calls a bigger token budget than plain chat, attempt to repair truncated JSON by closing whatever brackets and quotes were left open in the correct order, and retry once with a larger budget before giving up. We also normalize every parsed AI response afterward, deduplicating case-variant JSON keys (suggestions vs Suggestions) and coercing fields that arrived as a single comma-separated string back into real arrays, so the frontend can always trust the shape of what it receives. File handling: profile pictures, project cover images/screenshots, demo videos, and chat attachments are validated by extension and size (64MB cap) and stored under static/uploads in dedicated subfolders.

Challenges we ran into

Ephemeral filesystem storage on Render. The app stores uploaded images/videos in the project's own static/uploads folder, which works perfectly in local development. On Render, the filesystem isn't persistent across deploys/restarts, so anything a user uploaded could vanish on the next redeploy. We learned this only affects file storage, not the database, since the database itself is safe on Render Postgres. Fixing it for real means moving uploads to a persistent disk or object storage, which is on our immediate roadmap. The Postgres URL scheme mismatch. Render hands out database URLs with the old postgres:// prefix, but modern SQLAlchemy/psycopg2 require postgresql://. Without the rewrite in config.py, the app would crash on every deploy despite working fine locally against SQLite. Postgres dropping idle connections, surfacing as an opaque "SSL connection has been closed unexpectedly" error on long-lived workers. Fixed with pool_pre_ping=True and a pool_recycle shorter than Render's idle timeout. Getting reliable structured output from a reasoning-model LLM. Almost every AI feature on the platform, and every single feature inside the Deal Room specifically, depends on the model returning valid JSON (a fairness score, a list of clauses, strengths/weaknesses). When Groq's validator rejected a truncated response outright, the feature would just fail. We built the JSON repair/retry/sanitize pipeline described above specifically to solve this, and it now protects all 17+ AI features from the same class of failure. Deployment environment drift, late in the process. Getting from a working local build to a working Render deploy surfaced a chain of real issues one after another: a duplicated, conflicting line in requirements.txt; Render defaulting to a brand-new Python version whose C-extension ABI broke our Postgres driver; an outdated Groq SDK that didn't support the reasoning_effort parameter our own reliability pipeline depends on; and an internal-only Postgres hostname that only resolves from inside Render's private network. Each one taught us to actually read the hosting provider's docs and pin our dependency versions explicitly, rather than assuming "it worked in dev" is good enough.

Accomplishments that we're proud of

We didn't build "AI wrapped around a to-do list." We built a real social platform first (auth, profiles, a feed, likes/comments/saves, team collaboration, a full messaging system with reactions, replies, attachments, typing indicators, and blocking) and then made AI a first-class citizen inside it, including as an actual participant in chat threads via an @VISIONAI mention. The Deal Room is the feature we're most proud of. It takes a startup negotiation (equity, roles, milestones) and turns it into an AI-drafted agreement, with per-clause AI actions, an AI-generated fairness score with a full 7-part breakdown, a version history of every negotiation round with an AI-written summary of what changed, and a signing step with a printable exported contract. All of it is wrapped in a "this is a draft to help two parties talk, not legal advice" disclaimer baked directly into every prompt. We engineered real reliability around a non-deterministic AI backend instead of hoping it behaves. The JSON repair/retry pipeline and response sanitation turned "the model sometimes returns garbage" from a potential crash into a non-issue for the end user, across every single AI feature at once, because they all route through one service module. Every password in the system, both account logins and a project owner's optional password-protected project details, is properly hashed, never stored or compared in plain text. We shipped a genuinely transparent reputation system (public rank ladder, visible progress bar, clear per-role criteria) instead of a black-box score nobody can act on.

What we learned

Treat an LLM's output like untrusted user input, not a function return value. We learned to validate, repair, and sanitize AI JSON the same way you'd sanitize a form submission, assuming it can be malformed and building for that from day one, rather than bolting on error handling after something already broke in production. Infrastructure quirks bite you exactly once, in production, at the worst time. The Render postgres:// scheme, idle-connection drops, Python-version ABI mismatches, and internal-hostname resolution never showed up locally; they only appeared after deployment, which taught us to actually read the hosting provider's docs instead of assuming dev-environment success is good enough. A single point of integration for a third-party API pays off immediately. Routing every AI call through one vision_ai.py module meant that when we discovered the JSON-truncation problem, we fixed it once and every one of the 17+ AI features on the platform benefited immediately. Trust and safety language has to live in the prompt, not just the UI. Especially for the Deal Room, a disclaimer shown once in the interface isn't enough. The "this isn't legal advice, never invent numbers" instruction has to be repeated inside every single prompt that touches contract terms, because that's the only guarantee the model actually respects it. Dependency pinning is not optional once you deploy. A single duplicated line in requirements.txt, or an unpinned transitive dependency like httpx, was enough to break the entire build. We now treat every version number in that file as a deliberate decision, not a "whatever pip grabs" afterthought.

What's next for Untitled

Immediate

Move file uploads (profile pictures, project media, chat attachments) off the local filesystem and onto persistent/object storage so nothing is lost on redeploy. Add automated tests around the AI JSON-repair pipeline and the Deal Room's negotiation state machine, since those are the parts of the app with the most edge cases. Tighten rate limiting on the AI and Deal Room endpoints so one user can't burn the whole team's Groq quota.

Short-term

Let builders link a verified GitHub/portfolio to auto-populate a project instead of manual entry. Expand the reputation system into a public leaderboard/discovery signal investors and companies can filter by. Real-time messaging (WebSockets) instead of polling, now that the chat feature set is already this deep.

Long-term

Turn the Deal Room into an actual end-to-end path from discovery to conversation to negotiated agreement to funded/partnered, potentially integrating real e-signature and payment/escrow providers behind the existing AI-drafted-agreement flow. Open a public API so universities and hackathon organizers can pipe final-year/capstone projects directly into VISION instead of letting them die in a submission folder. Grow VISION into the actual bridge it was designed to be, between innovators, companies, and investors, beyond the hackathon.

Built With

• css3
• flask
• flask-login
• flask-sqlalchemy
• gunicorn
• html5
• javascript
• jinja
• llm
• openai-api-compatible
• postgresql
• python
• sqlalchemy
• websockets