// competency

Software & Platform Engineering

Custom software development for enterprise — from MVP to production-ready platforms. With architectural discipline instead of fast hacks, and business value over feature factory.

// about the practice

What it is and who needs it

Software development is not "hire 10 developers for 3 months". It is an engineering discipline with its own methodology: domain-driven design, architectural decisions (monolith vs. microservices), TDD/CI/CD, code review as a mandatory part of the process.

In 2026 the key advantage is not delivery speed, but long-term quality: whether the project remains maintainable in 2 years, or becomes legacy that is "easier to rewrite than support".

You need this if

  • You need a custom product not available off the shelf.
  • Existing system requires reengineering — old code became a blocker of business agility.
  • Development team grows but delivery speed falls — time for architecture consulting.
  • New product launch with unknown risks ahead — you need from-scratch design experience.
// our position

Why we do this differently

01

Delivery speed without architectural discipline is not speed — it is debt.

The first year of a feature factory gives an illusion of speed. In year two, the team spends 60% of time on refactoring and fixes. This is not a bug, it is a pattern — without architectural reviews, codebase degrades linearly with time.

02

Microservices without operational maturity = a distributed monolith, which is worse than a monolith.

Microservices pay off for teams of 50+ developers with own DevOps. For teams of 5–10, it is overengineering that doubles complexity without benefits.

03

Code review is not quality control — it is knowledge sharing and peer training.

A team where code review is a formality ("LGTM") becomes n separate experts in a year, none of whom understands the others' code. Bus factor = 1 per component. This is a first-order organizational risk.

// honest filter

When you need this — and when you don't

It is more honest to say "you do not need this yet" than to sell an engagement that will not deliver ROI.

✓ Need it

  • Custom product needed, not available on the market
  • Existing system blocks business initiatives
  • Engineering culture ready (code review, tests, CI)
  • Strategic sponsor ready on client side

✗ Not yet

  • Solvable with off-the-shelf SaaS — do not build from scratch
  • Team without testing culture — engineering maturity first
  • You want an "MVP in 2 weeks" — better path is no-code/low-code
// process

How we run the engagement

01

Discovery & domain modeling · 3–4 weeks

Interviews with process owners, event-storming for bounded contexts, risk assessment. Output: domain model and architectural decision records (ADR).

02

Architectural design · 3–4 weeks

Monolith vs. microservices choice, tech stack, API design, data schema, IaC approach.

03

MVP/Pilot · 3–4 months

First version for one use case with real users. Proves technical architecture and business assumptions at production quality.

04

Scale-out · 6–18 months

Phased functionality expansion, performance optimization, adding new features by business value priority.

05

Continuous engineering · ongoing

Regular architectural reviews, refactoring sprints, dependency updates, security audits. Without this, code degrades in 12–18 months.

Project lead: Softengi (custom software, AI/ML systems) and InBase (UnityBase low-code, enterprise platforms).
Brought in when needed: SL Global Service (cloud-native architecture), Data Management IG (data layer design).

// anti-patterns

Typical mistakes we have seen projects fail on

Feature factory without architectural oversight

Team delivered 50 features in year one. In year two, 30% of time goes to bug-fixing, another 30% to refactoring. Business asks why speed dropped.

What we do instead: mandatory architectural reviews per epic, refactoring as part of sprint capacity (not "later").

Microservices "to grow into"

A team of 6 developers builds 12 microservices "because it is modern". DevOps overhead exceeds business logic.

What we do instead: we start with a monolith and extract services only when there is evidence-based reason: different scaling profiles, different release cycles, or teams >50 engineers.

Tests "when there is time"

Test coverage <10%. Every release is a week of manual QA. After 18 months, no refactoring is possible.

What we do instead: tests as part of definition-of-done (not optional). Target coverage >70% for business logic.

// experience

Typical scenarios from our practice

No precise savings percentages — actual numbers depend on the client's starting point. Instead — concrete architectural decisions and organizational changes.

Bank · CRM platform

Custom CRM on UnityBase

Instead of an off-the-shelf CRM — a custom platform on UnityBase with integration to 14 banking systems. 12 months to production, then continuous evolution.

Energy holding · workforce management

Replacing Excel processes with a custom product

Business processes on 200+ Excel files. Custom platform with role-based UI, audit trail, ERP integration. 8 months. The hard part — domain knowledge transfer.

Government registry · public API

API gateway with versioning and throttling

Custom API platform for a government registry serving 12 agencies and 200+ external consumers. SLA 99.95%. 14 months.

// deep dives

Articles on this topic

Nine recent expert articles — from thematic overviews to specific architectural decisions.

// stack

Technologies we work with

Backend

Java · Python · .NET · Node.js · Go · PHP (UnityBase)

Frontend

React · Vue · Angular · Next.js · TypeScript · Svelte

Databases

PostgreSQL · MS SQL · MongoDB · Redis · ClickHouse · Elasticsearch

Architecture

Domain-Driven Design · CQRS · Event Sourcing · API-first · Hexagonal architecture

DevOps & QA

Docker · Kubernetes · GitLab CI · GitHub Actions · Playwright · Cypress · JUnit · pytest

Standards

ISO/IEC 27001 · OWASP · SOLID · 12-factor app · Clean Architecture

// frequently asked

Frequently asked questions

Monolith or microservices for a new project?

Almost always — modular monolith. Microservices pay off only for teams of 50+ with established DevOps culture. For everyone else — overengineering with worse operational profile.

How long does a custom product take?

MVP — 3–4 months. Production-ready — 6–12 months. If you are promised "product in 2 months" — it is either a templated solution (then why custom?) or a product debt to be paid later.

How to measure development team quality?

Three metrics: (1) lead time from commit to production (target <1 day); (2) deployment frequency (target several times per week); (3) change failure rate (target <15%). These are DORA metrics — the industry standard.

Is TDD still justified in 2026?

For business logic — yes, mandatory. For UI and scratch prototypes — opt-in. Classic test-first → green → refactor cycle catches 80% of bugs before code review.

What is Domain-Driven Design?

An approach to modeling complex business domains via ubiquitous language with business stakeholders and explicit bounded contexts. Pays off for projects >6 months with non-trivial business logic. For simple CRUD — overhead.

// other competencies

Related competencies

Real projects rarely fit in one competency. See which other areas we work in.

Tell us about the product you want to build

30-minute discovery call with an architect. We will discuss your idea, technical risks and realistic expectations.

All contacts