Skip to content
WEBváltóWEBváltó

Development

Software

Development and support of business-critical, high-availability enterprise systems.

Let us talk about the project
What we do
01

Custom business systems

Transactional and back-office systems, internal tools and portals. Typically projects where the hard part is the data model and the integration.

  • In a business system, the data model is the most expensive decision, so that is where our projects start.
  • A bad model keeps costing the client five years later, on every change.
02

Data and integration layer

Connecting systems, moving data and keeping it intact. Data integration matters from an operations perspective too.

  • Data migration and synchronisation between production systems.
  • Designing, building and documenting integration interfaces.
  • Data modelling and database design for long-term use.
03

Replacing Oracle Forms

Support for Forms 12c runs out in 2026–2027, so many organisations are deciding now whether the system moves to 14c or to a new platform. Replacement is not a simple technology swap, which is why it gets underestimated.

  • We start with a pilot project. It shows in miniature, under controlled conditions, what the full project will have to carry out.
  • We rebuild the same functionality on two target platforms: in Oracle APEX, and on Spring Boot with React/Angular.
  • We develop on both target platforms and teach the technologies behind them: APEX, Spring Boot, Angular and React.
How we approach it
04

Team extension and on-site support

We extend existing development teams with colleagues who do not necessarily need weeks to get to know the environment.

  • We work to the processes and tools already in place at the client.
  • On-site technical support during rollouts.
  • Security code review is also available on its own.
Get in touch
Modernisation

Legacy software modernisation

  • Many companies run a business system that has been in use for years and that important processes depend on, yet only a few people still know how it works. It is often barely documented and hard to change or extend. If it is built on an outdated technology stack that is no longer supported, that is a significant security and operational risk.
  • We take on getting to know existing systems and modernising them step by step, even if someone else built them originally. We uncover the dependencies and capture the important business behaviour in tests. On that basis we decide together which parts are worth keeping, where change is needed, and in what order to proceed.
  • Alongside development, we also put the conditions for operation in order. We document how the system works and set up monitoring and a repeatable deployment process. This puts both day-to-day operation and later development on a firmer footing.
Let us talk about the system
Oracle Forms

What gets underestimated in a Forms replacement

Most offers on the market are automated code conversion. Projects, though, do not fail on the conversion — they fail on what nobody can explain about the system any more.

Neither target platform is a one-click migration. Not even APEX, despite the Oracle proximity: the operating models of Forms and APEX differ substantially, and the rewrite calls for genuine redesign.

On replacing Oracle Forms
How we work
  1. 01

    Understanding

    First we look at what the system does today, and why it does it that way. What counts is how it is actually used now, even if it was originally designed for different needs.

  2. 02

    Data model and architecture

    We front-load the expensive decisions, while changing them is still cheap. We document the important decisions together with our recommendations.

  3. 03

    Building in stages

    We deliver working software at regular intervals, so the direction can still change along the way if needed.

  4. 04

    Handover and operation

    We prepare for handover while we build. If operations stay with us too, no knowledge is lost in the handover. If the client's own team takes over, they know exactly what they are taking on.

We do not give an estimate for a system we have not seen.

Let us talk about the options
Our practice2026

How we build today

Besides the working system, a project also produces a few things that stay with the client, even if another team takes it over later.

  • We derive the dependency map from the actual codebase, so the assessment rests on what is really in the code. Interviews add what the code cannot tell.
  • When replacing an old system, we first capture its behaviour in tests and measure the new system against them. The test suite thereby also describes what the old system did.
  • We derive the documentation from the code, so it does not go stale the day after handover.

These are our defaults. If a project calls for something else, we discuss it and write down why we deviate.

Technology

We have no favourite technology that we push onto every project. We choose what suits the system at hand and what can still be maintained years from now.

Server side

  • Java 21 / 25 LTS
  • Spring Boot 4
  • Kotlin
  • Node.js

Data

  • Oracle Database 23ai
  • PostgreSQL
  • PL/SQL
  • MongoDB
  • Redis
  • Oracle APEX 26.1

Front end

  • TypeScript
  • Angular
  • React

Mobile

  • Kotlin (Android)
  • Swift (iOS)

Platform

  • Docker
  • Kubernetes
  • Linux
  • Oracle Cloud
  • AWS

Integration

  • Oracle SOA Suite
  • Oracle Service Bus
  • Oracle Data Integrator

On mobile we build native

Kotlin for Android, Swift for iOS. For simple apps, cross-platform frameworks work well, but as a system grows more complex they take more and more extra effort. We mostly build mobile clients for complex systems, so that is where going native pays off.

Areas of expertise

Let us talk about the task

The first conversation shows what the task is and whether we are the right choice for it. If we are not, we make that clear from the start.

Get in touch

We reply within three business days.