The Open Source AI Platform for Funding & Business Consultants
OpenBcon helps consultants, advisors, incubators, and funding teams run the full workflow in one place:
- discover funding programs
- assess business readiness
- manage company and client records
- generate funding-ready business plans
- organize applications, templates, resources, and reports
Community edition:
AGPL-3.0-or-laterCommercial licensing available for private deployments, closed-source modifications, white-label/OEM distribution, implementation services, and ongoing support.
See COMMERCIAL-LICENSE.md and CLA.md.
Funding consultants and business advisors still spend too much time on repetitive work:
- searching and comparing grant or loan programs
- collecting company information from clients
- rewriting business plans and funding narratives
- tracking applications, deadlines, and next actions
- building reports and export packages manually
OpenBcon turns that fragmented process into one AI-assisted workspace.
OpenBcon is designed for teams that help businesses secure funding:
- funding consultants and grant writers
- business advisors and coaches
- incubators and accelerators
- economic development organizations
- partner networks, internal advisory teams, and multi-client workspaces
- AI business plan generation: turn company and funding-program context into a structured funding-ready package
- Configurable Advisory Hub: run section-by-section generation with admin-managed sections, document types, agents, roles, prompts, and ordering
- Funding readiness workflows: assess strengths, risks, and missing inputs before submission
- Client and company management: organize founder profiles, business details, and working records
- Funding program database: manage grants, loans, and opportunity sources in one directory
- Partner and admin workspace: configure modules, branding, landing-page content, legal links, data sources, models, payment settings, and workspace behavior
- Resource and template libraries: centralize templates, social resources, tools, and reusable content
- Google Sheets and Airtable integrations: connect external resource sources with admin-managed sync
- Open-source customization: self-host, extend, rebrand, or commercialize under the project's dual-license model
- Multilingual workspace UI: English (Canada), French (Canada), and Simplified Chinese locale support
The repository currently includes three product surfaces:
/- public landing page/dashboard- user workspace/admin- platform configuration console, including Advisory Hub setup
Every workspace module uses a flat route such as /funding-readiness, /quick-build, /advisory-hub, /my-applications, and /grants-loans.
Built-in auth entry flows are also included for /login, /signup, /forgot-password, and /reset-password.
Live demo and short product walkthroughs are planned. Until then, the repository includes a visual snapshot of the current product experience.
 Landing Page |
 Landing Page 2 |
 Dashboard Overview |
The current repository snapshot includes the landing experience, dashboard workspace, directories, and Quick Build flow.
 Funding Readiness |
 Quick Build |
 Quick Build - Result Preview |
 My Company |
 Saved Programs |
 My Applications |
 Grants & Loans |
 Templates |
 Social Resources |
 Tools |
 Settings |
 Admin Console |
- Responsive landing page and dashboard shell
- Mobile drawer navigation and collapsible sidebar groups
- Configurable branding, logo, and public messaging
- Admin-managed landing page header, content, footer navigation, and legal-link configuration
- Admin-managed pricing catalog with free, monthly, annual, and one-time offers
- Billing settings surface with current subscription, pricing options, and transaction history
- Module and Partner Portal feature flags
- Searchable and filterable listing views with record details
- Three-step Quick Build workflow with validation, company import, application restore, and generated previews
- Dedicated Advisory Hub route (
/advisory-hub) for reopening the latest generated package outside the form flow - Advisory Hub generation driven by configurable sections, document types, agents, roles, prompts, and workflow ordering
- Saved Programs materialized as applications with funding-program step data prefilled
- My Applications and Quick Build use the unique external
app_idin links and API requests - Google Sheets and Airtable funding data-source integrations
- Admin data-source search, create, edit, delete, enable, and manual sync controls
- Dynamic Grants & Loans directory with source attribution and Quick Build import
- PostgreSQL domain data plus MongoDB-backed dynamic configuration and workspace state
- One Strategic Report per application, persisted in
strategic_reportswith LangGraph trace and final result data - Three-year, 36-month financial forecasts with monthly revenue and expense rows, annual summaries, and Advisory Hub visualizations
- Database migrations, demo seed data, audit logs, and Docker Compose setup
- Route-specific titles, metadata, and a dedicated 404 page
- Vitest checks and a GitHub Actions verification workflow
- Dual-license foundation for open-source and commercial distribution
- React 19
- TypeScript
- Vite
- React Router
- Oxlint
- Express
- PostgreSQL 17
- MongoDB 8
- i18next and react-i18next
- Zod
npm install
npm run db:setup
npm run devOpen http://localhost:5173.
Copy .env.example to .env before changing database credentials or ports.
Start both database services before migrating state:
docker compose up -d postgres mongodb
npm run db:migrate-state-to-mongo
npm run db:migrate
npm run db:seednpm run db:setup runs the same migration and seed steps after the database
services are available. npm run dev starts the API on port 8787 and Vite on
port 5173.
For the Python AI backend used by the model connection chat, create the
Python environment described in python-backend/README.md, then run
npm run dev:python in a second terminal. It listens on port 8010.
If the browser shows a blank page immediately after renaming or moving a source
module, stop and restart npm run dev so Vite rebuilds its module graph. Then
reload the page. A successful npm run build confirms that the source imports
resolve correctly.
The workspace UI supports English (Canada), French (Canada), and Simplified Chinese. Change the language from Settings; the preference is persisted for the current browser profile and is used for workspace labels, dates, numbers, currency formatting, and generated forecast language.
The billing flow now supports Stripe Checkout and the Stripe customer portal.
- Copy
.env.exampleto.env. - Add your Stripe server credentials:
STRIPE_TEST_SECRET_KEYSTRIPE_LIVE_SECRET_KEYSTRIPE_WEBHOOK_SECRETAPP_STATE_ENCRYPTION_KEY
- Start the app with
npm run dev. - Open
/admin#paymentsand confirm these Stripe references:testSecretKeyReference->STRIPE_TEST_SECRET_KEYliveSecretKeyReference->STRIPE_LIVE_SECRET_KEYwebhookSecretReference->STRIPE_WEBHOOK_SECRET
- Save the Admin Console configuration in the browser. Platform settings now stay local-only and are not synchronized into PostgreSQL. Raw payment secrets are stored locally in encrypted browser storage rather than plaintext localStorage.
- In the Stripe Dashboard, register your webhook endpoint, for example:
http://localhost:8787/api/webhooks/stripe
If the checkout success, cancel, or billing-portal return URLs are left blank in
the Admin Console, the server automatically falls back to the current app origin
and routes users back to /settings#billing.
npm run dev
npm run build
npm run lint
npm run test
npm run check
npm run preview
npm run db:up
npm run db:migrate
npm run db:seed
npm run db:downQuick Build accepts the public application identifier and launches one Strategic Report for that application:
/quick-build?app_id=3a819e8f5ce9f1d8
The public generation API uses the same identifier:
POST http://localhost:8010/api/business-plan/generate
Content-Type: application/json
{"app_id":"3a819e8f5ce9f1d8","language":"en-CA"}The forecast-only endpoint is:
POST http://localhost:8010/api/business-plan/forecast
Content-Type: application/json
{"app_id":"3a819e8f5ce9f1d8","language":"en-CA"}The backend loads the application, company, and funding-program records from
PostgreSQL, then reads the current enabled Advisory Hub sections and assigned
agents from MongoDB. Sections are generated in the configured order using each
agent's current name, role, and prompt; there are no Python-side default section
values. The LangGraph run trace and final result are stored in the application's
single strategic_reports row.
The supported output languages are en-CA, fr-CA, and zh-CN. The selected
language is passed to LangGraph prompts and stored with the Strategic Report.
Users can change the workspace language from Settings. The choice is persisted
locally and also controls locale-aware number, date, currency, and forecast formatting.
The report page resolves that row from the application relationship, so the
navigation URL can be /advisory-hub?applicationId=<applications.id>; the
stored Strategic Report ID is displayed by the page and does not need to be
passed as a second query parameter.
Financial forecasting is part of the Strategic Report. By default it produces three years of monthly periods (36 columns), with revenue rows first, expense rows second, and calculated total revenue, total expenses, and net cash flow. Advisory Hub renders the forecast with trend charts, net-cash-flow bars, annual summaries, and the detailed monthly table.
src/
config/ Platform configuration and persistence
data/ Navigation and demo records
lib/ Domain and generation helpers
pages/ Landing, dashboard, and admin surfaces
persistence/ PostgreSQL synchronization and offline fallback
server/
db/ PostgreSQL pool, migrations, and seed data
app.ts API routes and validation
stateRepository.ts
The Admin Console now keeps platform settings in local browser storage only. Those settings are not synchronized to the API or PostgreSQL. Sensitive payment fields are stored in encrypted browser storage, while synced data-source records continue to use the API-backed persistence layer. The server validates a strict state-key allowlist so session tokens and local-only settings cannot be written to the state database.
Workspace settings such as the profile, billing selections, default company, and Quick Build preferences are persisted locally for the active browser session profile. Payment gateway secrets are never written back to the remote state store in plaintext.
Advisory Hub settings are also managed from the Admin Console and persisted with the platform configuration. Administrators can:
- enable, rename, and reorder the sections shown during package generation
- define the document types available to those sections
- add, remove, and edit Advisory Hub agents, including their names, roles, and prompts
- assign a document type and agent to each section
At least one section, one document type, and one agent remain available so the generation workflow always has a valid configuration.
The landing page can be managed directly from /admin#landing-page, including:
- header navigation items and signed-in or signed-out CTA labels
- grouped content sections for hero, CTA copy, features, workflow, and open-source messaging
- dynamic proof points shown on the public homepage
- footer sitemap links, platform links, and legal link destinations
Saved opportunities now bridge directly into the application workflow:
- saving a program can materialize a corresponding application record
- each application stores the Quick Build step-one funding context
/quick-build?app_id=...restores an existing application instead of starting a new one- the Step 2 business profile can automatically import the configured default company
- generated packages can be reopened later from the dedicated
/advisory-hubroute - each application maps to one Strategic Report through
strategic_reports.application_id
Payment settings under /admin#payments now focus on gateway configuration:
- Stripe and Waffo Pancake can each store separate test and live secret references
- environment-variable names remain visible as references
- raw payment keys are redacted in localStorage and stored in encrypted browser storage
- checkout success and cancel URLs can be overridden per deployment
- customer self-serve subscription changes use the Stripe billing portal
- webhook signature verification uses server environment variables rather than synced admin state
Stripe checkout remains the only live billing flow wired to the server today. Waffo Pancake is available in the Admin Console as a configurable gateway option for secret and mode management.
Before production deployment:
- Replace the demo auth flow and seeded development identity with production authentication and user provisioning.
- Add role-based authorization for founder, advisor, admin, and partner workflows.
- Add row-level workspace authorization before accepting user-supplied IDs.
- Keep production secrets in a secret manager and use Admin only for references or encrypted-at-rest secure storage.
- Configure TLS and a managed PostgreSQL backup policy.
PostgreSQL stores relational domain data, especially users, companies, funding
programs, applications, and strategic reports. Internal application relations
use the numeric applications.id, while external generation calls use the
unique 16-character applications.app_id.
MongoDB stores editable dynamic JSON configuration and lightweight workspace state
in the dynamic_state collection using three scopes:
platformfor branding, landing-page content, modules, AI/payment configuration, and data sourcesworkspacefor saved-program preferences and Quick Build draftsuserfor personal settings, pinned resources, and active workspace selection
Sensitive payment keys inside bconomics-platform-config-v1 are not returned to
the browser in plaintext. The API redacts them in bootstrap payloads, encrypts
raw values before saving them to MongoDB, and decrypts them only for
server-side payment operations.
On first migration, existing app_state JSON documents are copied to MongoDB.
The PostgreSQL app_state table is no longer used. On later visits, MongoDB and
the relational applications table are loaded before the React application mounts.
Mutations are debounced and written in batches, and every mutation creates an audit
record in PostgreSQL.
See docs/DATABASE.md for the schema, API contract, deployment guidance, and migration path toward fully normalized domain tables.
This repository is currently a development/demo workspace. The visible login pages are present, but server-side authentication and workspace authorization are not implemented yet; API routes currently use the configured demo user and workspace context. Do not expose the Node API, Python AI API, PostgreSQL, MongoDB, payment routes, or model endpoints publicly until authentication, authorization, production CORS, secret management, TLS, and database network controls are configured.
Keep .env and provider keys out of Git. Use a secret manager in production and
never place raw AI or payment credentials in frontend configuration. Review and
back up the database before applying destructive historical migrations, including
the migration that removes the legacy funding-package tables.
Open /admin#data-sources to manage the sources that populate Grants & Loans,
Templates, Social Resources, and Tools. Administrators can search and filter by
module, change a source's destination, enable or disable it, and run a manual sync.
Synchronized records are cached locally in the demo and become available in their
selected workspace module.
Supported columns are:
Program Name, Type, Provider, Amount, Deadline, Match, URL, Location
Common alternatives such as Name, Agency, Maximum Amount, Closing Date,
and Region are mapped automatically.
Templates, Social Resources, and Tools use:
Title, Description, Category, Status, URL, Updated
Alternatives such as Name, Summary, Format, Channel, Link, and
Last Updated are also recognized.
Paste a public or link-readable Google Sheets URL and optionally provide the sheet tab name. The frontend converts the sharing URL to CSV and imports the rows. The included funding, template, and tools CSV files can be used to test the sync flow without an external account.
Airtable synchronization uses a server-side proxy so the personal access token is never stored in the browser. Configure the base ID, table, view, proxy URL, and environment-variable name in Admin.
The integration proxy receives:
{
"provider": "airtable",
"baseId": "appXXXXXXXXXXXXXX",
"tableName": "Funding Programs",
"view": "Published",
"credentialReference": "AIRTABLE_ACCESS_TOKEN"
}It should return either an array of field objects or the Airtable-style shape:
{
"records": [
{
"fields": {
"Program Name": "Community Growth Loan",
"Type": "Loan",
"Amount": 50000
}
}
]
}Protect the proxy with administrator authorization, validate the requested base and table against an allowlist, and read the Airtable token from server-side environment variables.
OpenBcon uses a dual-license structure:
- Community edition:
AGPL-3.0-or-later - Commercial edition: available by separate paid agreement
The commercial edition is intended for customers that need:
- proprietary or closed-source deployment rights
- private modifications without AGPL disclosure obligations
- white-label, OEM, or embedded distribution rights
- paid implementation, customization, or ongoing support
In the community edition, OpenBcon attribution in the landing page and dashboard footer is required. Commercial license holders can negotiate white-label controls, including whether that attribution is visible.
See COMMERCIAL-LICENSE.md for the commercial licensing model and CLA.md for the contributor agreement required for external contributions.
git init
git add .
git commit -m "Initial open source release"
git branch -M main
git remote add origin <your-repository-url>
git push -u origin mainDo not commit production credentials, customer data, generated documents, or third-party assets that you do not have the right to redistribute.