Architecture stays editable
You do not have to be right about everything up front. The architecture can keep changing during development and long after it — adding and removing parts is a normal operation, not a rewrite.
Systems engineering
We build systems that stay alive.
Drawn like architecture, built like an organism. Data flows through it live, models learn as it flows, every part — a microservice on Kubernetes — replaceable on its own. Complexity grows by +n, never ^n: you can still change anything, years later.
$ curl -s cyberconspect.com/spec
we: architects who build · senior engineers only
pipeline: analysis → architecture → k8s → containers
→ integration → observability → qa → support
team: one
The thesis
Software doesn't die of crashes. It dies when people stop changing it.
Every system reaches a size where its parts know too much about each other. From there, each small change touches everything, estimates stop making sense, and one day — nobody announces it — the safest release becomes no release. That is the death we design against, from the first line.
Tightly coupled — ^n
Every part knows about every other part. Adding one multiplies the combinations you have to hold in your head, test and keep working. Eventually the cheapest option is to stop changing the system.
Microservices on Kubernetes — +n
Each part is small, owns one job, and talks through a contract. Adding one adds its own complexity and nothing else. Removing one subtracts exactly the same amount.
One decision does need to be right
The technology stack for your particular kind of product — which database above all, and what the data actually looks like. That choice is expensive to reverse, so it is the part we slow down for.
Scale becomes quantitative
Once parts are small and uniform, a bigger system is more of them rather than a harder one. Growth turns into a question of count and capacity — something you can plan and budget for.
The anatomy
Built like a body. Replaceable like a machine.
The parts of a living system map cleanly onto the parts of ours — with the one advantage biology never offers: every organ can be swapped without surgery on the rest, and every organ can also live on its own.
Kubernetes
Carries the weight so nothing else has to. Scheduling, isolation, metrics and logs are part of the body plan — not bolted on after the first fall.
Small services
Each does one job and fits in one head, written in whatever language fits it — Go, Python, TypeScript. Adding one costs +n. Removing one costs the same.
The data flow
Deployments, jobs and job pipelines keep a steady stream moving through the system — under load, with backpressure, without silent loss.
Models that learn live
Our own ML runs as ordinary containers — training on the stream as it flows, predicting in real time, switchable off in one command.
Monitoring & alerting
The system watches itself: metrics, logs and alerts that reach a human before a customer notices anything at all.
Answers where you work
Results delivered into the chat and tools your people already use — bots and assistants speaking from the system, not from imagination.
The other half
Builders alone don't make a landmark.
On a large construction project, the crew is not what separates a landmark from a warehouse — the architects are. Software is the same: correct is not yet well-designed. Alongside the engineering we bring the architect's eye — a practical, creative vision of how the system is shaped, how it feels to use, and how it fits the business around it. One team carries the full set of drawings:
cyberconspect — project set
scale 1:1 · rev A
S-01
Business needs analysis
The simple questions that decide what the system must be — asked by us, answered by you.
S-02
Architecture & design
The shape of the thing: services, data flow, interfaces — drawn before it exists.
S-03
Cluster deployment
Kubernetes set up and configured across as many hosts as the workload needs.
S-04
Container development
Every service — ML models included — built fast and stable, in the language that fits it.
S-05
Integration & configuration
Wired into your tools and your existing products — AI and chat bots included.
S-06
Quality testing
Contracts, flows and load — verified before launch, guarded in CI after it.
S-07
Maintenance & support
The system handed over complete and cared for afterwards, for as long as you want.
Method
We ask. We draw. We grow it. You own it.
The full method lives on the approach page. The honest version fits in four sentences.
01 · ASK
Questions, not a brief
Simple questions about how the work happens today. You answer them — writing the specification is our job, not yours.
02 · DRAW
The stack and the shape
Technology chosen for your data — the database above all — and the architecture sketched around the main flow. The one stage worth slowing down for.
03 · GROW
One container at a time
Services and models arrive as small containers — tested at the contracts, deployed across the cluster, watched from day one.
04 · OWN
Yours, entirely
The complete system handed over. Support afterwards if you want it — never because you are stuck with us.
How we talk to you
The questions are simple. The systems are not.
You should not have to describe a system in engineering terms to get one. You know your business; we turn what you know into architecture. Out of plain answers, quantitatively large systems get built.
We ask
Where does this number come from today, and who touches it before it is final?
You
It comes off the exchange in the morning, an analyst corrects two fields by hand, then it goes in the report.
We ask
How bad is it if it is an hour late? How bad if it is wrong?
You
An hour late is survivable. Wrong is not — we would be trading on it.
We ask
Who needs to see it, and where are they when they need it?
You
Four people, and honestly they live in the company chat, not in dashboards.
Result
Three answers, and the architecture is already implied: an ingest service, a correction step with an audit trail, a validation gate that fails loudly rather than quietly, and delivery into chat instead of another dashboard nobody opens.
What we cover
The whole spectrum — infrastructure, product, and the seams between them.
We take responsibility for the complete system rather than a slice of it, because the expensive problems live exactly where the slices meet.
Infrastructure
Cluster & platform
Kubernetes across as many hosts as needed, wired into one cluster, described in code.
Architecture
Microservice design
Service boundaries, contracts, and the data flow that connects them.
Product
The system itself
The services that do the work, each written in the language that suits it best — fast, stable, maintainable.
Quality
Testing at every level
Contracts, flows and load — verified before launch, guarded in CI after it.
Data
Pipelines & jobs
Deployments, cron and job pipelines, inter-service communication, steady throughput.
Interfaces
UI as part of the whole
Designed, not just assembled — built where the product needs it, always as part of the system.
AI
Integration into your tools
Our own ML models and connected AI — trained and predicting in real time on the live stream, delivered where people work.
Operations
Monitoring & alerting
Metrics, logs and alerts that page a human before a customer notices.
Integration
Your existing products
The systems you already run, connected in rather than replaced for the sake of it.
After launch
Handover & support
The cluster is handed to you complete. Ongoing support is available, never required.
Not us
Standalone UI work
We do not take website or interface projects detached from a system we are building.
Not us
Embedded & mobile
Firmware and native mobile apps are a different craft — not ours.
Not us
Staff augmentation
We deliver and answer for whole systems. We do not rent out engineers by the seat.
One example
Trading analytics for the energy market.
The approach is domain-agnostic; the systems are not. Here is what it looks like applied to one of them.
In development
Energy-market trading analytics for hodie.cz & elrnd.com
An analytical and trading platform for energy markets: continuous ingest of market and operational data, computation of curves, signals and forecasts over it, and delivery of the result to the people who act on it.
Every stage is a small service on Kubernetes with a versioned contract. Over the last quarter the system gained four services and lost one, without a single broken contract — which is the whole argument on the chart above, in practice.
- Grew by addition — a forecasting service and a chat notifier were added months after launch, touching nothing else.
- Independent scaling — ingest, computation and delivery scale on their own signals and fail on their own too.
- Answers where people are — results pushed into the chat tools the team already lives in, not a dashboard they have to remember.
- Operable by a small team — one view answers “is it healthy”, and every alert points at a runbook.
- Client
- hodie.cz · elrnd.com
- Market
- Energy
- Domain
- Trading analytics
- Status
- Active development
- Runtime
- Kubernetes
- Architecture
- Microservices
- Role
- Architecture, build & operations
You do not need a specification to start.
Tell us roughly what the business does and where it hurts. The questions are our job — and after a first conversation you will have a straight read on scope, risk and what a first phase would look like.