We reply within three business days

Your traffic spike is not an incident.It's Tuesday.

Altessa Solutions builds high-load platforms, client applications and AI that hold up in production. You talk to the engineers who will do the work, from the first call onwards.

Request a first readHow we work
every change is read by a second engineerbefore it reaches production
What
High-load platforms. Client applications. AI in production.
How
Fixed-scope project. Dedicated team. Staff augmentation.
Start
Discovery week, starting within ten business days.
Sectors
  • Fintech and payments
  • Mobility
  • Media streaming
  • Telecom
  • Healthtech
  • Marketplaces

Why we start by reading

Load does not break systems. Decisions made two years earlier do.

So we start with your code, not with an estimate. The discovery week shows which of those decisions can still be undone cheaply and which cannot.

§ 01 — What we do

Three practices that have to work together.

Most engagements begin in one practice and end up using two. The app needs a backend that holds; the backend needs a model that stays inside its budget.

01

High-load platforms

GoJavaC#.NETKotlingRPCProtobuf 3KafkaNATSNATS JetStreamRabbitMQPostgreSQLMongoDBClickHouseRedisElasticsearchk8s

Systems measured in requests per second. Event-driven cores, sharded storage, idempotent writes, and headroom we prove with load tests before your users test it for us. Under overload they shed work on purpose instead of falling over.

Typical: 5–8 engineers, 4–6 months, SLO agreed in writing

  • 01Architecture review and migration plans
  • 02Payment, booking and streaming cores
  • 03Zero-downtime migration: dual writes, backfill, cut-over
  • 04A load rig that reproduces your peak, plus failure drills
  • 05SLO design, observability, on-call runbooks

02

Client applications

SwiftSwiftUIKotlinComposeKMPWinUIC#.NETQtC / C++Java

Native iOS, Android, macOS and Windows, with a shared core where it pays for itself. Offline-first data, telemetry from the first build, releases on a fixed cadence.

Typical: 3–5 engineers, 3–5 months to store, release every two weeks

  • 01Windows 10/11, macOS, Linux, Android, iOS/iPadOS, watchOS
  • 02Store releases, CI, staged rollouts
  • 03Crash, latency and funnel telemetry

03

AI in production

PythonPyTorchvLLMTritonTensorRTONNXRayRAGMCPpgvectorQdrantLangGraphMLflow

Retrieval, agents and model serving with the unglamorous parts finished: evaluation sets, guardrails, cost ceilings, latency budgets. A demo takes a weekend; an SLA takes longer. We measure quality on your data before launch and keep measuring it after.

Typical: 2–4 engineers, 8–12 weeks to the first production slice

  • 01Retrieval and search over your own data
  • 02Agent workflows with human checkpoints
  • 03Evaluation suites that gate every model change
  • 04A fallback path for when the provider is down
  • 05Self-hosted inference and GPU cost control

§ 02 — Examples

The problems we are usually called for.

Written from patterns across our projects, not from one client. What people arrive with, what is usually behind it, and what we change.

“Every sale ends in an incident, and there is no time to rewrite.”

We don't rewrite everything. The hot path moves into its own core, writes become safe to retry, and the migration runs live while the old code keeps serving until the last day.

Platforms · usually 5–8 engineers, 4–6 months

“A release takes a quarter and nobody can say why.”

It is rarely the code. It is manual regression and a branch nobody dares merge. We split the release train from feature work, automate the regression pack and put the risky parts behind flags.

Client applications · usually 3–5 engineers, 3–5 months

“The AI demo impressed everyone and never shipped.”

Because a demo does not count money or answer for mistakes. We add an evaluation set, a cost ceiling, a fallback path and a human in the loop where an error is expensive.

AI in production · usually 2–4 engineers, 8–12 weeks

What you seeWhat is underneathWhat we do

Every sale ends in an incident

Synchronous writes to one database, duplicate payments, manual rollback

Event-driven core, idempotent writes, migration with no maintenance window

The app ships once a quarter

Manual regression, two codebases, a branch nobody dares merge

Shared Kotlin core, automated regression, a release train every two weeks

Support cannot clear the queue

Knowledge in people's heads, answers not reproducible, the AI pilot never shipped

Retrieval over your own data, evaluations on every release, self-hosted inference

Also on the list

  1. 01

    Search slows down as the catalogue grows

    Ranking off the primary database, a budget on every query path

    3–4 mo
  2. 02

    Telemetry outgrew its database

    Ingest into a stream, history into a column store, reports without timeouts

    3 mo
  3. 03

    Two codebases instead of one team

    A shared KMP core, native UI where the platform expects it

    3–5 mo
  4. 04

    Nobody left who wrote the system

    An audit, written decisions, and a team that can carry it

    from 1 wk

§ 03 — How it runs

Five steps, starting with one week.

The discovery week is a paid engagement of its own, €12k fixed. It produces an architecture, a ranked list of risks and a price. If any of the three disappoints you, it ends there and you keep the documents.

  1. 01week 1

    Discovery week

    Your code, your load graphs, your deadline. We read before we talk.

  2. 02end of week 1

    Architecture and estimate

    One document: target design, migration path, team shape, price range.

  3. 03every 2 weeks

    Two-week iterations

    Increments on staging, demonstrated live, with the burn chart attached.

  4. 04before launch

    Load testing and launch

    Soak tests, failure drills, a rehearsed rollback. Launch day should be uneventful.

  5. 05ongoing

    Run or hand over

    We stay on call, or we train your team and leave the runbooks with them.

What you hold after the first week

  • Target architecture, and what we would keep
  • Risk register, ranked by blast radius
  • Capacity model for the next 18 months
  • Team shape, timeline and price range
  • A go / no-go decision you can take to your board
  • All of it in your repository, yours to keep

§ 04 — The team

The people who design it are the people who keep it running.

Forty engineers on staff. You interview the people who will write the code, they stay on the project until it is finished, and nobody is moved off mid-way to cover a gap elsewhere.

Backend and platform
18
Mobile and desktop
9
AI and data
7
SRE, QA, design
6

Principle 01

Senior engineers

Median nine years of experience. Junior engineers learn on our internal tools, not on your production.

Principle 02

On call with you

The engineers who built a system carry the pager for it.

Principle 03

Decisions in writing

Every architecture decision gets a written record in your repository, not a message in a chat thread.

Principle 04

No lock-in

Your cloud, your repositories, your CI. Leaving us should take a calendar invite, not a migration.

§ 05 — Engagement models

A team, a project, or one specialist.

Pick the shape that fits the work, not the other way round. Switching models mid-engagement is normal and does not restart anything.

ModelBest forTeamCommitmentCadenceFrom
Fixed-scope projectA defined launch with a hard date4–8 people3+ monthsMilestones, fixed price per phase€100k / phase
Dedicated teamOwning a product line end to end5–12 people6+ monthsMonthly, 30-day notice€9.5k / engineer / mo
Staff augmentationNamed gaps in your own squads1–5 people3+ monthsHourly, weekly timesheets€58 / hour

Included in every model

  • Rates are per engineer at 160 billable hours a month
  • Delivery lead and QA, not billed separately
  • Security review before each release
  • NDA and a GDPR data-processing agreement
  • Full IP transfer on payment
  • Written status weekly, steering monthly

§ 06 — Stack we answer for

Conventional tools, used well.

The tool follows the problem: what the load, the deadline and your existing systems actually require. Anything unusual comes with a written reason and an exit plan.

Backend

GoJavaKotlinC#.NETC / C++PythonNode.jsRustSpring BootASP.NET CoregRPCProtobuf 3GraphQL

Web and frontend

TypeScriptVue.jsNuxtNext.jsReactNode.jsViteWebSocketSSR

Data and messaging

PostgreSQLMongoDBClickHouseElasticsearchRedisKafkaNATSNATS JetStreamRabbitMQDebeziumAirflow

Infrastructure

KubernetesHelmDockerTerraformArgoCDGitHub ActionsAWSGCPBare metalPrometheusGrafanaOpenTelemetry

Mobile and desktop

iOSiPadOSwatchOSmacOSWindows 10/11AndroidLinuxSwiftSwiftUIKotlinComposeKMPC#.NETWinUIQtFlutter

Load and quality

k6GatlingJMeterTestcontainersPlaywrightpprofFailure drills

AI and ML

PyTorchvLLMTritonTensorRTONNXRayRAGMCPpgvectorQdrantLangGraphMLflowClaude / OpenAI APIs

§ 07 — In the open

What we publish.

Libraries we extracted from client work and notes we wrote while solving something. Everything we publish lives in one place:

github.com/altessa-s

§ 08 — How we decide

Architecture decisions are written down.

Not a document nobody reads: a short record per decision, in your repository, reviewed like code. A year later the question "why is it built this way" has an answer.

  1. 01

    The fork is written down before it is taken

    Options, what each one costs, and what we would give up. Two paragraphs, not a deck.

  2. 02

    It is reviewed like code

    The record goes through a pull request. Your architect can argue with it before anything is built, not after.

  3. 03

    The reason is recorded, not just the choice

    Constraints, load assumptions and the date. Most bad rewrites start because nobody remembers the constraint.

  4. 04

    It says when to revisit

    Every record carries the condition that would invalidate it — a load threshold, a cost ceiling, a vendor change.

§ 09 — Where we say no

The work we turn down.

  • We don't quote without access to the code

    An estimate from a slide deck is a guess, and one of us always pays for it.

  • We don't sell juniors as seniors

    If we can't staff a project with senior engineers, we say so and pass on it.

  • We don't rewrite for the sake of rewriting

    Twice we have recommended leaving a system alone and walking away. It was cheaper for everyone.

  • We don't build websites or landing pages

    No marketing sites, no throwaway apps built to a deadline and abandoned. If it isn't a system someone has to keep running, we are the wrong team.

  • We don't hold you hostage

    Your cloud, your repositories, 30 days' notice and runbooks on the way out.

§ 10 — Questions we get early

Ask the awkward ones first.

If your question is not here, put it in the form below. An engineer answers, in writing.

The discovery week begins within ten business days of a signed statement of work, and the team is staffed by the end of that week from our own payroll. If we cannot staff it with senior engineers, we say so and decline the project.

Tell us what breaks under load.We will tell you what we would do about it.

Request a first read

§ 11 — Contact

Write to us.

Describe the system and what is going wrong with it. An engineer reads it and answers within three business days.

What happens next

Day 1–3
An engineer reads your note and replies in writing with a first read: what we think is going on and what we would look at first.
If useful
A short call with that same engineer, at a slot you pick. Only if the written answer leaves something open.
If it fits
We scope the discovery week: one week of reading your code, €12k fixed, architecture and price at the end of it.
Engagement model

NDA on request. Your data stays in the EU. We answer ourselves, with no automated sequences.

This site is protected by reCAPTCHA; the Google Privacy Policy and Terms of Service apply.

Prefer to answer a few questions instead of writing a note?Fill in the project brief