Atlas proves operating depth.
The older system already covers a wide field-sales operation. Its value is the amount of real workflow knowledge inside it.
Acquisition brief / 01
Buy the system. Choose what carries it forward.
Atlas and Icarus are two generations of the same ERP effort. Atlas holds proven operating workflows. Icarus reorganizes the product for many companies and industries. The practical question is how to turn both into one product that can be rebranded, completed, and resold.
Read the acquisition thesis
The short version.
This is not a choice between two subscriptions. It is a decision about how two codebases should work inside one acquisition.
Icarus fits the resale model.
The newer system was organized for many companies, shared infrastructure, and controlled customer variation.
The acquisition value is in the pair.
A credible plan uses Icarus as the potential SaaS base and Atlas as operational proof and a source of selected workflows. Diligence has to prove what can move.
Working hypothesis
Use Icarus as the candidate multi-company product base. Use Atlas as working evidence and a source of selected domain workflows. Do not promise a wholesale merge. Prove transfer effort in diligence.
Existing estate / 03
Two systems. Different jobs.
Feature lists blur the useful distinction. Atlas shows what the team has already solved. Icarus shows how the next product expects to change from customer to customer.
ATLAS / V1
Operational proof
Atlas grew around a field-sales business and carries broad working scope. It is the richer reference for how real departments use the ERP day to day.
- Current shape
- One organisation per deployment
- Proven areas
- Leads, HR, payroll, attendance, inventory, after-sales, fleet, and messaging
- Acquisition role
- Working product evidence and a candidate source of selected workflows
ICARUS / V2
Product foundation
Icarus is younger, but it starts from the commercial shape in the SOW. Many organisations share one product while configuration, industry rules, and bespoke experience live in separate layers.
- Current shape
- Organisation-scoped records inside one deployment
- Working areas
- 14 registered blocks covering sales, fulfilment, workforce, finance, documents, and alerts
- Rebrand status
- The codebase is still branded Atlas V2 internally
- Acquisition role
- Candidate SaaS base, subject to isolation and completeness testing
Architecture / 04
Where change lives.
The drawing is only useful if it explains a business consequence. Switch views, then read what happens when a new company, market, or workflow enters the product.
Buyer questionAtlasIcarus
A new SME signs
Stand up and shape another customer deployment.
Create another organization inside the shared product model.
The customer needs different terms and rules
The change may enter shared application code.
Configuration and recipes provide a defined place for variation.
One domain needs to change
The effect can cross a tightly connected application.
Blocks aim to keep domain logic and data boundaries separate.
The product is rebranded for a market
Brand and workflow changes live in the customer-shaped product.
Fit-outs and recipes separate experience from the shared base.
A credible role for each asset.
The value case is stronger than a forced winner. It is also more demanding than copying one repository into the other.
Atlas as evidence
Use the working ERP to understand department flows, data needs, edge cases, and the scope customers already expect.
Icarus as the base
Test whether its tenant model, configuration system, and domain boundaries can carry the resellable SaaS product.
The SOW gaps
Specify the modules, locales, mobile app, compliance work, migration, and acceptance tests that neither repository finishes today.
No merge promise. Matching feature names do not prove that code can move cleanly. Authentication, data models, dependencies, licensing, and coupling must be checked first.
SOW trace / 06
What the brief still demands.
These are evidence states, not completion scores. "Not evidenced" means the repositories reviewed do not prove the requirement yet.
RequirementAtlas evidenceIcarus evidenceDisposition
Multi-company SaaS
One organisation per deployment
Organisation-scoped records in one deployment
Structural fit in Icarus. Isolation still needs testing.Per-company configuration
Configuration exists, but customer work can enter feature code
Typed knobs, recipes, and fit-outs
Structural fit in IcarusConfigurable approvals
Not traced against the SOW
Not traced against the SOW
Formal gap reviewHR and sales
Broad working proof
Working domain blocks
Partial in bothFinance and supply chain
Some operational coverage, not the full brief
Ledger, inventory, and quote foundations, not the full brief
New scope remainsEnglish and Arabic
No Arabic locale evidenced
English and Hindi today. Arabic and RTL are open
New workEmployee HR mobile app
Responsive web, no native HR app evidenced
Web application today
New workSaudi compliance and reporting
Not evidenced as complete
Not evidenced as complete
Specialist scope and validationRequested reference stack
Next.js, TypeScript, Convex, Clerk
Next.js, TypeScript, Convex, Better Auth
Commercial and technical decisionWork plan / 07
What happens before build estimates.
Dates come after the code and the SOW have been traced. These gates put the decisions in the right order.
- 01
Prove ownership and deployability
Confirm source ownership, licenses, third-party dependencies, repository completeness, and that each demo matches the code offered in the transaction.
- 02
Test the product boundary
Threat-model tenant access, test organisation-scoped queries, and decide what level of data separation the commercial product requires.
- 03
Trace the SOW line by line
Mark each requirement as working now, suitable for adaptation, or new implementation. Decide whether the requested stack is binding.
- 04
Assign each asset a role
Choose the product base. Then decide which Atlas workflows are references, which are adaptation candidates, and which should stay behind.
- 05
Fund the named gaps
Treat Arabic and RTL, mobile HR, Saudi requirements, migration, security, and acceptance testing as their own workstreams.
Prove this before money changes hands.
- Source ownership and transfer rights
- Open-source and commercial dependency licenses
- Demo-to-repository correspondence
- Tenant isolation and authorization coverage
- Data-model and workflow transfer effort
- Migration, hosting, security, and support obligations
Recommended next stepCommission a formal acquisition audit and SOW trace across both repositories. That produces the real module plan, transfer scope, risk register, and estimate basis.
See what is real.
Open both systems. Judge Atlas for its operational depth and Icarus for the product structure it is trying to establish.
Atlas / current ERPOpen Atlasatlas.vividverseglobal.comIcarus / product baseOpen Icarusicarus.vividverseglobal.com
Both demos are evidence inputs. Neither replaces code, ownership, security, or SOW diligence.