One database
172 tables, all linked. Projects connect to finance. Finance connects to procurement. Procurement connects to vendors. HR connects to projects. CRM connects to customer success. Every foreign key is a real relational link.
The Platform
One place where
the business actually runs.
YBNW One is a database-first business management platform. Not a bundle of apps glued together. A single Postgres-backed workspace where every department — projects, finance, HR, procurement, CRM, governance, documents, operations — reads and writes from the same data layer.
160+ modules
172 database tables
795 permissions
12 role types
One workspace subscription
The Problem With SaaS Sprawl
Most companies have not outgrown their tools. Their tools have outgrown each other.
The modern software stack for a 50-person company typically involves eight to fifteen separate SaaS subscriptions. Each one solves a department-level problem. None of them know what the others are doing. The result is not operational clarity — it is operational friction that compounds with every new hire, every new tool, and every new reporting requirement.
01
Data lives in the wrong place
When a project goes over budget, the information that explains why is spread across a project tool, an accounting system, a procurement inbox, and a spreadsheet someone built last quarter. Pulling a coherent answer requires manual work that nobody has time for. The business makes decisions on incomplete information because assembling complete information is too slow.
02
Seat pricing punishes collaboration
Per-seat pricing forces managers to decide who deserves access before work can move. The finance manager cannot see the project status unless someone pays for a seat. The project manager cannot see the invoice because that is in a separate Finance module. The result is email threads, exported CSVs, and informal workarounds — exactly the kind of information leakage that creates compliance risk and slows decisions.
03
Reporting becomes a second job
Building a board-level report from five disconnected systems means someone has to manually pull data from each one, reconcile the inevitable disagreements between them, and hope nothing changed while they were exporting. Monthly reporting in most growing businesses takes two to five days of senior staff time — not because the data is complicated, but because it lives in the wrong places.
04
Security multiplies with every new tool
Each new SaaS subscription is a new access control model to configure, a new permission system to audit, a new place where an offboarded employee might still have access, and a new vendor relationship to include in your risk register. For regulated industries, this is not a convenience problem — it is a compliance problem that grows exponentially with each additional tool in the stack.
05
Context is lost between handoffs
When a sales deal closes and moves from CRM to project delivery, the context from the sales process — the customer's constraints, the pricing commitments, the delivery promises — needs to be manually transferred. When a vendor contract moves from legal to procurement to accounts payable, the contract terms need to be re-entered. Every handoff between systems is a point where information degrades and errors multiply.
06
Integrations are a maintenance burden
The standard response to tool fragmentation is integration — Zapier connections, API bridges, middleware services. But integrations fail silently, require maintenance, create version skew, and still do not give you the shared permission model, unified audit trail, or consistent data structure that a purpose-built connected platform provides. You end up managing integrations as a second operational responsibility.
What YBNW One Is
A business operating platform, not an app bundle.
YBNW One is built on a single PostgreSQL database managed by Supabase. Every module — from the Kanban board in project management to the payroll run in HR to the purchase order in procurement — reads and writes to the same database. There is no sync layer. There is no integration between a CRM database and a finance database. There is one database. This is not a marketing claim. It is a structural property of how the platform is built.
This means when a project goes over budget, the finance team sees the same project ID that the project team sees. When a vendor payment is approved, the procurement records and the accounts payable records are the same records. When a customer account is linked to both a CRM opportunity and a project, the link is a real database foreign key — not a text field someone typed to match records across two systems.
The practical consequence is that reporting does not require manual assembly. The executive dashboard sees live project status, live financial figures, live team capacity, live vendor pipeline, and live risk register — all from the same operational data that teams create during their regular work.
React 18
Supabase
PostgreSQL
Row-Level Security
Recharts
Stripe
The Data Layer
Supabase and Postgres are not the backend. They are the platform.
Most web applications use a database as a place to store state. YBNW One uses the database as the operational source of truth for everything the business does. The React frontend is a well-designed interface over that database. The database is where the work actually lives and where permissions are enforced.
172 database tables
The YBNW One schema has 172 tables covering every business domain the platform touches. Core tables include: projects, tasks, invoices, budgets, purchase_orders, employees, leave_requests, deals, crm_contacts, crm_companies, vendors, compliance_requirements, audit_plans, risks, inventory_items, kanban_columns, kpis, and more. Each table is normalized, indexed, and protected by workspace-scoped row-level security.
Row-level security at every table
Supabase's row-level security (RLS) is configured at the database layer, not the application layer. This means even if a bug exists in the frontend code, database queries from one workspace cannot return rows from another workspace. Security is baked into the schema through policies on every table. It cannot be accidentally disabled by a frontend change. This is the architectural property that makes multi-tenant data isolation reliable rather than dependent on developer discipline.
Real-time subscriptions
Supabase's real-time infrastructure means that when one team member updates a project status, another team member's dashboard reflects the change without a page reload. When a purchase order is approved, the procurement view updates live. When a KPI value changes, the executive dashboard updates. This is not polling — it is database-level event propagation via WebSocket subscriptions that are established when a user opens the workspace.
188 migration files
The database schema is managed through 188 numbered SQL migration files. Every change to the schema — adding a column, creating a new table, modifying a policy, adding an index — is a versioned, reviewable migration. The production database state is always reconstructible from source code. Upgrades do not require manual database surgery. Each migration is run in sequence and can be rolled back if it introduces a problem.
Shared foreign key relationships
When a project record in the projects table is linked to a budget in the budgets table and an invoice in the invoices table and a team assignment in the employees table, those links are real database foreign keys — not string fields that could drift out of sync. Cross-module reporting works because cross-module relationships are enforced at the database level through referential integrity constraints.
Edge Functions for automation
Server-side logic that should not run in the browser runs in Supabase Edge Functions — TypeScript functions deployed at the edge with direct access to the PostgreSQL connection pool. The platform has three production Edge Functions: Stripe checkout handling, Stripe customer portal management, and Stripe webhook processing. Additional Edge Functions handle complex business logic, background processing, and integration callbacks without cold-start latency.
How Modules Connect
Work that moves between departments stays connected.
The most valuable property of a shared data layer is that when work moves from one department to another, the context moves with it. Here is what that looks like in the actual data model.
Sales → Delivery
When a CRM opportunity closes, the deal record — client name, agreed value, delivery commitments, close date, assigned account manager — becomes the foundation for a project record. The project inherits the client from the CRM companies table via a foreign key. The budget is seeded from the deal value. The team assignment links back to the HR employees table. The customer account moves into the customer success module. Nothing is re-entered manually.
Projects → Finance
As project work progresses, billable time entries and project expenses flow directly into the invoice manager. Purchase orders created for project vendors are linked to the project ID so project budget tracking reflects actual spend, not just planned spend. The budget planner shows planned vs actual variance in real time. When a project closes, the profitability calculation pulls from real invoice totals and real expense records — not from estimates or manually entered figures.
Procurement → Accounts Payable
A purchase order created in procurement flows through approval, is received against actual delivery, and generates a payable record in finance. The vendor that supplied the goods is the same vendor record referenced in the procurement scorecard, the vendor risk assessment, and the supplier contract. The PO number on the invoice matches the PO number in procurement. There is no reconciliation step between a procurement system and an accounting system because they are the same system.
HR → Projects → Finance
Employee capacity data from the HR and resource planning modules informs the project workload planner. Time logged against projects flows into both project progress tracking and payroll costing. When a team member is on approved leave, their availability in the project resource planner reflects that leave — because both the leave request and the project assignment reference the same employee record. Workload and leave are not in separate systems that need to be reconciled.
Risk → Governance → Reporting
Risks logged in the risk heatmap module (categorized by type: technical, financial, operational, strategic, legal, reputational, security; scored on a 5×5 probability-impact matrix; status: open/mitigating/resolved/accepted) are connected to the governance and compliance dashboards. When the board requests an executive summary, the risk register data is already structured and current — not dependent on someone manually updating a slide deck or extracting data from a separate risk tool.
Customers → Success → CRM
Customer accounts in the CRM module — linked to contacts, companies, opportunities, and deal records — are connected to customer success workflows including health scoring, NPS tracking, renewal management, and support tickets. When a customer's health score drops, the account manager sees it in the same system where they manage the pipeline. Renewal dates visible in CRM are the same renewal dates that trigger alerts in customer success. There is one customer record, not two.
The Permission Model
795 permissions. 12 roles. One place to manage all of them.
Access control in YBNW One is not a setting buried in an admin panel. Every operation in every module — viewing a record, creating a record, editing a record, approving a workflow step — is governed by a named permission constant that is checked before the operation executes. The permission model is enforced at both the UI layer (preventing the display of controls the user cannot use) and the database layer (preventing unauthorized queries regardless of what the frontend sends).
01
795 named permission constants
Every significant user action is backed by a named permission. Examples from the actual codebase: VIEW_ALL_INVOICES, MANAGE_PAYROLL, CREATE_PROJECT, DELETE_PROJECT, EDIT_ANY_PROJECT, APPROVE_PURCHASE_ORDER, DELETE_VENDOR, VIEW_AUDIT_LOG, MANAGE_INVENTORY. You can give a financial controller access to all invoices without giving them access to HR payroll records. You can give a contractor access to specific projects without any access to finance or HR.
02
12 predefined role types
The platform ships with Administrator, Manager, Team Lead, Employee, Contractor, Viewer, Finance Manager, HR Manager, Compliance Officer, Project Manager, Support Agent, and Custom roles. Each has a curated default permission set designed for that role type. Roles can be customized: individual permissions can be added to or removed from any predefined role to match the specific structure of each organization.
03
Workspace and team scoping
Permissions operate at the workspace level. A user in Workspace A cannot see records from Workspace B even if they have identical roles in both. Within a workspace, records can be further scoped by department, project, or team. A contractor assigned to one project can see that project's records but not other projects in the same workspace. This scoping is enforced at the database layer — it is not a UI filter that could be bypassed.
04
Protected routes and UI gates
Every route in the React application is wrapped in a ProtectedRoute component that checks the user's permission set before rendering. If a user navigates to a URL they do not have permission for, they see a permission-denied view — not an empty page. The UI never shows controls for operations the user cannot perform. This is enforced at the component level through the useAuth() context hook that provides a hasPermission(permission) check.
05
Audit trails on sensitive operations
Changes to records with compliance significance — invoices approved, purchase orders raised, payroll runs processed, compliance requirements updated, vendor contracts modified, user access changed — are written to an audit trail that captures who performed the operation, what changed, and when. This audit trail is queryable, exportable, and cannot be modified by regular users. It is the evidentiary record that answers "who did this and when" for any sensitive business event.
06
Multi-workspace governance
An organization can run multiple workspaces — one per company entity, one per client, one per department — each with its own team, roles, and data. A user can be a member of multiple workspaces with different roles in each. A group administrator can oversee multiple workspaces without needing individual logins for each. Cross-workspace reporting is available to users with the appropriate cross-workspace permissions.
Who It Is For
Companies that want to run from one place, not from a patchwork.
YBNW One is the right fit for organizations where multiple departments need to collaborate on shared work, where leadership needs reporting that does not require manual data assembly, and where the cost and complexity of tool sprawl has become visible enough that consolidation makes operational sense.
01
Growing companies (10–500 employees)
At this stage, organizations have outgrown spreadsheets and point tools but have not yet committed to enterprise ERP complexity and cost. YBNW One gives the full platform — all departments, all modules, real database backing — at a price that scales with capacity rather than headcount. Every team member can be in the platform from day one without triggering per-seat billing.
02
Professional services firms
Consulting firms, agencies, engineering firms, and managed service providers run their business on a combination of projects, people, time, invoices, and client relationships. YBNW One connects all of these: project management is linked to time tracking, time tracking feeds invoicing, invoices connect to accounts receivable, and client relationships live beside delivery records and support tickets. The whole project-to-cash cycle is in one system.
03
Operations-heavy businesses
Businesses with procurement complexity, inventory management needs, vendor relationships, facilities management, compliance obligations, and governance requirements benefit most from the shared data layer. When a supplier delivers goods, the inventory receipt, the accounts payable record, and the vendor performance scorecard all update from the same event — because those are related records in the same database, not separate systems waiting to be reconciled.
04
Regulated industries
Companies in finance, healthcare, legal, and other regulated sectors need audit trails, access controls, compliance framework tracking, and data handling controls that a collection of general-purpose SaaS tools cannot reliably provide. YBNW One's database-first architecture — with row-level security enforced at the database layer, named permission constants for every operation, and a queryable audit trail — makes it easier to demonstrate access control and data handling to auditors and regulators.
05
Teams replacing a stacked toolset
If you are currently paying for separate project management, CRM, HR, finance, procurement, and document tools — and spending time managing integrations between them — YBNW One is designed to replace the stack. The implementation services team can assess your current tools, design the migration path, and wire the platform to your existing processes without requiring a big-bang cutover or extended downtime.
06
Founders and operators who want visibility
A founder running a 20-person business wants to see what is happening across the business without logging into six separate systems. The executive dashboard in YBNW One surfaces revenue, active projects, open tasks, team capacity, pending approvals, key risks, and recent activity — all from the same operational data the team creates every day, without a separate BI layer or manual reporting process.
Technical Foundation
Built on proven open infrastructure, not proprietary lock-in.
YBNW One is built on a technology stack that is auditable, well-understood, and maintained by the global developer community. There is no custom database engine, no proprietary workflow runtime, and no black-box integration layer that only YBNW engineers can debug.
The frontend is React 18 with Vite 7 — the most widely deployed JavaScript framework with the broadest ecosystem. The backend is Supabase on PostgreSQL — an open-source database with forty-plus years of production hardening. The billing infrastructure is Stripe. The deployment is Vercel. Every component of this stack is auditable, replaceable, and operated at scale by thousands of other organizations.
See the platform in one workspace.
Start a free workspace to explore every module. No credit card, no feature gates, no seat limits for your team. Or book a walkthrough and we will show you the platform against your specific stack and use case.