Least privilege by default
Access is granted per role and per environment. Credentials are stored in managed secret systems and rotated, never embedded in source or configuration files.
00Software & infrastructure engineering
Systems built
to keep
running
RIVER KG is an IT company working on custom software, cloud architecture, data platforms, and secure infrastructure. We take responsibility for how systems behave under load, over years, and in the hands of the people who operate them.
01Company overview
What we do
We design, build, and operate software and infrastructure for organisations where downtime, incorrect data, or a failed migration has real consequences.
Projects usually begin with a system that already exists: a service that has outgrown its original design, an integration that breaks silently, a reporting process that nobody trusts. Our first task is to describe that situation accurately.
From there we work in defined increments, with architecture written down, decisions justified, and each release observable in production. The result is a system the client owns entirely — code, infrastructure definitions, and documentation.
02Core capabilities
Four disciplines, one delivery model
- 01Applied software engineering
- Backend services, APIs, and application logic written for long maintenance horizons: explicit boundaries, typed contracts, and tests that describe behaviour rather than implementation.
- 02Cloud and platform architecture
- Network topology, compute strategy, storage tiers, and cost models designed together, so that infrastructure decisions remain reversible as the workload changes.
- 03Data engineering
- Ingestion, transformation, and modelling pipelines with defined schemas, lineage, and validation rules, so that reported numbers can be traced back to their source.
- 04Operations and reliability
- Observability, alert design, deployment automation, and recovery procedures rehearsed before they are needed rather than written after an incident.
03Featured technology
Architecture first
Before code is written, the system is drawn: services and their responsibilities, data ownership, synchronous and asynchronous paths, failure domains, and the boundaries where information crosses trust levels.
Diagrams are kept current with the implementation. When they diverge, the diagram is corrected rather than abandoned — it remains the shared reference during incidents and onboarding.
04Services overview
Ten areas of work
Engagements combine several of these areas. The mix depends on the state of the existing system and the constraints around it.
- 01
Custom software development
Domain-specific systems built from requirements, not from templates.
- 02
Web application development
Accessible, fast interfaces with server-rendered delivery where it matters.
- 03
Cloud architecture
Environment design, networking, scaling policy, and cost boundaries.
- 04
System integration
Contract-first connections between internal systems and third-party services.
- 05
Cybersecurity engineering
Threat modelling, access control, secrets management, and hardening.
- 06
Data platforms and analytics
Pipelines, warehouses, and models that stay consistent over time.
- 07
DevOps and infrastructure
Reproducible environments, delivery pipelines, and infrastructure as code.
- 08
Technical consulting
Architecture review, technology assessment, and delivery planning.
- 09
Software modernisation
Incremental replacement of legacy components without freezing the business.
- 10
Ongoing technical support
Monitoring, maintenance, and controlled evolution after launch.
05Industries & business challenges
Recurring problems we are asked to solve
| Context | Typical problem | Engineering response |
|---|---|---|
| Logistics and operations | Scheduling and tracking data spread across spreadsheets and disconnected tools. | Single operational data model, event history, and interfaces built around daily working rhythms. |
| Financial and regulated services | Manual reconciliation and audit trails that cannot be reconstructed reliably. | Append-only records, deterministic calculations, and reporting derived from one source. |
| Industry and manufacturing | Machine and sensor output collected but not usable for decisions. | Ingestion pipelines, normalised measurements, and dashboards tied to defined thresholds. |
| Healthcare and public sector | Sensitive data handled by systems with unclear access boundaries. | Role-based access, encryption in transit and at rest, and documented data flows. |
| Software product companies | Delivery slowing down as the codebase and infrastructure grow. | Modular boundaries, automated pipelines, and measurable release health. |
06Development approach
How the work proceeds
01Understand
We start with the existing system, its constraints, and the people who operate it. Documentation of the current state comes before proposals for a future one.
02Model
Domain concepts, data ownership, and failure modes are written down and reviewed. Disagreement at this stage is cheaper than disagreement in production.
03Build in slices
Each increment is deployable and observable. Progress is demonstrated by working software in a real environment, not by percentage estimates.
04Operate
Instrumentation, runbooks, and handover material are produced alongside the code, so that the system can be run by the team that owns it.
07Technology expertise
Tools we work with
Technology choices follow the problem. We prefer widely supported, well-documented components over novelty, and we avoid dependencies that cannot be operated by the client's own team.
- Languages
- TypeScript, Python, Go, Java, SQL
- Frontend
- React, server-side rendering, design systems, accessibility
- Backend
- REST and RPC services, event-driven messaging, background processing
- Data
- PostgreSQL, columnar warehouses, streaming ingestion, dbt-style modelling
- Infrastructure
- Containers, Kubernetes, serverless runtimes, infrastructure as code
- Delivery
- CI/CD pipelines, automated testing, staged rollouts, observability stacks
08Security & quality principles
Non-negotiable practices
Verified builds
Dependencies are pinned and scanned. Builds are reproducible, artefacts are traceable to a commit, and deployments are recorded.
Reviewable change
Every change passes review and automated checks. Rollback paths exist before a release, and migrations are written to be reversible where the data model allows.
Defence in depth
Validation at boundaries, encryption in transit and at rest, network segmentation, and logging designed for investigation rather than volume.
09Project workflow
From first review to steady operation
Phase 01
Discovery
Systems review, constraints, risks, and a written scope with open questions listed explicitly.
Phase 02
Architecture
Data model, interfaces, environments, and non-functional requirements agreed in writing.
Phase 03
Implementation
Iterative delivery into a staging environment with review at the end of each increment.
Phase 04
Hardening
Load behaviour, security review, failure testing, and documentation completion.
Phase 05
Release
Staged rollout, monitoring in place, and a defined rollback procedure.
Phase 06
Operation
Maintenance, observability review, and planned improvement cycles.
10Key facts
How RIVER KG operates
- Engineering-led
- Work is scoped, estimated, and delivered by the engineers who build it.
- Written architecture
- Every project has documented decisions with the reasoning preserved.
- English working language
- All communication, documentation, and code review in English.
- Source ownership
- Clients hold the repositories, infrastructure accounts, and credentials.
We publish no unverified figures, awards, or client names on this website.
11Working with RIVER KG
Why organisations choose us
Specificity over generality
We prefer a narrow system that fits the process precisely to a broad platform that fits nothing well. Requirements are reduced to what the organisation actually does.
Direct engineering contact
The people writing the code take part in the discussions. There is no translation layer between technical reality and project reporting.
Operational thinking from the start
Monitoring, backups, permissions, and cost behaviour are part of the design phase, not tasks postponed until after launch.
Transferable results
Documentation, infrastructure definitions, and code are structured so another team could continue the work without a rewrite.
12Company statement
Software is infrastructure. It should be documented, observable, recoverable, and understood by the people who depend on it.
13Contact information
Reach us
- Company
- RIVER KG
- nelliebutl26@gmail.com
- Website
- riverkg.com