You already know the model.
Draw it, and run it.
Analysts spend their working lives modelling: entities, relationships, states, rules. Then the model becomes a document, the document becomes a backlog item, and the backlog item waits. dForge takes the diagram itself — draw your entities and relationships, import the file, and you have a working rough cut the same afternoon.
Then you and the AI finish it.
The model is right. It just never becomes software.
Your diagram is the deliverable.
Draw the model, import it, finish it with AI — and hand over a running system instead of a specification.
Draw it the way you already do
Entities, fields and relationships — in dbdiagram.io or anything that exports DBML, or as plain SQL. This is the artefact you were producing anyway. You just stop treating it as documentation.
- Bring DBML or SQL — the diagram you already drew.
- Entities, fields and relationships carried over as you drew them.
- No blank file, and no hand-off to translate your intent.
One command turns it into a module
The schema importer converts your diagram into a rough-cut dForge module: your entities and fields carried over, with views, menus, folders and roles inferred. Then you and the AI finish it — the actions, rules and reports a diagram was never able to hold.
- Views, menus, folders and roles inferred for you.
- You and the AI add the actions and rules a diagram can't carry.
- It all lands as reviewable metadata, never as code you must trust.
"Track client onboarding — stages, an owner, a due date."
Database, forms and roles — no developer.
What you hand over is a system, not a picture
A real PostgreSQL schema, generated screens, role-based access, an audit trail and reports — running, for actual users. When the business changes you change the model, not a ticket.
- A real database, screens, permissions and an audit trail.
- Reports people build themselves, inside their own access.
- Change the model later — no rewrite, no queue.
Spec and wait — vs. model and run.
Modules worth installing first for this.
Sales CRM: contacts, leads, opportunities, quotes, activities, and product catalog. Customer identity lives in the shared parties module; CRM-specific columns (industry, credit limit, account manager) are layered on as an extension.
Projects, tasks, time tracking, and daily reports. Time entry favors a daily-report flow over per-row grid editing; billable tracking lives in the pm-fin bridge.
Core HR management — departments, positions, employees, leave, attendance, skills, training, and documents
Tell us what you need and we'll build the module — or book a call to map your systems together.
See who else builds on dForge.
Monday, Zoho or HubSpot stopped fitting
Aging Access, FoxPro or custom ERP
Founders & domain-specific micro-SaaS
CIOs under pressure to deliver more, faster
Simplify operations on one governed model
Run ops behind Shopify or WooCommerce
Small companies with no developer on staff
Department managers waiting on central IT
Consultancies & systems integrators