Functional Evidence Is Not Enough
The POC proved screens and functions, not transaction correctness under concurrency, failure, and rollback.
VisualBase vs. .NET 10 + ABP for the Inventory and Production System
Start a Greenfield implementation using .NET 10 LTS and ABP. Keep VisualBase only as a conditional option if it passes explicit engineering and contractual gates.
The POC proved screens and functions, not transaction correctness under concurrency, failure, and rollback.
Procedures, views, rule tables, and metadata make behavior harder to trace, test, and release.
It does not remove lock-in unless NCGR can independently build, operate, and upgrade the platform before final acceptance.
Select the technical foundation before developing a long-lived inventory and production system.
Can the option support inventory, production, approvals, reporting, and integrations?
Can rules be reviewed, tested, released, rolled back, and monitored?
Can NCGR operate, maintain, and upgrade the system without critical vendor dependency?
Does initial speed justify the long-term cost of customization, upgrades, skills, and exit?
Decision rule: functional fit alone is insufficient; strategic systems must also pass engineering assurance, independence, and operational gates.
Menus, modules, Quick Table, Formula Editor, approvals, generated forms, and SQL Studio. [S4][S11]
Runtime screen generation, SQL-centered customization, and rules and behavior stored in a database repository. [S1][S2]
Based on the provided context, the vendor will hand over the no-code platform source after project completion; legal scope and buildability require verification.
Actual source, independent build, testing, performance, security, DR, APIs, observability, and the exact product version were not proven in this assessment.
This is an engineering architecture assessment. The 80:08 recording was reviewed as visual workflow evidence, not a source audit or production-readiness certification.
VisualBase is effective at rapidly creating standardized administrative data applications.
Eleven modules were visible, including inventory, procurement, finance, planning, and operations.
Quick Table, fields, approvals, and a generated form were assembled in the recorded session.
The runtime model is designed for bilingual interfaces and an Arabic context.
Fifteen tabs configure source, rules, events, security, approvals, and tools.
Formula Editor provides Test and Validate; comprehensive automated coverage was not shown.
It accelerates change, but requires strong controls to prevent bypassing the release lifecycle.
Source: NCGR VisualBase environment [S4] and development UX recording dated 27 August 2026 [S11].
≈ 40:00
Quick Table generates SQL structure and default audit columns inside the platform.
≈ 50:00
Formula Editor provides local testing and validation while composing a formula.
≈ 72:30
SQL Studio allows an approval stored procedure to be edited directly in the session.
No evidence demonstrated prevention of double issue or conflicting reservations against the same balance.
Test and Validate are local helpers; no evidence showed metadata, SQL, and workflow regression coverage in CI.
The session showed DDL, metadata, SQL, and generated runtime behavior without proving Git/PR controls, artifacts, or environment promotion.
Least privilege, service-bypass prevention, and dynamic SQL safety were not reviewed.
Performance, monitoring, backup and restore, DR, and RPO/RTO were not proven through testing.
There is insufficient evidence of owned APIs, explicit versions, idempotency, and safe reprocessing.
An unproven capability remains an open risk; for a strategic system, it cannot be converted into a positive assumption.
Behavior is distributed across a proprietary engine, metadata, and mutable database objects.
Behavior is explicit, owned, and tested; the database provides persistence, transactions, and constraints.
Sources: direct observation and vendor material [S1][S2][S4]; official ABP capabilities [S6].
Every movement is an independent entry; corrections use reversals or adjustments linked to the original.
Prevent over-allocation under concurrent requests and retries.
Maintain a complete chain for serial or lot, quarantine, inspection, and recall.
The version used by a production order is fixed and linked to effectivity and approval.
Release, issue, consume, receive, scrap, rework, and close states are explicit.
Provide idempotency, safe reprocessing, and reconciliation with procurement and finance.
Every critical rule must be explicit, owned, testable, and proven under failure and concurrency scenarios.
| Criterion | VisualBase—Current Evidence | .NET 10 + ABP | Stronger Option |
|---|---|---|---|
| Initial Delivery Speed | High for screens, CRUD, and configuration | Relatively slower due to domain and platform foundation | VisualBase |
| Business Logic Clarity | Distributed across metadata, SQL, and the engine | Owned C# modules that are written and reviewed | .NET |
| Automated Testing | Not proven for rules stored as data | Unit / Integration / Contract / E2E in CI | .NET |
| Release Governance | Runtime editing; Git integration not proven | PR, review, build artifact, and planned migration | .NET |
| Operations and Observability | Distributed workflow; telemetry and DR not proven | Metrics, logs, traces, health checks, and monitored jobs | .NET |
| Ownership and Exit | Conditional source handover after project completion | Product code owned from day one; open framework | .NET |
| Skills Availability | Specialized expertise in the vendor engine and model | Broader ASP.NET Core, SQL, and DevOps talent market | .NET |
The conclusion does not treat ABP as a ready-made inventory product; it is a framework for building a product owned by NCGR.
Source access enables audit, defect correction, service continuity, and possible transfer of maintenance to another party.
However: source files without an independent build, rights, tooling, tests, and operating knowledge may become an unusable asset.
Require independent-build proof and periodic source updates as acceptance and payment gates—not a post-delivery promise.
Are the rights permanent and do they include modification, operation, and an alternative maintenance provider?
Reduced ConditionallyCan NCGR build, upgrade, and sign the engine without vendor services?
Not ProvenMetadata parsers, events, rules, and screen generation are tied to a proprietary model.
HighProcedures, views, and rule tables make exit a re-engineering exercise, not only a data copy.
HighMaintenance requires knowledge of the engine, non-standard practices, and proprietary extension points.
HighSource handover improves legal exit options, but technical lock-in falls only after independent operation and maintenance are proven.
Clone a clean repository and build the full platform without a vendor device or account.
Deploy a clean environment, restore backups, and test DR under NCGR control.
Fix a defect, add a test, and produce a signed release through the NCGR pipeline.
Upgrade a dependency or runtime with compatibility evidence and metadata migration.
An alternative team implements a change without the original vendor.
Legal acceptance of licenses, rights, and a maintainable software bill of materials.
Any failure in buildability, rights, or dependencies means lock-in risk remains material.
Start with a modular monolith: explicit domain modules, API-first contracts, SQL Server for persistence, and testing, release, and operations owned by NCGR.
Explicit types and contracts, code review, layered testing, observability, and a broad talent market.
Greater initial foundation work, domain discovery, CI/CD, security, operations, and testing before feature expansion.
ABP is not a ready-made ERP. Avoid premature microservices and make deliberate decisions about commercial modules and framework upgrades.
Sources: official ABP documentation and releases [S6][S7], and the .NET support policy [S8].
Only one module writes each transactional table; reporting and integrations use contracts.
Reservation, movement, reversal, BOM, and production-order lifecycle become C# rules and tests.
Git, CI/CD, EF Core migrations, traces, metrics, and correlated logs.
The approach retains SQL Server and limits stored procedures to measured, versioned, and tested needs.
| Decision Gate | VisualBase | .NET + ABP | Conclusion |
|---|---|---|---|
| Functional Delivery Speed | Proven | Moderate | Clear VisualBase advantage |
| Domain and Concurrency Correctness | Not Proven | Provable | Critical gate |
| Testing and Release Governance | Not Proven | Standard Approach | Critical gate |
| Security, Operations, and Recovery | Not Proven | Designed and Tested | Critical gate |
| Ownership and Exit | Source Promise | Owned from the Start | VisualBase remains conditional |
| Platform Decision | Do Not Start | Recommended Option | Approve through an ADR |
Build the product with .NET 10 LTS and ABP. Do not adopt VisualBase as the strategic foundation unless the evidence changes and every critical gate is passed.
Do not scale the team until correctness, concurrency, security, performance, and operations pass.
The vendor must run the same scenarios and prove source, buildability, and independence under NCGR control.
Approve .NET 10 LTS and ABP as the foundation for the inventory and production system