EspañolCatalàEnglish
Appearance
Let’s talk
Let’s talk
EspañolCatalàEnglish
Appearance

CLIENT WORK / ENGINEERING PROOF

Real work.
Real context. Clear boundaries.

A useful case study is not a gallery of screenshots or a technology list. It should explain what had to be solved, which constraints shaped the decisions, what Rabassoft was responsible for and what evidence exists today.

PROOF / HIERARCHYSCOPE MATTERS
CLIENT WORKReal business problems
Condis · ModernizationeVins · Product Engineering
RABASSOFT ENGINEERINGArchitecture and engineering capability
Schema Engine · Experimental

CLIENT WORK

Client work with explicit scope and status.

Every collaboration shows something different. We do not try to turn them into the same story or attribute more responsibility than we really had.

01 / BUSINESS SYSTEMS MODERNIZATIONOPERATIONAL APPLICATION

From the initial assessment to an operational application for managing incidents and investment proposals.

The work began with a technical assessment of the existing application, its data, rules and dependencies before development was committed. That evidence made it possible to define the transition, redesign what was needed and build the new application.

STUDY

The initial assessment recovered rules, dependencies, data and user needs before the scope and transition were defined.

APPLICATION

The software developed is an application for managing incidents and investment proposals.

MIGRATION

Data migration treated as a repeatable, verifiable process, with traceable results and errors.

DELIVERY

The transition also modernizes how the system is delivered and evolved, not just its interface.

  1. 01STUDYStudy the systemApplication · data · users
  2. 02DEFINEDefine the transitionScope · architecture · migration
  3. 03BUILDBuild the applicationIncidents · investment proposals
  4. 04OPERATEOperate and evolveDelivery · operations · evolution
See our approach to modernization Explore our technical assessments before development
02 / PRODUCT ENGINEERINGFRONTEND / PRODUCT COLLABORATION

Evolving an existing SaaS without ignoring customers, data and product constraints.

Rabassoft worked on defined frontend and product areas while the eVins team remained responsible for the wider platform and backend. The evolution combined technical modernization, modular architecture and the ability to incorporate new priorities without missing the committed date.

FOUNDATION

Progressive modernization of Angular and PrimeNG and a transition from an NgModule-based structure to standalone architecture, without resorting to a complete product rewrite.

PERFORMANCE

Lazy routes and dynamic loading reduced the JavaScript included in the initial load by 80%, making startup lighter and delivering a noticeable improvement in page loading.

TYPE SAFETY

Strict typing was progressively extended across weakly typed areas. Inconsistencies that could previously go unnoticed began to be detected during development and compilation.

MODULARITY

Frontend routes and capabilities were composed according to contracted modules, avoiding the loading and initialization of functionality that did not apply to each customer.

DELIVERY

When new requirements emerged against a tight schedule, we prioritized and implemented additional modules and delivered the agreed scope by the committed date.

PRODUCT CONSTRAINT

Decisions about modules and the marketplace were adapted to real constraints from customers, data and existing operations—not to an idealized greenfield redesign.

  1. 01CURRENTExisting SaaSCustomers · modules · constraints
  2. 02MODERNIZEModernize the foundationAngular · standalone · strict typing
  3. 03OPTIMIZEOptimize loading−80% initial JavaScript · modular routes
  4. 04DELIVERDeliver prioritiesAdditional modules · committed date
SCOPE BOUNDARY

Rabassoft worked on defined frontend and product areas. The wider platform, backend and authorization controls remained the responsibility of the eVins team.

See our product and platform approach

RABASSOFT ENGINEERING

OPEN SOURCE / EXPERIMENTAL

Schema Engine: validated metadata, explicit application decisions.

Schema Engine exists to reduce the repeated implementation of interfaces such as forms, tables and property panels when their structure needs to vary by application, purpose, operating mode or effective context.

It explores how to turn data and presentation metadata into validated, normalized interface definitions executed by framework-independent runtimes.

The application always retains control over data, accepted operations and authorization. Presentation may reflect effective permissions, but it never replaces security validation by the application or server.

The first implemented vertical is forms driven by JSON Schema and UI Schema. Other view families are part of the future direction and are not presented as current capabilities. Schema Engine is a Rabassoft engineering project and a space for architectural experimentation—not client work or evidence of production adoption.

CORE

Compilation, diagnostics, normalized definitions and runtimes designed to remain independent of the presentation framework.

CONTROL

The application can accept, reject or defer operations without handing ownership of the model to the renderer.

PROJECTIONS

The same model can be presented in different ways according to the purpose and context provided by the application.

INTEGRATIONS

Replaceable validation, translation, adapters and renderers prevent any one technology from defining the portable model.

  1. 01INPUTSchema + UI SchemaCurrent data and presentation metadata
  2. 02COMPILENormalized definitionValidation · compatibility · diagnostics
  3. 03RUNTIMEControlled executionSnapshots · interaction · validation · operations
  4. 04BOUNDARYApplication decisionAccept · reject · defer
  5. 05PROJECTIONReplaceable presentationAngular adapter · native renderers · Aria pilot
MATURITY BOUNDARY

Schema Engine remains publicly classified as Experimental until its contracts, documentation, releases and adoption justify a different classification. Tables, property panels, contextual variants and authorization-based projection are future direction, not current capabilities. We do not show versions or metrics here that could become outdated.

WHAT COUNTS AS PROOF

We prefer a bounded, verifiable story to a larger commercial claim.

A case study is useful when it makes clear what happened and what can reasonably be inferred. Context, scope and boundaries are therefore part of the evidence.

01 / SCOPE
Visible scope

We explain what Rabassoft was responsible for and what was left out.

02 / STATUS
Current status

A project in pre-production is presented as pre-production; an experiment, as an experiment.

03 / EVIDENCE
Evidence before adjectives

Verifiable decisions, constraints and mechanisms carry more weight than a technology list.

04 / BOUNDARIES
explicit limits

We do not turn partial collaboration, internal work or a demo into a larger commercial story than the evidence supports.

YOUR CONTEXT

Does your situation look like any of these?

You do not need to arrive with the solution already decided. The first conversation helps us understand the context and assess fit.

Let’s talk