The problem before the technology
We do not begin from a tool. We begin by understanding what is failing, whom it affects, and what it costs to leave the situation as it stands.
Software and systems engineering
From requirement to system in operation.
We accompany organisations from the definition of the requirement through to the continuous operation of the system: analysis, architecture, construction, infrastructure, security and quality assurance, under a single line of technical accountability.
komorebi (木漏れ日) denotes sunlight filtered through leaves. It is a precise image of the work: letting clarity through the complexity.
The process
Six stages between the brief and the running system.
No stage is skipped and none is billed twice. Hover over each one to see its scope.
- 01
Requirements
We identify the problem, not the solution accompanying it.
Interviews with those who carry out the process and those who approve it. Stakeholder map, real constraints and acceptance criteria documented before the first line of code.
- 02
Analysis
We distinguish what is required from what was requested.
Domain modelling, risk identification and a substantiated estimate: scope included, scope excluded, and decisions deliberately deferred.
- 03
Architecture
We resolve first whatever proves expensive to change later.
Boundaries between components, integration contracts, data model and infrastructure. Every decision is recorded alongside the alternative considered and its rationale.
- 04
Construction
Code legible to a team other than the one that wrote it.
Short, verifiable increments, peer review, and observability built in from the first deployment rather than added once the system is already failing.
- 05
Quality assurance
What is not verified is not finished.
A layered test strategy, end-to-end coverage of business-critical processes, and an integration pipeline that halts any regression before production.
- 06
Operations and security
A system that defends itself and records what occurred.
Threat modelling, hardening, credential management, continuous monitoring and a response procedure rehearsed in advance of the incident.
The six stages describe the full path, not a single-pass schedule. They are traversed on every iteration at whatever scale applies: a two-week increment passes through all six, as does an entire project, at differing depth.
Disciplines
Ten disciplines that rarely coexist within a single organisation.
Here they do. That is why the architecture accounts for security from the design stage, operations are planned alongside the product, and testing is not defined at the end of the project.
Product and architecture
- 01
Analysis and requirements
Understand before building.
The costliest mistake in a project is made before the first line of code: building correctly something that was never required.
- Discovery and interviews
- Domain modelling
- Acceptance criteria
- Scope and prioritisation
- 02
Software architecture
The decisions everything else rests upon.
We define boundaries, contracts and the data model, and place the reasoning on record. A system is understood through its decisions, not its diagram.
- Component design
- Interfaces and contracts
- Data modelling
- Decision records (ADR)
- 03
Software development
Build what was agreed, without deviation.
Bespoke product, integrations and modernisation of legacy systems. Web applications, backend services and data processing.
- Web applications
- Services and APIs
- Integrations
- Legacy modernisation
Platform and operations
- 04
Infrastructure architecture
Where the system resides and what it costs to sustain.
Cloud, networking and infrastructure as code, sized for the organisation's actual operation rather than a theoretical scenario.
- Cloud design
- Infrastructure as code
- Networking and continuity
- Cost control
- 05
DevOps and reliability (SRE)
Deliver frequently and sustain the service.
Delivery automation, service level objectives, and operations assisted by artificial intelligence agents that monitor, diagnose and propose the remedy before an incident escalates.
- Continuous integration and delivery
- Service level objectives
- Observability and alerting
- AI-assisted operations
- 06
Configuration management and SCM
Traceability of every change back to its origin.
Branching strategy, versioning, repository governance and release management: every artefact in production can be traced to the change that produced it.
- Branching strategy
- Versioning and releases
- Repository governance
- Traceability and audit
Assurance and defence
- 07
Automated quality assurance
The net that holds what review does not reach.
Tests that run automatically on every change and that fail when they ought to. The precondition for deploying with confidence.
- Test strategy
- End-to-end and regression
- Load testing
- Blocking continuous integration
- 08
Security and cybersecurity
Anticipate the reasoning of whoever attempts to breach the system.
Security built into the design rather than audited at project close, when remediation proves unfeasible or disproportionately expensive.
- Threat modelling
- Code and dependency review
- Hardening and credentials
- Compliance and evidence
Artificial intelligence and hardware
- 09
Applied artificial intelligence
Systems that interpret the physical world and turn it into data.
Computer vision and language models integrated into the product: an image or a document enters the system and structured, validated information becomes available to the application, with no manual transcription.
- Computer vision
- Data extraction and structuring
- Language models in product
- Process automation
- 10
Connected hardware and embedded systems
From the sensor to the screen, with nothing in between.
Firmware on Arduino and Espressif platforms, telemetry, and the cloud platform that receives it. The data originates on the device and concludes in the application.
- Firmware and microcontrollers
- Arduino and Espressif
- Telemetry and connectivity
- Cloud integration
Models
Choose a starting point.
Six site models covering the majority of briefs. Select the one closest to what you have in mind and send it to us on WhatsApp: we define the scope from there.
Select a model to continue.
The models are a starting point, not a closed template: design, content and features are adjusted to your case. Timelines are indicative and confirmed after analysis.
Method
How we work.
We apply agile methodologies — Scrum or Kanban according to the nature of the work and the maturity of the team — with short iterations and a verifiable increment at the close of every cycle. These are the six commitments that are not negotiable.
Short iterations, steady cadence
We work in one- to two-week cycles at a constant rhythm. At the close of each there is working software your team can review, not a progress report.
Priorities revisited every cycle
We maintain a prioritised backlog together with your team and reorder it according to what has been learned. The scope of each cycle is negotiable; the acceptance criteria and the technical quality are not.
Permanent visibility
The board, the actual progress and the impediments are available at all times. Meetings exist to decide, not to report what could already be consulted.
Decisions on the record
Every architectural decision is recorded with its context and the alternative considered. The question “why was it resolved this way?” always has an answer.
Complete handover
The code, the infrastructure, the documentation and the knowledge remain with your organisation. We work so that the technical dependency is temporary.
Tooling
What we build with.
The tool is selected according to the problem. These are the ones we use routinely.
- Languages
- TypeScriptPythonGoRustJavaC / C++SQL
- Applications
- ReactNext.jsNode.jsFastAPISpring
- Design
- FigmaSketchPenpotFramerUizard
- Agile management
- ScrumKanbanUser storiesRelative estimationRetrospectives
- Data
- PostgreSQLRedisKafkaClickHouseTimescaleDB
- Infrastructure
- LinuxAWSGCPKubernetesDocker
- Infrastructure as code
- TerraformOpenTofuPulumiAWS CDK
- Operations
- PrometheusGrafanaOpenTelemetryArgo CDPagerDuty
- Configuration and SCM
- GitGitHubGitLabConventional CommitsSemVer
- Quality
- PlaywrightVitestpytestk6GitHub Actions
- Security
- OWASP ASVSSAST / DASTVaultTrivyOIDC
- Artificial intelligence
- ClaudeOpenCVPyTorchONNX Runtime
- Hardware
- ArduinoESP32ESP8266PlatformIOFreeRTOSMQTT
Contact
Tell us what you need.
Three questions to understand the context. The detailed conversation follows.