Main content
EnglishRomână
Contact
EnglishRomână

Custom software, from web to firmware

We develop custom software in Cluj-Napoca, EU: SaaS platforms, operations software, phone apps and firmware. One team builds all of it, from the database to the sensor above a museum door.

Project briefCase studies
FIG. 1Muzeul Baia, one backend
Muzeul Baia system: people counters send their readings to the backend. The public portal, the ticketing, the back office with its zone map and the offline audio guide app all run on the same backend and codebase.HTTPPeople countersAnonymousIngestSensor dataDatabaseOne backendPublic portalTicketsBack officeAudio guideOffline

Built for Muzeul Baia: every public and staff tool on one backend.

Muzeul Baia case study

Every visitor tool, run by the museum's own staff

Run by museum staff from one login

Web platforms, IoT systems and mobile apps

Web platforms and SaaS

Multi-role SaaS on one backend, and the operations software a business runs on.

40%

More clients served in the same time

Rarău Rental: inventory, booking, check-in

Built forMozar, Rarău Rental, OpenTest

How the SaaS platforms are built
FIG. 2Mozar, on two screensDemo data
Mozar professional dashboard for one mission: required documents grouped into identity, legal and financial, one document flagged for revision with the auditor's note, mission progress at 50 percent and a discussion thread with the auditor.
Phone view of a Mozar quote: quote number, company, mission type, amount before tax, VAT, a total of 1 368 euros, the terms checkbox ticked and an Accept and pay button.

How a custom software build runs

Each stage ends in something the client can check.

FIG. 5One build, stage by stage
A build runs from a written analysis to a staging build with demo data, then a signed acceptance for the stage; the loop repeats for the next stage until the production release and handover.Next stageWritten analysisRoles, data, integrationsStaging buildDemo dataStage acceptanceSigned reportProduction releaseDocs and handover

What each stage delivers

Written analysis
Roles, processes, the data model and the integrations, agreed on paper before the first line of code.
Build on staging
Working software on a staging environment during the build, with demo data the client can click through.
Acceptance per stage
Each stage closes with a signed acceptance report.
Release and handover
Production release, documentation and a handover session for the people who run the system.

Existing systems: rebuild or keep

A written review comes before any promise.

FIG. 6Inherited code, two paths
An inherited codebase goes through a written review, which leads either to a rebuild behind a migration, as on Mozar, or to keeping the system and moving it forward, as on OpenTest.Inherited codeAnother teamWritten reviewKeep or rebuildRebuild behind a migrationMozarKeep and move forwardOpenTest

Mozar: rebuild behind a migration

Mozar's first platform was replaced by a rebuild from scratch. The migration was rehearsed until it ran clean, the old system stayed untouched, and no user had to reset a password.

Mozar case study

OpenTest: keep and move forward

OpenTest still runs on the stack it launched with. Its backend was upgraded step by step, without a rewrite.

OpenTest case study

Every change is tested before it reaches users

Claude Code writes part of the code; tests and an engineer who knows the system check all of it.

Tests per CI runDemo data

1,210tests

Checks that run in CI

  • Access rule tests
    What it catches: A role that can read rows it should never see
    Project: Mozar, Rarău Rental, Muzeul Baia
  • Database change checks
    What it catches: A database change that would break existing data
    Project: Mozar
  • Pricing tests on every combination
    What it catches: A cart priced above its cheapest package split
    Project: Rarău Rental
  • Browser walks at phone width
    What it catches: Any element that overflows a 390 px screen
    Project: Rarău Rental
  • Byte-exact protocol tests
    What it catches: Firmware and app reading one byte of a packet differently
    Project: Regularity Rally System

Teams that want the same setup in their own repository get it through Claude Code for teams. The same checks are the evidence a customer's NIS2 questionnaire asks a supplier for: NIS2 for software suppliers. The AI agents we build run inside software made this way.

Technology stack by layer

Chosen per project. A client's existing stack stays when it is sound.

Web
Next.js, React, TypeScript
Backend
Node.js, Python
Data
PostgreSQL
Mobile
React Native, iOS, Android
Embedded
C, ESP32, FreeRTOS, Bluetooth Low Energy
Delivery
Automated tests, continuous delivery, Docker

Custom software development FAQ

Web, mobile and IoT in one studio

One studio covers all three because real projects need all three. Muzeul Baia combined a public site, an Android audio guide and people counters in one codebase. When the same engineers write the firmware, the backend and the app, there is one protocol, one data model and one owner for every bug.

Taking over a codebase from another agency

An inherited codebase gets a written review first: what can stay, what blocks the next feature and what a migration would risk. The review ends in a recommendation to keep and extend the system, or to rebuild it behind a migration, as on Mozar.

Mozar case study

AI-written code in production

Claude Code writes part of the code. Every change still goes through type checks, database tests and CI, and a person who knows the system reviews it before it merges. The checks that run on each project are listed on this page.

Custom software or off the shelf

Off-the-shelf software wins when the process is standard. Custom pays off when the process is the business: Rarău Rental gives a ski rental counter a console that prices every cart at its cheapest package split, a rule specific to that shop.

Cost of custom software

Cost follows scope: the number of user roles, integrations and platforms, and any hardware. After the written analysis the build is priced per stage. Hardware prototypes add parts and board runs on top.

Handover at the end of a build

Handover means a system another engineer can run: migrations, seed data, runbooks and deploy scripts sit next to the code, with documentation for the people who operate it. Ownership of the code and the accounts is set in the contract; the handover checklist lists what stays with the client.

Working alongside an in-house team

Work lands as pull requests in the team's own repository, through its CI and review rules. Teams that adopt Claude Code themselves can add the setup described in Claude Code for teams.

Claude Code for teams

A first build, scoped in writing

A few lines on the system and its users are enough to start.

Project brief
Case studies
Email
contact@elastoapps.com
Studio
Cluj-Napoca, Romania, EU