I build the custom software a business runs on, test the networks it runs on, design the interfaces people use, and model the parts that get made — held to one engineering standard, for clients across Europe.
Different surfaces, same discipline — measure first, build the minimum that holds, document what you hand over.
Internal tools and process automation built around how your team actually works — replacing the spreadsheets, handoffs, and manual steps that quietly cost hours every week.
Network penetration testing and hardening that gives you an honest, prioritised picture of your exposure — scoped tightly, documented fully, handled under NDA as standard.
Fast, precise, standards-built websites — like the one you're reading now. Designed and engineered as one piece, not a theme bent to fit.
Custom 3D models and print-ready parts — from prototype to finished piece, modelled to spec and to tolerance.
Cost, time, or exposure — and the smallest thing that solves it. Fixed and agreed before any build or test begins.
Software ships in increments you can see. Security follows a documented methodology. You're never guessing what's happening.
A working system, clear documentation, and a direct line back to me. Not a ticket queue and not a black box.
I work across software, security, web, and physical fabrication because to me they're one discipline wearing four faces — precise systems, built and verified to a standard, whether they're made of code, network rules, pixels, or plastic.
[Replace this paragraph with your own story: the engineering background, what led you to running this independently, and what you want a prospective client to understand about how you think before they ever get on a call.]
Get in touch →The engineering, security, web and infrastructure norms this practice follows — the professional backbone under every project, aligned with EU and international standards.
The international product-quality model (2023 revision) that defines software quality across nine characteristics — functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability and safety — each with measurable sub-characteristics.
We use ISO/IEC 25010 as the reference vocabulary for defining and evaluating quality on every build — desktop PySide6/Qt tools, FastAPI services, embedded STM32 firmware and ML pipelines. It anchors how we discuss non-functional requirements with clients (reliability, performance, maintainability) rather than leaving 'quality' undefined.
Adopted verbatim as the EN ISO/IEC 25010 European Norm by CEN/CENELEC, giving EU clients a common, harmonised quality reference.
The umbrella standard (2017 edition) establishing a common framework of processes, activities and tasks across the whole software life cycle — from acquisition and requirements through development, operation, maintenance and disposal.
We follow 12207's process framework, scaled to a solo practice: clear requirements capture, versioned development, verification, maintenance and defined handover/decommissioning. It keeps small engagements disciplined without imposing enterprise-scale bureaucracy.
Published as EN ISO/IEC/IEEE 12207 and widely referenced in EU public-sector and regulated software procurement as the baseline life-cycle vocabulary.
The internationally recognised standard (2015 edition) specifying requirements for a quality management system: a process-based, risk-aware approach focused on consistently meeting client and regulatory requirements and improving over time.
We are not certified to ISO 9001, but we apply its principles — documented processes, traceable requirements-to-delivery records, corrective-action follow-up and a plan-do-check-act mindset — so that a one-person practice still delivers with the consistency clients expect.
The most widely held management-system standard across the EU; its process and risk-based-thinking model underpins procurement expectations in most member states.
A public specification for version numbers in MAJOR.MINOR.PATCH form, where each increment carries defined meaning — incompatible API changes, backward-compatible additions, and backward-compatible fixes respectively — with rules for pre-release and build metadata.
We version deliverables — Python packages, FastAPI service releases, single-EXE Windows builds and firmware images — with Semantic Versioning, so clients can read compatibility and upgrade impact straight from the number. Released versions are immutable; any change ships as a new version.
A vendor-neutral, jurisdiction-independent convention; adopted directly (no EU-specific variant needed) and expected across European open-source and dependency ecosystems.
A lightweight convention layered on commit messages (type, optional scope, description, body, footer) that makes history machine-readable, dovetails with Semantic Versioning and enables automated changelogs and version bumps.
We apply Conventional Commits in Git so history is auditable and release notes and version bumps can be generated automatically. Combined with our CI pipelines (build, lint, test on each push), it gives even solo projects a clean, reviewable change record.
A neutral open convention with no regional variant; interoperable with the tooling EU development teams and open-source projects already use.
The multi-part international standard for software testing, covering concepts and definitions, test processes, test documentation, test techniques and keyword-driven testing — applicable to any organisation and any life-cycle model.
We follow 29119's concepts and techniques to structure testing proportionately: unit and integration tests for Python and C/C++ code, API tests for FastAPI services, and documented test cases for embedded and ML components. Test design is risk-based, not box-ticking.
Adopted as the EN ISO/IEC/IEEE 29119 series, providing EU clients a harmonised, internationally agreed testing reference.
The standard for integrating security throughout the application life cycle, defining organisation- and application-level frameworks and processes so that security is built into how software is developed, acquired and operated — not bolted on afterwards.
We fold security into the SDLC as 27034 intends: threat-informed design, dependency and component vetting, secrets handling, and hardened deployment (nginx, HTTPS, ufw/fail2ban, SSH key-only, systemd hardening). Our penetration-testing background feeds directly back into how we build.
Part of the ISO/IEC 27000 family that underpins EU information-security expectations and complements GDPR's security-by-design obligation (Art. 25/32).
An open standard providing a structured, leveled catalogue of security requirements for verifying web applications and APIs — covering authentication, authorisation, session management, data protection and common code vulnerabilities — usable for both secure development and security testing.
We use ASVS as both a build checklist and a test basis: web and API work is verified against its requirements, and our penetration-testing engagements produce evidence-first findings mapped to ASVS controls (a discipline behind our publicly disclosed HackerOne finding).
A vendor-neutral, freely available standard widely referenced across EU application-security assessments; supports demonstrating GDPR-aligned security-by-design for web systems.
The internationally recognised standard for establishing, operating and continually improving an information security management system, covering risk treatment, access control, cryptography and operational security.
We are not certified, but we run engagements aligned with ISO/IEC 27001 controls: scoped handling of client data and evidence, encrypted storage and transit, least-privilege access, and defined retention and disposal of test artefacts.
The de facto baseline for the risk-management and security-measures obligations that NIS2 places on essential and important entities.
An open standard defining testable security requirements for web applications and APIs across authentication, session management, access control, cryptography and input handling, organised into graded verification levels.
We use ASVS as the requirements baseline for application assessments and secure-development reviews, mapping findings to specific ASVS controls so clients get verifiable coverage rather than an ad-hoc checklist.
Provides concrete, auditable security requirements that support the secure-by-design duties introduced by the EU Cyber Resilience Act.
A comprehensive, community-maintained methodology for testing web applications and services, with over a hundred referenced tests spanning information gathering, authentication, authorisation, session and business-logic flaws.
We follow WSTG as our web testing methodology, tracking coverage against its stable test IDs so each engagement is reproducible and every in-scope area is accounted for in the report.
Underpins the technical assurance expected of network and information systems under NIS2.
A consensus awareness document ranking the most critical categories of web application security risk, widely used to prioritise defensive effort and developer education.
We apply the Top 10 as a shared vocabulary in reporting and developer guidance, using it to frame priorities while relying on ASVS and WSTG for exhaustive depth beyond the headline categories.
A common reference point for the risk-based security posture NIS2 and the CRA expect of digital products and services.
A community framework defining the phases of a penetration test, from pre-engagement scoping and intelligence gathering through threat modelling, exploitation, post-exploitation and reporting.
We structure engagements along the PTES phases: agreed rules of engagement up front, evidence captured at each step using the Kali toolchain, and business-impact-focused reporting with clear remediation guidance.
Supports the structured, documented testing evidence that regulated entities need under NIS2 supply-chain and assurance requirements.
A U.S. federal guide to planning and conducting technical security testing and assessment, covering review techniques, target identification and analysis, and vulnerability validation.
We follow SP 800-115 for assessment planning and rules of engagement: defined scope and objectives, documented techniques and their limitations, and validation of findings to reduce false positives before reporting.
A widely accepted technical-testing reference that complements the assurance expectations of NIS2 and the CRA.
An open FIRST-maintained framework for communicating vulnerability severity through Base, Threat, Environmental and Supplemental metric groups, producing a comparable numeric score.
We score findings with CVSS v4.0 and, crucially, contextualise the environmental metrics to the client's actual deployment so severity reflects real business risk rather than a generic base number.
Provides the consistent severity language useful for the incident and vulnerability reporting obligations under the CRA and NIS2.
The international standard giving guidance on how to receive vulnerability reports and publish remediation information, defining coordinated, responsible disclosure practice.
We follow coordinated disclosure aligned with ISO/IEC 29147, backed by real experience: a publicly disclosed HackerOne finding handled through responsible reporting and agreed remediation timelines.
Directly supports the coordinated vulnerability disclosure and reporting duties introduced by the CRA (reporting from September 2026) and NIS2.
The EU directive imposing risk-management, supply-chain security and incident-reporting obligations on essential and important entities across critical sectors.
We help EU clients understand where our testing and hardening work supports their NIS2 duties — risk-based assessment, supply-chain review and incident readiness — without claiming to certify their compliance.
Core EU regulatory layer; our security testing and infrastructure hardening feed directly into the technical measures NIS2 requires.
The W3C Recommendation (published October 2023) that defines how to make web content perceivable, operable, understandable and robust. Version 2.2 adds nine success criteria — including Focus Appearance, Target Size, Dragging Movements and Accessible Authentication — for a total of 87, with particular benefit to users with low-vision, cognitive and motor disabilities.
We build to WCAG 2.2 Level AA as our default target: semantic HTML, visible focus states, keyboard-operable interactions, sufficient contrast and touch-target sizing, and reduced-motion support. Canvas 2D visuals are paired with text alternatives and accessible fallbacks rather than left as opaque pixels.
Level AA is the conformance level the EU harmonised standard and accessibility legislation build upon; targeting it directly is the practical basis for EU accessibility conformance.
The European harmonised standard for ICT accessibility. It incorporates WCAG (v3.2.1 embeds WCAG 2.1 Level AA for web content) and extends it to documents, software and hardware. Conformance provides a presumption of conformity with EU accessibility obligations; a v4.x revision incorporating WCAG 2.2 AA is expected to be referenced in the Official Journal around late 2026.
We treat EN 301 549 as the reference frame for EU-facing web work, aligning to its WCAG-based web clauses and tracking the pending update to WCAG 2.2. We document conformance rationale so clients have a defensible basis for accessibility statements.
It is the harmonised standard underpinning the Web Accessibility Directive (2016/2102) and the European Accessibility Act (enforceable since 28 June 2025); conformance is the recognised route to legal presumption of conformity.
The ergonomics standard (part of the ISO 9241 series on human-system interaction) that sets out human-centred design principles: grounding design in real user needs and context of use, involving users, and iterating throughout the lifecycle to produce usable, useful systems.
We apply human-centred design as a working method: clarifying who the users are and their context up front, iterating on interfaces, and validating usability rather than shipping on assumption. This shapes both web front-ends and the desktop (PySide6/Qt) tools we build.
An internationally adopted usability standard used across the EU; complements accessibility conformance by addressing overall usability and fitness for purpose.
Google's user-centric performance metrics: Largest Contentful Paint (LCP, target ≤2.5 s), Interaction to Next Paint (INP, ≤200 ms) and Cumulative Layout Shift (CLS, ≤0.1), assessed at the 75th percentile of real-user page views to gauge loading, responsiveness and visual stability.
We follow the Core Web Vitals thresholds as performance targets, favouring a lightweight architecture (Astro, vanilla JS/CSS, no heavy frameworks), reserved layout space to avoid shift, and disciplined asset/loading strategies to keep LCP, INP and CLS in the 'good' range.
A vendor-neutral field-data performance benchmark, not an EU instrument, but a widely used proxy for the fast, stable experience good web practice demands across all markets.
The living specifications defining the core web platform: the WHATWG HTML and DOM Living Standards (developed under a 2019 W3C–WHATWG agreement) and the Fetch networking model, alongside W3C specifications for CSS and related APIs.
We build on standards-compliant, semantic HTML and standard DOM/Fetch APIs rather than framework-specific abstractions, which keeps our sites interoperable, resilient across browsers and maintainable without lock-in — consistent with our vanilla JS/CSS approach.
Open, royalty-free web standards; using them directly maximises interoperability and long-term maintainability for EU clients without proprietary dependencies.
The standard maintained by Ecma International's TC39 that defines the JavaScript language. Editions ship annually — ECMAScript 2025 (16th edition, June 2025) is the current published edition, adding the Iterator global, new Set methods and JSON module imports with import attributes.
We write standards-based JavaScript to the current ECMAScript edition, using native language features over polyfills or heavy tooling where browser support allows, and keeping to well-supported syntax so client code stays portable and future-proof.
A globally adopted, vendor-neutral language standard; writing to it ensures cross-browser correctness and longevity for EU-deployed web software.
The GDPR requirement that controllers implement appropriate technical and organisational measures — both when determining the means of processing and during processing — so that data protection principles (notably data minimisation) are built in and, by default, only data necessary for each purpose is processed.
We apply privacy-by-design to web builds: collecting only what a feature genuinely needs, avoiding unnecessary third-party trackers and cross-border data flows, minimising logging, and preferring self-hosted or no-analytics defaults. Where processing occurs we make it explicit and documented.
A direct EU legal obligation under Regulation (EU) 2016/679, applicable to any site processing personal data of individuals in the EU.
The set of response headers that harden a site against common web attacks — Content-Security-Policy (mitigating XSS), Strict-Transport-Security (enforcing HTTPS), X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy — as catalogued by the OWASP Secure Headers Project.
We deploy the OWASP core header set as part of our server baseline: HTTPS via Let's Encrypt/certbot with HSTS, a tuned Content-Security-Policy, and the supporting Referrer/Permissions/X-Content-Type headers configured at nginx. This ties directly into our hardened Hetzner/nginx hosting practice.
Not an EU instrument, but a recognised security baseline that supports the 'appropriate technical measures' expected under GDPR Article 32 for protecting personal data in transit.
TLS 1.3 (IETF RFC 8446) is the current transport-encryption standard, mandating forward-secret ephemeral key exchange and a faster 1-RTT handshake. ACME (RFC 8555) is the protocol behind Let's Encrypt that automates issuance and renewal of publicly-trusted certificates.
Every service we operate is served over HTTPS via nginx with TLS 1.3 enabled and weak ciphers and legacy protocols disabled. Certificates are issued and auto-renewed through Let's Encrypt using certbot (ACME), so encryption stays valid without manual intervention. We configure HSTS and modern cipher suites by default.
Encryption-in-transit directly supports the GDPR Art. 32 requirement for appropriate technical measures, and TLS is a baseline expectation across EU security guidance including ENISA recommendations.
Consensus-based, prescriptive configuration baselines from the Center for Internet Security covering Linux OS hardening: filesystem permissions, account and authentication policy, network parameters, logging, and disabling unnecessary services, organised into Level 1 (essential) and Level 2 (high-security) profiles.
We harden Hetzner VPS instances along CIS Benchmark lines: removing unneeded packages and services, tightening kernel and network sysctl parameters, enforcing sane file permissions, and disabling insecure defaults. We treat the benchmarks as a checklist rather than a certification claim.
Recognised hardening baselines evidence the 'state of the art' technical measures expected under GDPR Art. 32 and map cleanly onto ISO/IEC 27001 Annex A configuration-management controls.
Securing remote administrative access to servers: public-key-only authentication, disabling password and root login, strong key algorithms, and network-level restriction of the SSH service, consistent with guidance such as NIST SP 800-123.
Servers are configured for key-only SSH (PasswordAuthentication no, PermitRootLogin no) using Ed25519 keys. Administrative access uses a non-root account with sudo, and the SSH service is exposed only to trusted sources behind the firewall. No password logins exist to brute-force.
Strong authentication and restricted privileged access support GDPR Art. 32 access-control obligations and align with ISO/IEC 27001 Annex A access-control and cryptography controls.
The principle of least privilege (formalised in NIST SP 800-53 AC-6) restricts every user and process to the minimum access needed for its task. systemd provides kernel-backed sandboxing directives to enforce this per-service.
Application services run under dedicated unprivileged system users, never as root. Where a service runs under systemd we apply sandboxing directives such as NoNewPrivileges, ProtectSystem, PrivateTmp and PrivateDevices to contain it, so a compromised service cannot reach the wider host or escalate privileges.
Least privilege and process isolation are core to GDPR Art. 32 data-minimisation-of-access and to ISO/IEC 27001 Annex A access-control and secure-configuration controls.
A default-deny host firewall (ufw, a front end to nftables/iptables) that permits only required ports, combined with fail2ban, which watches authentication and service logs and automatically bans source IPs exhibiting brute-force or abusive behaviour.
Each server runs ufw in a default-deny posture, exposing only the ports a given service actually needs (typically SSH, 80 and 443). fail2ban monitors SSH and web logs and temporarily bans offending IPs, cutting down automated attack noise against the VPS.
Network access control and attack mitigation are expected technical measures under GDPR Art. 32 and correspond to ISO/IEC 27001 Annex A network-security and monitoring controls.
A resilience rule of thumb: keep three copies of data, on two different media/systems, with at least one copy off-site (ideally isolated), so no single failure, ransomware event, or provider outage causes permanent data loss.
For systems we operate, we structure backups toward the 3-2-1 model: the live data, an automated on-server/secondary copy, and an off-site copy separated from the primary host. We favour tested, restorable backups over untested ones and verify that a restore actually works.
Backup and restore capability underpins the GDPR Art. 32 requirement to restore availability and access to personal data in a timely manner after an incident, and maps to ISO/IEC 27001 Annex A backup controls.
Continuous collection of system, service, and security logs (via systemd's journal and service logs) plus health/uptime monitoring, providing the audit trail and early warning needed to detect, investigate, and respond to faults and incidents.
We rely on the systemd journal and nginx/service logs for operational and security visibility, monitor service health and certificate/renewal status, and use logs as evidence when diagnosing incidents. Logging feeds directly into fail2ban's automated response.
Logging and monitoring support the GDPR Art. 33 breach-detection-and-notification duty and align with ISO/IEC 27001 Annex A logging-and-monitoring controls.
ISO/IEC 27001 defines an information-security management system, with Annex A listing reference controls. ISO/IEC 27017 is a cloud-specific code of practice that extends those controls to cloud/VPS environments, covering shared responsibility, tenant segregation, asset removal, and virtual-environment hardening. Neither 27017 nor 27018 is separately certifiable.
We operate client infrastructure on European cloud (Hetzner) with the shared-responsibility boundary made explicit, and apply the relevant ISO/IEC 27017 and ISO/IEC 27001 Annex A controls we can genuinely own at the server layer: hardening, access control, segregation, and secure decommissioning of assets after engagements. We are aligned with these controls; we do not hold a certification.
ISO/IEC 27001 and 27017 are the internationally recognised references EU clients use to gauge information-security maturity, and their controls reinforce GDPR Art. 32 obligations for cloud-hosted personal data.
Every pixel is hand-built — the instrument up top, the live code behind the glass, this field. Grab them. Throw them around.