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. VISION exists to close that gap: don't let a good idea die just because nobody saw it.

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."

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. Investors and companies get dedicated dashboards to discover projects, and can message builders directly or in group project chats with replies, reactions, starred messages, forwarding, file/image attachments, typing indicators, and blocking, i.e. a full modern chat experience, not just a basic inbox. A reputation system tracks engagement and awards visible rank badges as users level up, with a notification firing the moment someone earns a new one. A built-in notification center covers messages, engagement, collaboration, profile views, and achievements with cooldowns so the same action never spams the same person twice. VISION AI is woven through almost every part of the product (see below) from improving a pitch while you're still typing it, to matching a project with the right investors, to running the entire negotiation of a real investment/partnership deal.

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 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: ~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 like _project_card.html, _sidebar.html, _topbar.html, _reputation.html, _icons.html, and _modals.html composed into role-specific pages), layered with vanilla JavaScript (main.js, deal-room.js, vision-ai.js) and hand-written CSS (style.css plus feature-specific stylesheets for chat and the deal room) no frontend framework, everything is deliberately dependency-light so it's easy to reason about and fast to load. AI: Groq's OpenAI-compatible API running openai/gpt-oss-120b, wrapped in a single service module (vision_ai.py) that every AI feature in the app calls through so the API key, prompt formatting, and error handling live in exactly one place. 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 the database itself is safe on Render Postgres and that fixing it for real means moving uploads to a persistent disk or object storage (S3-style), 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. Long-lived worker processes occasionally got handed a connection Render had already closed, surfacing as an opaque SSL connection has been closed unexpectedly error. We fixed this with pool_pre_ping=True and a pool_recycle shorter than Render's idle timeout. Getting reliable structured output from an LLM. openai/gpt-oss-120b is a reasoning model it spends part of its token budget "thinking" before writing an answer, which meant JSON responses (used for almost every AI feature's structured output strengths/weaknesses lists, risk cards, fairness scores) would sometimes get cut off mid-object and rejected outright by Groq's strict JSON validator. We built a real recovery pipeline for this: request a lower reasoning effort specifically for JSON calls, give JSON calls a larger token budget than plain chat, attempt to extract and repair the truncated JSON (closing whatever brackets/quotes were left open, in the correct order) before ever giving up, and retry once with a bigger budget if repair fails. The model didn't always follow its own schema. Even with a valid JSON object back, fields that were supposed to be arrays of strings sometimes arrived as a single string of comma-separated quoted fragments, or with duplicate keys differing only in casing (suggestions vs Suggestions). We wrote a sanitation layer that normalizes every AI response before it reaches the frontend, so the UI can always trust that a "list" field really is a list.

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/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 (explain, simplify, rewrite founder-friendly or investor-friendly, propose a counter-offer, check fairness), an AI-generated fairness score with a full breakdown (equity, control, financial risk, founder protection, investor protection, exit fairness, legal completeness), a version history of every round of negotiation with an AI-written summary of what changed between rounds, and a signing step all wrapped in a clear "this is a draft to help two parties talk, not legal advice" disclaimer baked directly into every prompt so the AI never oversells itself as legal counsel. We engineered real reliability around a non-deterministic AI backend instead of hoping it behaves the JSON repair/retry pipeline and response sanitation described above turned "the model sometimes returns garbage" from a crash into a non-issue for the end user. Every password in the system account logins and a project owner's optional "make this project's details password-protected" feature is properly hashed, never stored or compared in plain text.

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 assume it can be malformed and build for that from day one, rather than bolting on try/except after something already broke in production. Infrastructure quirks bite you exactly once, in production, at the worst timenthe Render postgres:// scheme and idle-connection issues never showed up locally; they only appeared after deployment, which taught us to actually read the hosting provider's docs instead of assuming "it worked in dev" is good enough. A single point of integration pays off. 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 15+ AI features on the platform benefited immediately we didn't have to hunt down and patch a dozen separate call sites. Trust and safety language has to live in the prompt, not just the UI. Especially for the Deal Room, we learned that 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.

What's next for VISION

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 /api/vision-ai and Deal Room AI 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 (reactions, typing, stars, forwarding) is already this deep.

Long-term Turn the Deal Room into an actual end-to-end path from discovery → conversation → negotiated agreement → 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.