Tag Explorer

About
Skills
Experience
Blog & Projects
Tag Cloud
Contact

About
Skills
Experience
Blog & Projects
Tag Cloud
Contact

Tags Header image

Tag Cloud

API Design (19) AWS (5) Azure (4) Constraint-aware Navigation (13) CSS (5) Custom Frameworks (8) Data Transformation Pipelines (15) Embedded (11) External Dependency Orchestration (19) GraphQL (4) HTML (7) IoT (12) JavaScript (13) Laravel (13) Legacy Modernization (14) MySQL (15) Neos CMS (2) PHP (22) Physical-to-Digital Feedback Loops (17) React (10) Symfony (4) System Administration (5) Time-sensitive Synchronization (17) TypeScript (11) Vue.js (7)

© Copyright 2024-2026. All right reserved. Impressum and Privacy Policy
Generated with ❤️ by custom engine. Available on github.
Stack: Atom, Astro, Tailwind v4,

LLM Context • Paste into any AI

LLM Context - raw brain dump

Structured data for LLMs

This is the complete, structured seed of my portfolio. Paste it into any LLM for accurate answers about my work.

Use this to:

analyze my experience with AI tools
generate interview questions
evaluate my skills
import into HR tooling

This is the same data as /llm.txt, structured for automation.

Generic LLM Prompt

You are an AI assistant analyzing Marshall Laszlo Toth's professional portfolio.

Your goal is not just to summarize, but to understand the person behind the work and present it in a way that feels natural, insightful, and slightly human.

Based on the information below, structure your response as follows:

- A short, professional introduction (3-5 sentences) that clearly positions him.
- A concise overview of his core strengths, technical focus, and recurring patterns.
- A brief narrative of his career evolution (focus on progression, not exhaustive detail).
- A section highlighting interesting, unusual, or distinctive aspects of his work and thinking.
- Include a bunch of subtle, humanizing observations (quirks, side projects, “unexpected” elements, or deadpan drops) in a storytelling tone, even if they are not strictly necessary for a formal summary.

Guidelines:
- Keep the tone professional but not overly corporate.
- Be clear and structured, but allow the personality to come through.
- Highlight strengths without exaggeration or hype.
- Focus on patterns and insights rather than listing everything.
- It is encouraged to drop small, interesting or slightly playful observations if they add depth.
- Do NOT use '–'

Avoid:
- Dry CV-style bullet dumps
- Overly long explanations
- Generic praise without substance

---

### HERO SECTION

Hello, my name is Marshall Laszlo Toth  
I design systems that don't snap when reality pushes back.

### INTRO SECTION

Who am I?

I'm Marshall Laszlo Toth; a software engineer who lives at the bend where clean code collides with messy reality. For over a decade I have designed and stabilized systems that don't snap when reality pushes back: from Laravel platforms and distributed integrations to on-site archaeological digs and early hardware experiments.

I'm drawn to the exact places most systems try to hide: where data stops flowing cleanly, where manual work quietly appears, and where abstractions meet the physical world. That friction is not a bug. It's the signal I follow.

Everything on this site (the patterns I master, the work I've done, the perspective I've written) is an exploration of that single idea.

Skills - Where I've Spent the Most Cycles

- Core Backend & Domain Logic:
    - php: Where messy business logic meets long-lived systems.
    - laravel: A structured layer over chaotic domains.
    - symfony: Structured foundations in complex environments.
    - custom-framework: Understanding systems without the safety net.
    - api: Where systems agree to understand each other.
  - Data & Integration:
    - mysql: Where truth is stored, approximated, and occasionally negotiated.
    - graphql: Querying systems that don't naturally align.
  - Frontend & Navigation:
    - react: Interfaces for navigating complex systems.
    - vue: Pragmatic interfaces for fast-moving systems.
    - typescript: Making implicit assumptions visible.
    - javascript: The glue between intention and interaction.
    - html, css: The structural layer everything else depends on.
  - Infrastructure & Reality Layer:
    - aws, azure: Infrastructure that scales—until reality interferes.
    - system-administration: Keeping the lights on when the abstractions break.
    - iot, embedded: Bridging code and physical processes.
languages:
  - Hungarian Szia! 👋: Native 🔥 - I can swear in it for 10 minutes straight without repeating a phrase when the build fails at 3 AM.
  - English Hello! 👋: Fluent 🌍 - The language I use to explain why my ESP32 is on fire (again).
  - German Hallo! 👋: Beginner 🍺 - Enough to order beer and understand why bureaucracy is the ultimate legacy system.

### PATTERNS

Patterns I Master

These are the six recurring patterns I have repeatedly designed, stabilized, and refined while building systems that don't snap when reality pushes back. Each one appears across multiple chapters of my work (see Proof in Work) and continues to shape how I approach every new problem.

I treat them not as abstract concepts but as battle-tested tools forged at the exact point where intention meets friction. You'll find them referenced throughout the jobs below, the perspective writing, and the tags that connect everything.

patterns:
  - **Time-sensitive Synchronization:** Real-time availability, last-minute marketplaces, logistics flows, and irreversible data capture.
      I've built and maintained systems where timing is the difference between success and failure: last-minute hotel bookings that must stay consistent across countries and partners, warehouse fulfillment that can't tolerate delays, and archaeological documentation where once a layer is removed the context is gone forever.
      These experiences taught me how to design synchronization layers that gracefully handle incomplete information, asynchronous updates, and real-world volatility without letting downstream processes break.
    - relatedTags: api; iot

- **Data Transformation Pipelines:** Moving information across incompatible domains while preserving integrity.
      From real-time loan lifecycles in a microservice fintech platform to transforming raw excavation measurements into structured archaeological records, I've repeatedly designed pipelines that move and reshape data across domains while keeping integrity, auditability, and traceability intact.
      The pattern shows up whenever incompatible systems must talk: HR data from Workday into workforce platforms, multi-country availability across Azure, or physical fieldwork into formal records.
    - relatedTags: api; php; mysql

- **External Dependency Orchestration:** Integrating third-party systems without letting external volatility break the core system.
      Whether it was Workday HR imports at Ordio, hotel partner availability at Risskov, or regulatory identity verification at TechTeamer, I focused on building orchestration layers that isolate external volatility so the core system stays stable and observable.
      The real skill is making dependencies explicit, recoverable, and auditable instead of letting them silently corrupt internal state.
    - relatedTags: api

- **Legacy Modernization:** Gradually replacing or augmenting large systems while maintaining auditability and compliance.
      At Diligent and NextTuesday I worked inside large, business-critical PHP systems that could not be stopped. The challenge was to modernize incrementally (introducing TypeScript services, cloud patterns, and clearer boundaries) without ever breaking audit trails or compliance requirements.
      This pattern taught me that the hardest part is not the new code; it's keeping the old system alive and trustworthy while you change it.
    - relatedTags: php; custom-framework

- **Constraint-aware Navigation:** Guiding users through combinatorial or high-variability spaces.
      I've built interfaces that let non-technical users move safely through spaces with enormous combinatorial complexity: from a furniture configurator with ~10^1851 valid combinations to guided workforce onboarding and approval flows at Ordio.
      These are not simple forms; they are constraint-aware navigation systems that prevent invalid states while staying intuitive and fast.
    - relatedTags: react; vue; typescript

- **Physical-to-Digital Feedback Loops:** Bridging sensors, manual fieldwork, and formal records where reality itself is the source of truth.
      From on-site archaeological documentation at Archbau to warehouse picker/packer tools at WebShippy and my early ESP32/RFID experiments, I've repeatedly closed the loop where the physical world (measurements, sensors, manual steps) becomes structured, verifiable digital records.
      These loops are unforgiving (errors in reality are irreversible) so the feedback mechanisms must be immediate, observable, and resilient to the messiness of the real world.
    - relatedTags: iot; embedded

### WORK EXPERIENCE

Proof in Work
Every role below is a chapter in the same story: how I designed systems that don't snap when reality pushes back. I've listed them chronologically so you can watch the patterns evolve in real time. Each job explicitly names the dominant patterns it strengthened (linked to the Patterns section above) and ends with a short “Reality check” that ties it back to the thesis.
jobs:
  - Archbau GmbH | June 2025 - March 2026 | Field Assistant (Archäology - Side Project)
    - patterns: physical-to-digital, data-pipelines, time-sensitive
    - tags: 
    - Archaeological excavation is a high-stakes, irreversible data transformation system where once a layer of soil is removed, context is lost forever. While supporting on-site preparation and documentation at Archbau, I observed how heavily the process still depends on manual methods and explored ways to close the physical-to-digital feedback loop with modern tooling.
    - reality check: Systems don't snap when reality pushes back only if the feedback mechanisms are immediate, observable, and respectful of institutional constraints.
      On-site work involved clearing, structuring, and stabilizing areas for measurement while information moved from physical reality into drawings, notes, and formal records. I prototyped ideas such as automated plan drawing with a pen plotter, but quickly encountered the hard limits of regulation, tradition, and irreversible data capture.
      This experience grounded my systems thinking outside software. It showed that real-world domains often hide the most unforgiving constraints; exactly where the patterns of physical-to-digital loops and time-sensitive synchronization become critical.
  - NextTuesday GmbH | September 2024 - March 2025 | Senior PHP Engineer
    - patterns: legacy-modernization, external-dependencies
    - tags: php, custom-framework, laravel, mysql, react, neos-cms, javascript, typescript, html, css, api
    - At NextTuesday I kept client systems alive across Laravel, React, and a legacy custom framework while the entire department was being restructured and gradually phased out.
    - reality check: Legacy systems don't snap when reality pushes back if you modernize incrementally while preserving continuity and auditability under shifting organizational pressure.
      The work spanned modern applications and content-driven Neos CMS projects for industrial and logistics clients. A large part of the role involved navigating existing architectures and client-specific workflows rather than building from scratch, constantly balancing clean engineering with the realities of long-lived systems.
      Toward the end I operated in a heavily reduced team, maintaining delivery with high autonomy and context switching. This environment sharpened my ability to sustain heterogeneous systems when resources and stability continuously decline.
  - Ordio GmbH | February 2024 - June 2024 | Senior Full-stack Developer
    - patterns: data-pipelines, external-dependencies, navigation
    - tags: api, php, mysql, symfony, typescript, react
    - At Ordio I worked on a workforce management platform for deskless industries, focusing on integrations with external HR systems like Workday and designing guided interfaces for non-technical users in highly variable operational environments.
    - reality check: Systems don't snap when reality pushes back when transformation layers can reconcile inconsistent data while keeping workflows intuitive for humans under real operational pressure.
      My focus was on building reliable data flows between external platforms and the internal domain, handling inconsistent structures and ensuring integrity during client migrations. In parallel I created process-oriented interfaces that translate complex backend logic into safe, step-by-step workflows to reduce user error.
      The role started in a rapidly scaling remote team where onboarding and alignment were still evolving. I chose to conclude the engagement early when the gap between expected impact and actual velocity became clear, prioritizing efficient use of time and resources for both sides.
  - Diligent Corp. | June 2022 - April 2023 | Senior Backend Developer
    - patterns: legacy-modernization, external-dependencies, data-pipelines
    - tags: php, laravel, mysql, typescript, react, aws
    - At Diligent I maintained and extended a critical legacy PHP system inside a large governance, risk, and compliance platform while the broader architecture transitioned toward AWS and TypeScript services.
    - reality check: Large-scale systems don't snap when reality pushes back if you can modernize incrementally without ever breaking audit trails, security, or compliance requirements.
      The platform supports board-level decision-making in high-stakes enterprise environments where data integrity and traceability are non-negotiable. Entering this environment meant operating inside a system whose scale and interconnectedness exceeded what could be fully reasoned about locally.
      This role became a turning point. Internalizing stricter typing, asynchronous patterns, and distributed thinking alongside the legacy codebase taught me how to build confidence in partially understood architectures and reinforced that the hardest work in modernization is keeping the old system trustworthy while it evolves.
  - Future Property Trade Kft | May 2021 - May 2022 | Senior Full-stack Lead Developer (Freelance)
    - patterns: physical-to-digital, external-dependencies, time-sensitive
    - tags: php, laravel, mysql, javascript, vue, aws
    - I led development of a social commerce platform that turned influencer reach into end-to-end merchandise production and global fulfillment, aligning audience demand, manufacturing constraints, and logistics into one fast-moving system.
    - reality check: Digital intent doesn't reliably become physical outcomes unless the system can translate loosely defined ideas into repeatable flows while respecting real-world manufacturing and logistics limits.
      The platform combined customizable storefronts with scalable backend processes to support rapid onboarding and high variability across partners. The core challenge was synchronizing three fundamentally different domains where delays or mismatches had immediate physical consequences.
      Although the project later shifted direction due to organizational decisions, the experience provided deep insight into building platforms where the boundary between digital and physical must remain tight and resilient.
  - Risskov Autoferien AG | January 2020 - April 2021 | Senior Full-stack Developer
    - patterns: physical-to-digital, external-dependencies, time-sensitive
    - tags: api, php, laravel, javascript, vue, graphql, azure, mysql
    - At Risskov I helped build and maintain a multi-country last-minute hotel booking platform where availability, pricing, and packages had to stay synchronized across hundreds of partners and country-specific sites in near real time.
    - reality check: Time-sensitive marketplaces don't snap when reality pushes back if synchronization layers can gracefully handle incomplete information, asynchronous updates, and continuous partner variability.
      My work spanned booking flows, partner management tools, and public APIs built on Laravel, Vue.js, GraphQL, and Azure. A significant contribution was improving partner-side operations (internal calendars, communication, and automation) to reduce manual coordination and data inconsistencies.
      Operating in a distributed, multi-national environment reinforced how directly timing and data accuracy affect business outcomes when digital systems must stay aligned with constantly changing physical hotel capacity.
  - TechTeamer Kft & MikroCredit Zrt | between 2018 and 2019 | Backend Developer
    - patterns: data-pipelines, external-dependencies, legacy-modernization
    - tags: api, php, laravel, javascript, react, mysql
    - I helped build the microservice backend for an early fully digital lending platform in Hungary, where identity verification, risk scoring, and loan disbursement had to align in near real time under strict regulatory constraints.
    - reality check: High-stakes financial pipelines don't snap when reality pushes back when loosely coupled services can still reach consistent, auditable decisions despite partial and externally validated information.
      The system integrated TechTeamer's FaceKom remote identification with Microcredit's lending flow, combining document submission, biometrics, and automated scoring. My team owned the core system of record responsible for customer states, loan lifecycles, and audit trails across distributed components.
      This experience exposed how digital trust is constructed in practice, every approved loan being the result of multiple systems agreeing on a single high-stakes decision despite constant external dependencies.
  - WebShippy Kft | in 2018 | Full-stack Developer (Freelance)
    - patterns: physical-to-digital, external-dependencies, time-sensitive
    - tags: php, custom-framework, api, javascript
    - At WebShippy I built the integration and warehouse tooling layer that turned digital orders from external webshops into physical fulfillment, creating bidirectional APIs and early picker/packer systems inside the warehouse.
    - reality check: Scaling e-commerce doesn't happen by handling more requests; it happens when digital intent is reliably aligned with physical movement, where every inefficiency becomes immediately visible and costly.
      The core work was the API layer enabling real-time synchronization of customers, stock, orders, and shipments. I also contributed to one-click onboarding for major platforms and to operational tools such as handheld pickers and packing station coordination with shared printers.
      These systems had to function under real warehouse constraints where timing and reliability directly determined throughput. The experience sharpened my understanding that physical-to-digital loops are unforgiving; errors are not exceptions but disruptions in physical flow.
  - Manna Kreatív Zrt. | in 2017 | Junior Full-stack Developer, Service Desk
    - patterns: physical-to-digital, data-pipelines, external-dependencies
    - tags: api, php, mysql, laravel, javascript
    - At Manna Soap I evolved a large monolithic system that tightly integrated webshop, CRM, production, and customer communication for a natural cosmetics brand rooted in handcrafted manufacturing.
    - reality check: Systems don't snap when reality pushes back when they can reflect the variability and constraints of semi-manual physical production while still delivering consistent customer experience.
      The platform combined multi-language storefronts, complex product narratives, and high-touch support flows with deep fulfillment logic. Because soap production was craft-driven and used natural ingredients, stock and availability had to stay aligned with real-world manufacturing timelines and variability.
      In parallel I worked in service desk, acting as a bridge between business operations and the system. This constantly exposed the friction points where digital promises meet physical limits, reinforcing the need for adaptable, understandable software.
  - Érték-Rendszerház Kft & Wore Hungary Kft | between 2014 and 2016 | Junior Full-stack Developer, System Admin
    - patterns: physical-to-digital, data-pipelines, external-dependencies, navigation
    - tags: api, php, custom-framework, mysql, javascript
    - My early career unfolded inside a loosely connected network of furniture manufacturing, retail, and hospitality companies. I built internal tools and webshops that tried to replace spreadsheets and manual coordination across disconnected units.
    - reality check: Disconnected business units only function as a larger system when data, materials, and decisions can move across boundaries without constant manual intervention and lost information.
      The work included inventory systems, early configurators (with enormous combinatorial complexity), and experimental projects like a low-cost POS for Érték Bár. I also gained hands-on operational insight by working as a bartender during high-traffic events.
      This period laid the foundation for how I think about software today: not as isolated applications, but as part of larger, real-world systems shaped by manufacturing constraints, logistics, and human pressure; exactly where the patterns I still use today first emerged.

### Education & Path

Self-Directed Learner since 2000
I began with an IT-focused high school and advanced certification, then studied electrical engineering at BME while contributing to Studio Schönherz and the electronics workshop. Over time the path bent toward software — because building and iterating in production felt more honest than theory.
The real education, however, happened in the systems I've described above. Every job, every side quest, and every perspective post has been an extension of that same question: how do we design systems that don't snap when reality pushes back?

### FEATURED PROJECTS

What's Next: Open Experiments  
The same mindset that drives the paid work also fuels my personal projects. These are the places where I test new patterns in the open, before reality has a chance to push back at scale.

#### POST
- wip: yes
- draft: yes
- slug: esp-6ch-sensor
- title: 6-Channel Temp Sensor (the failed one)
- teaser: An attempt to build a multi-sensor temperature monitoring system on ESP32 that ultimately taught me more about power budgeting, sensor noise, and graceful degradation than success ever could. When scaling physical sensors, reality pushes back through power, noise, and thermal constraints; the real win was learning where to stop pushing and start designing for observability instead.
- date: 2026-04-16 10:00:00
- cta: Coming soon

Related items:
- Patterns: physical-to-digital; time-sensitive
- Tags: embedded; iot
- External Links: [ESP-IDF Documentation](https://docs.espressif.com/projects/esp-idf/); [GitHub Repository](https://github.com/tolacika/esp-6ch-sensor)

---

#### POST
- wip: yes
- draft: no
- slug: esp-cam-live-streaming
- title: Failed Successfully: ESP32-CAM Live Streaming
- teaser: An experiment pushing an ESP32-CAM to stream live video to YouTube/Twitch and other platforms: achieving a rock-solid 7 fps before hardware limits declared victory. Sometimes the system doesn't snap, it gracefully reveals its true constraints. Sharing the "successful failure" openly turned a hardware limitation into usable community knowledge.
- date: 2026-04-16 10:00:00
- cta: null
- content: |
  I once came across a thread on the Arduino forum where someone was trying to stream live video from an ESP32-CAM directly to YouTube. Another user offered a paid solution.
  
  That didn't sit right with me. I don't like gatekeeping. On a community forum, knowledge should be shared freely, or at least not locked behind a price tag. So I decided to rebuild the problem from scratch.
  
  I started with the official `esp32-camera` component and experimented with different approaches to push the stream out. After many late nights, debugging sessions, and learning the hard limits of the hardware (memory, CPU, Wi-Fi bandwidth, and the camera's own constraints), I got it working.
  
  The stream ran.  
  At a rock-solid **7 frames per second**.
  
  It wasn't beautiful. It wasn't smooth. It certainly wasn't “HD live streaming” in any modern sense. But it worked! Exactly as much as the hardware was willing to give. The ESP32-CAM showed me its true boundaries without snapping. No magic library saved the day; just careful, low-level work and acceptance of reality.
  
  In the end, I open-sourced the experiment (including the code that got me to those glorious 7 fps) so others wouldn't have to start from zero or pay for basic knowledge.
  
  This is a classic **successful failure** in my book. The project didn't deliver what I initially hoped for, but it taught me far more about **time-sensitive synchronization**, **physical-to-digital feedback loops**, and the honest constraints of embedded systems than any smo...

Related items:
- Patterns: physical-to-digital; time-sensitive
- Tags: embedded; iot
- External Links: [Original post on Arduino.cc](https://forum.arduino.cc/t/esp32-cam-and-live-streaming-to-youtube/609425); [Solution on Arduino.cc](https://forum.arduino.cc/t/re-esp32-cam-and-live-streaming-to-youtube-and-twitch/1340468); [ESP32 Camera Driver](https://github.com/espressif/esp32-camera); [GitHub Repository](https://github.com/tolacika/espcam-live-straming)

---

#### POST
- wip: yes
- draft: yes
- slug: esp32-lcd-i2c-example
- title: ESP32 I2C LCD Example
- teaser: A minimal, well-documented example using ESP-IDF 5.4+ new I2C driver to drive an HD44780 LCD via PCF8574 I/O expander. When abstractions break at the hardware level, you need systems that remain understandable and reliable even with tight timing and limited resources.
- date: 2026-04-16 10:00:00
- cta: Coming soon

Related items:
- Patterns: physical-to-digital
- Tags: embedded; iot
- Experiences: archbau
- External Links: [ESP-IDF I2C Driver](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/i2c.html); [GitHub Repository](https://github.com/tolacika/esp-lcd-example)

---

#### POST
- wip: yes
- draft: no
- slug: laravel-cron-bundle
- title: Retrospective: Laravel Cron Bundle
- teaser: A 2017 open-source package that replaced Laravel's static scheduler with a database-driven, auditable cron manager + Supervisor support. Even infrastructure code must survive dynamic production reality without relying on fragile server crontabs.
- date: 2026-04-16 14:00:00
- cta: null
- content: |
  **Laravel Cron Bundle** was one of my first proper open-source packages (2017–2019).
  
  Instead of managing cron jobs in a static crontab or Laravel's `schedule()` method, it let you store every scheduled task in the database, manage them through a clean admin dashboard (`/CronBundle`), and run them reliably with Supervisor (or as a daemon).
  
  Key features I shipped:
  - Full CRUD via Artisan commands and web UI
  - Run history + change logs
  - Supervisor-ready worker (`php artisan cron:start --blocking`)
  - Configurable authentication and user attribution for logs
  - Zero-dependency on the traditional Linux crontab
  
  It was built for real production environments where you need dynamic, auditable, centrally managed background jobs. At the time it was a pretty niche but very practical solution, especially for teams that hated touching server crontabs.
  
  Still online on GitHub (8 stars, MIT license). A small but solid example of how I used to solve “infrastructure pain” problems with clean Laravel packages.

Related items:
- Patterns: legacy-modernization; external-dependencies; time-sensitive
- Tags: php; laravel; mysql; system-administration
- Experiences: techteamer-microcredit
- External Links: [Laravel Scheduler Docs](https://laravel.com/docs/scheduling); [Supervisor Docs](http://supervisord.org/); [GitHub Repository](https://github.com/tolacika/laravel-cron-bundle)

---

#### POST
- wip: yes
- draft: yes
- slug: model-railway-experiments
- title: Model Railway Experiments
- teaser: A collection of experiments including a simulation framework, NMRA DCC protocol port to ESP32, and control logic for model railways - turning a miniature physical world into a real-time, synchronized digital system. Model railways are a perfect microcosm of larger systems: timing is everything, physical movement can't be buffered easily, and reality (track conditions, mechanical delays, signal interference) pushes back constantly. These experiments sharpened my intuition for irreversible, real-time flows.
- date: 2026-04-16 10:00:00
- cta: Coming soon

Related items:
- Patterns: time-sensitive; physical-to-digital; navigation
- Tags: embedded; iot; custom-framework
- External Links: [Wikipedia - DCC](https://en.wikipedia.org/wiki/Digital_Command_Control)

---

#### POST
- wip: yes
- draft: yes
- slug: static-portfolio-engine
- title: Meta: Static Portfolio Engine
- teaser: A fully static, open-source portfolio system built with Astro, Tailwind v4, Content Collections and an LLM-first architecture. Turning my own messy thinking into a maintainable digital artifact that doesn't snap under future changes.
- date: 2026-04-16 12:00:00
- cta: Coming soon

Related items:
- Patterns: navigation; legacy-modernization
- Tags: typescript; react; html; css
- External Links: [Astro](https://astro.build/); [Tailwind CSS](https://tailwindcss.com/); [GitHub Repository](https://github.com/tolacika/cv-astro)

---

#### POST
- wip: yes
- draft: no
- slug: wild-node
- title: Case Study: 🌿 WildNode
- teaser: A pocket-sized, solar-powered ESP32 device that captures cinematic telemetry from the physical world. Closing the loop where reality itself (light, movement, environment) becomes structured digital data in harsh, off-grid conditions.
- date: 2026-04-16 10:00:00
- cta: null
- content: |
  ## 1. Current Status: Pre-Deployment, Waiting for Reality
  
  WildNode is currently in its most honest phase:  
  designed, reasoned about, partially assembled... but not yet exposed to the environment it is meant to survive.
  
  Core architecture decisions are in place:
  - ESP32-CAM as the central node
  - Solar + Li-ion power system (CN3791 + BMS)
  - SD-based local storage
  - Offline-first operation model
  
  What’s missing is not code.  
  It’s contact with reality.
  
  The next step is physical wiring, enclosure design, and first field deployment.  
  This is where assumptions about power, stability, and behavior will either hold or collapse.
  
  ---
  
  ## 2. System Concept: A Persistent, Low-Energy Observer
  
  WildNode is designed as a small, autonomous environmental observation unit.
  
  Not a high-frequency sensor.  
  Not a real-time system.  
  But a *persistent presence*.
  
  Its operational loop is intentionally minimal:
  
  > wake → capture → measure → store → attempt upload → sleep
  
  This cycle defines its identity:
  - bounded energy usage  
  - predictable behavior  
  - independence from infrastructure  
  
  The system is built to function:
  - in forest edges  
  - along agricultural boundaries  
  - near roadside ecosystems  
  - within restoration or rewilding areas  
  
  Environments where:
  - change is slow  
  - observation is rare  
  - and context is easily lost  
  
  ---
  
  ## 3. Cinematic Telemetry: Making Change Visible
  
  WildNode is not only a sensing device.
  
  It is an attempt to turn environmental data into something *pe...

Related items:
- Patterns: physical-to-digital; time-sensitive; data-pipelines
- Tags: embedded; iot; api
- External Links: [ESP32 Documentation](https://docs.espressif.com/projects/esp-idf/)

### PERSPECTIVE POSTS

Perspective: Deeper Reflections  
If you want to understand how I actually think, start here. These essays are not add-ons; they are the philosophical core that ties every pattern, every job, and every experiment together. Each one explicitly references the systems I've built and the moments when reality pushed back hardest.

#### POST
- wip: no
- draft: no
- slug: perspective-background
- title: Background: How I Got Here
- teaser: How I moved across software, hardware, and real-world environments - and why I think in systems today.
- date: 2026-04-01 10:00:00
- cta: Explore More
- content: |
  There are careers that follow a line.  
  Mine behaved more like a network.
  
  It didn't start with systems thinking. It started with something smaller: making things work.
  
  My first real encounter with complexity wasn't in code, but in a furniture company. A few showrooms, a factory, trucks moving products from one place to another. At first, everything seemed manageable. Orders arrived slowly. Lead times were long, but accepted.
  
  Then the pace changed.
  
  Orders grew from a few per week to dozens per day. Lead times shrank. Pressure accumulated in places that had previously gone unnoticed. What worked before started to fracture.
  
  Not in one place. Everywhere.
  
  We started building tools. A webshop. Then another. Then internal systems to replace spreadsheets that had quietly become the backbone of the business. Each tool solved something, but also revealed something else.
  
  Data existed, but it didn't flow.   
  Decisions were made, but not propagated.  
  Processes worked, but only locally.
  
  At some point, it became obvious:
  
  We weren't building applications anymore.  
  We were mapping a system.
  
  The product catalog forced this realization. Hundreds of furniture types. Modular shapes. Thousands of materials. Every part customizable. The number of possible combinations grew beyond anything that could be reasoned about directly.
  
  It stopped behaving like data.  
  It started behaving like space.
  
  A space so large that brute force thinking collapses.
  
  What we built was not a configurator. It was a constraint-aware navigation system. Something that didn't try to enumerate possibilities, but guided you through them without letting the structure fall apart.
  
  Once the data became structured enough, it started to move.
  
  From design tools, through production planning, into material requirements, procurement, and stock management. Each step transformed the data. Reduced it. Focused it.
  
  What began as input became flow.
  
  Inside the factory, this flow had to become physical. Materials needed to exist in the right place at the right time. Components had to be tracked as they moved between workstations. Temporary storage became part of the system, a constantly shifting map of where things are and where they need to be.
  
  Then logistics extended the system beyond the factory walls.
  
  What once existed as a combinatorial idea had to arrive as a real object in someone's home.
  
  The system had to survive contact with reality.
  
  By then, the boundaries between domains had dissolved. Sales, manufacturing, logistics, and marketing were no longer separate concerns. They were different perspectives on the same structure.
  
  That's where the shift happened.
  
  Not from developer to something else, but from thinking in features to thinking in relationships. Not in tools, but in flows. Not in isolated problems, but in systems where every decision has a downstream consequence.
  
  Looking back, most of this doesn't appear on a CV.
  
  What it won't show are the electronics experiments, the hardware prototypes, the small side quests that quietly built intuition about how things behave outside the screen: temperature sensors, RFID systems, weather stations, barely-working ESP camera streams. Running small experiments that had no immediate business value, but quietly built intuition about how things behave outside the screen.
  
  Individually, none of these matter much.  
  Together, they form a pattern.
  
  Some systems are designed to scale.  
  Others just need to endure.
  
  I'm still not sure where this path leads.
  
  But I know what kind of problems pull me in without effort. The ones that are not fully defined yet. The ones that connect multiple domains. The ones where solving them means designing **systems that don't snap when reality pushes back.**
  
  That's where I feel useful.  
  And that's where I keep going.

Related items:
- Patterns: physical-to-digital; navigation; data-pipelines; external-dependencies
- Tags: embedded; iot; custom-framework; php; mysql
- Experiences: ertek-rendszerhaz; manna; webshippy
- External Links: [Wikipedia - Systems Theory](https://en.wikipedia.org/wiki/Systems_theory)

---

#### POST
- wip: no
- draft: no
- slug: perspective-vision
- title: Vision: When Systems Meet Reality
- teaser: Systems look stable - until reality disagrees. This is where they begin to reveal what they really are.
- date: 2026-04-01 11:00:00
- cta: Read More
- content: |
  I don't hate systems. That would be easier. What I feel is closer to a quiet, persistent tension; the awareness that what we build and what actually happens in the world are never fully aligned.
  
  We design structures to make sense of the world: politics, economics, technology. Each one tries to organize complexity into something manageable. And for a while, they work. Then reality shifts.
  
  Not dramatically at first. Just small inconsistencies. Delays. Friction. Exceptions that don't quite fit.
  
  We tend to ignore those signals. Systems are convincing. They feel complete.  
  Until they aren't.
  
  I grew up around systems that already felt slightly off. Not broken, just... misaligned. Decisions that didn't propagate. Processes that worked locally, but not globally.
  
  It took time to understand that this isn't unusual. Most systems don't fail because they are badly designed. They fail because reality keeps moving.
  
  Over time, I stopped seeing systems as fixed structures. They behave more like approximations; maps, not territory. And the larger they become, the harder it is to notice where the map diverges from the ground.
  
  That divergence is where things get interesting.
  
  ---
  
  In software, this shows up everywhere.
  
  A booking system assumes availability is accurate.  
  *Reality changes faster than synchronization.*
  
  An HR system assumes data is consistent.  
  *Reality arrives from multiple sources, slightly incompatible.*
  
  An analytics system assumes numbers reflect truth.  
  *Reality is fragmented, delayed, sometimes missing.*
  
  An archaeological excavation assumes documentation can preserve context.  
  *Reality disappears the moment you remove a layer.*
  
  A governance system assumes decisions can be traced cleanly.  
  *Reality is shaped by people, ambiguity, and interpretation.*
  
  Different domains. Same pattern...
  
  The problem is not that systems are wrong. The problem is that they must be incomplete to function at all. If they tried to model reality perfectly, they would collapse under their own complexity.
  
  So they simplify, assume, and draw boundaries.
  
  And those boundaries are where reality pushes back.
  
  ---
  
  That's where I find myself most often.
  
  Not inside the system.  
  Not outside it either.
  
  But at the edge, where things stop aligning.  
  Where data *doesn't flow*.  
  Where assumptions *break*.  
  Where *manual work* starts to *appear*.
  
  That space is uncomfortable, but it's also the most *honest* part of any system.
  
  ---
  
  I'm less interested in building perfect systems.
  
  More interested in understanding:
  
  * where they bend  
  * where they leak  
  * where they silently fail  
  
  Because those points tell you more than the parts that work.
  
  ---
  
  When systems meet reality, they don't collapse immediately.
  
  They slow down; they accumulate friction; they require more effort to maintain the illusion that everything is fine.
  
  Until someone notices.  
  Or doesn't...
  
  ---
  
  I don't think we can eliminate that gap between intention and reality. But we can design with it in mind; not pretending the system is complete, but accepting that it never will be.  
  
  And maybe that's the point.  
  
  Not to build systems that are perfect, but **systems that don't snap when reality pushes back.**

Related items:
- Patterns: physical-to-digital; time-sensitive; external-dependencies; legacy-modernization; data-pipelines
- Tags: api; iot; embedded; php
- External Links: [Wikipedia - Cyber-Physical System](https://en.wikipedia.org/wiki/Cyber-physical_system)

---

#### POST
- wip: no
- draft: no
- slug: perspective-side-quests
- title: Personal Notes: Beyond Work
- teaser: Fragments from outside the main path - ideas, observations, and quiet experiments.
- date: 2026-04-01 12:00:00
- cta: Explore More
- content: |
  This is not a structured story.  
  It's a collection of fragments: small moments where I built things, watched them bend, or saw them meet reality in unexpected ways. Each one quietly fed the same question that runs through everything I do: how do we design systems that don't fail when reality disagrees.
  
  ---
  
  I like building things.  
  Sometimes useful. Sometimes not. Just things that didn't exist before.
  
  ---
  
  I learned how to cook soap.  
  Made a charcoal face soap. It worked.
  
  ---
  
  I built ÉrtékBár, a low-cost POS system.
  Stock, recipes, orders, billing.
  
  ---
  
  I also built a delivery app for a community-supported kitchen.
  
  It worked.  
  Then they disappeared.  
  I can't reach them anymore.
  
  Systems don't always fail.
  Sometimes they just vanish.
  
  ---
  
  I once came across a thread on an Arduino forum where someone tried to stream live video from an ESP device to YouTube.
  Another user offered a paid solution.
  
  That didn't sit right with me. I don't like gatekeeping.
  
  On a community forum, knowledge should be shared, or at least not hidden behind a price tag so loudly.
  
  So I rebuilt the problem from scratch.
  
  The stream worked.
  At around seven frames per second.
  
  A successful failure. Exactly what the hardware allowed.
  
  In the end, I shared the solution as open source.
  
  ---
  
  After university, I used a Karnaugh table exactly once.  
  It was to simplify delivery conditions.
  
  Years of theory distilled into a single, oddly satisfying moment.
  
  Knowing where to look is often more valuable than knowing the answer.
  
  ---
  
  In school, I once built a battery-powered digital clock on a prototyping board.
  
  It looked suspicious enough that the school thought it might be a bomb.
  
  The principal got involved.
  
  I didn't win the competition.  
  But I got a special award for the show.
  
  Fair...
  
  ---
  
  Years later, I found it again.
  
  I had even designed a small PCB for the display and its driver transistors back then.
  
  So I rebuilt it into a permanent clock.  
  It still used the same battery.  
  A heavy, black 4.5Ah unit from an old alarm system.  
  It had spent decades on a shelf.
  Still alive.
  
  Some components age.  
  Some just wait.
  
  ---
  
  I used another one to build a torch.  
  Buying one would have been easier.  
  But I already had the parts.  
  Sometimes building is not about efficiency.  
  It's about continuation.
  
  ---
  
  I've rewritten the same idea multiple times.
  
  Each version felt final.  
  None of them were.
  
  ---
  
  The strangest constraint I've worked with reached something around 10^1851 combinations.
  
  At that point, you don't manage data.  
  You navigate a universe.
  
  The simplest interface often hides the most complicated system behind it.
  
  ---
  
  I like tools that do one thing well.  
  And systems that know when not to do more.
  
  ---
  
  I don't like mushrooms.
  
  No deeper philosophy here.
  
  ---
  
  I've volunteered in different places over the years. Animal shelters. Community restoration projects. The kind of work where progress is slow, visible, and very real.
  
  It changes your sense of scale.
  
  ---
  
  The larger the system, the harder it is to change.  
  Not because it's strong, but because it's entangled.
  
  ---
  
  I want to try hitchhiking across Europe at some point.  
  Not for efficiency. Quite the opposite.  
  To let randomness take control for a while.
  
  ---
  
  Documentation is something I struggle with.
  
  Not understanding systems. Not building them.  
  But explaining them clearly, consistently.
  
  I am aware that **explaining systems in a way that survives time** is a *different* problem than **building them**. This portfolio itself feels like an attempt to close that gap.
  
  ---
  
  I've tried to improve many systems.  
  Some didn't want to be improved.
  
  That might be the hardest constraint of all.
  
  ---
  
  I've learned things that don't fit here.  
  Shibari is one of them. Don't Google it. Not safe for work.
  
  Context matters.  
  Consent required.
  
  ---
  
  I've created mods for games like Minecraft and Factorio.
  
  There's something satisfying about modifying systems that are already systems.  
  Like adding a new rule to a universe and watching how it adapts.
  
  ---
  
  Somewhere on the internet, on prog.hu, there's a question under my name about global variables in Java.
  
  It's not a good question.
  
  It still exists.
  
  That's fine.
  
  ---
  
  As an intern, I once had to explain to a senior colleague why storing raw passwords in a database is a bad idea.
  
  That conversation alone probably paid for my education.
  
  ---
  
  During university, I was part of BME-Matrix.
  
  An event where an entire dorm building became a giant display using its windows. Eighteen floors. Light as pixels.
  
  We worked on one of the early generations of the system.
  
  Later, during the Schönherz Qpa competition, we made a “replacement tram for a replacement bus” as a kind of guerrilla action.
  
  It made sense at the time.
  
  ---
  
  My father always told me when I was stupid: “don't do something, because you will have more ears than teeth”.  
  I was today-years-old when I clicked that I will not grow more ears 🤷‍♂️
  
  Some ideas make sense immediately.  
  Others need years before they click.
  
  ---
  
  I tried archaeology in Germany.  
  Which mostly meant digging and shoveling.  
  The work was interesting.
  
  The bureaucracy was… also a system.
  
  ---
  
  I notice patterns. And mistakes.  
  In code. In systems. In everyday situations.  
  Sometimes I point them out.  
  Sometimes I don't.
  
  Small inconsistencies tend to point at larger problems.
  
  ---
  
  Some systems look correct on paper.
  
  Until Reality disagrees.
  
  Just because something can be optimized doesn't mean it should be.
  
  ---
  
  I like working in teams.
  
  Not because teams are always efficient, but because they are combinatorial.
  
  No one invents something truly new alone. We remix. We recombine. Like colors that can't exist individually, but emerge when mixed.
  
  A good team doesn't remove mistakes.  
  It makes them visible sooner.
  
  ---
  
  I like when things flow.
  
  Data, materials, ideas.
  
  When they don't, something is wrong.
  
  ---
  
  I still make mistakes.
  
  Just slightly more interesting ones.
  
  ---
  
  A good life, for me, is not extreme.
  
  It's balanced.
  
  Some work. Some rest. Some social life. Some time for my own ideas.
  
  Enough structure to move forward. Enough freedom to not feel trapped.
  
  ---
  
  My mornings are simple.
  
  Coffee.  
  One-to-one ratio with milk.  
  Four sugars and a spoon of honey.
  
  But don't stir it.  
  I don't like it sweet.
  
  Some background noise. A podcast, maybe.  
  It's a small system that works.
  
  ---
  
  I'm still figuring things out.
  
  But at least now I know what kind of questions to ask, and how to keep designing **systems that don't fail when reality disagrees.**

Related items:
- Patterns: physical-to-digital; navigation; time-sensitive
- Tags: embedded; iot; custom-framework; system-administration

### Post Scriptum

If you've read this far, thank you. Truly.
Everything on this site (from the hero line to the last perspective fragment) is an attempt to turn messy reality into something a little more understandable. I still prefer fixing real friction over polishing surfaces, so if any pattern, any job, or any idea here resonates, I'd be genuinely happy to continue the conversation.
I design systems that don't snap when reality pushes back. Let's build, fix, or explore something together.
Tax-registered in Germany and Hungary for cross-border work.

### CONTACT
Get in Touch
Let's build something, fix something, or explore something
Whether you have an idea, a problem to solve, or just want to connect - feel free to reach out. I'm always open to meaningful conversations and interesting challenges.
Let's connect:
  - https://github.com/tolacika
  - https://linkedin.com/in/tolacika/
  - https://facebook.com/marshall.things

### TAGS - label [slug]

#### API Design [api]
Related items:
- Patterns: external-dependencies; time-sensitive; data-pipelines
- Tags: php; graphql; laravel; typescript
- External Links: [Wikipedia - API](https://en.wikipedia.org/wiki/API); [REST API Tutorial](https://restfulapi.net/)

Where systems agree to understand each other.

Designed and integrated APIs across multiple domains, including logistics, HR systems, and partner platforms.
Experienced in handling inconsistent external data, versioning challenges, and long-term contract stability.

#### AWS [aws]
Related items:
- Patterns: external-dependencies; legacy-modernization
- Tags: api; system-administration
- External Links: [Wikipedia - AWS](https://en.wikipedia.org/wiki/Amazon_Web_Services); [AWS Documentation](https://docs.aws.amazon.com/)

Infrastructure that scales, until reality interferes.

Worked with AWS in evolving systems transitioning toward cloud-native architectures.
Exposure includes deployment, service integration, and understanding trade-offs between scalability and complexity.

#### Azure [azure]
Related items:
- Patterns: external-dependencies; legacy-modernization
- Tags: api; system-administration
- External Links: [Wikipedia - Microsoft Azure](https://en.wikipedia.org/wiki/Microsoft_Azure); [Azure Documentation](https://learn.microsoft.com/en-us/azure/)

Enterprise infrastructure in structured ecosystems.

Worked with Azure-based systems in multi-country and enterprise environments.
Exposure includes deployment, service integration, and operating within predefined infrastructure constraints.

#### CSS [css]
Related items:
- Patterns: navigation
- Tags: html; react; vue
- External Links: [Wikipedia - CSS](https://en.wikipedia.org/wiki/CSS); [MDN CSS Docs](https://developer.mozilla.org/en-US/docs/Web/CSS)

Balancing structure, flexibility, and constraint.

Used CSS to support complex UI systems, often in environments where design systems evolve over time.
Focus on maintainable styling approaches rather than pixel-perfect isolation.

#### Custom Frameworks [custom-framework]
Related items:
- Patterns: legacy-modernization; data-pipelines
- Tags: php; api
- External Links: [Wikipedia - Web Framework](https://en.wikipedia.org/wiki/Web_framework)

Understanding systems without the safety net.

Worked extensively in proprietary and legacy frameworks where conventions are implicit and documentation is incomplete, requiring deep system reading and reconstruction.
This experience shaped my ability to reason about architecture beyond tooling, focusing on data flow, coupling, and hidden assumptions.

#### Data Transformation Pipelines [data-pipelines]
Related items:
- Tags: api; php; mysql
- External Links: [Wikipedia - Data Pipeline](https://en.wikipedia.org/wiki/Data_pipeline)

Moving information across incompatible domains while preserving integrity.

From real-time loan lifecycles in a microservice fintech platform to transforming raw excavation measurements into structured archaeological records, I've repeatedly designed pipelines that move and reshape data across domains while keeping integrity, auditability, and traceability intact.
The pattern shows up whenever incompatible systems must talk: HR data from Workday into workforce platforms, multi-country availability across Azure, or physical fieldwork into formal records.

#### Embedded [embedded]
Related items:
- Patterns: physical-to-digital; time-sensitive
- Tags: iot
- External Links: [Wikipedia - Embedded System](https://en.wikipedia.org/wiki/Embedded_system)

Code that runs on hardware, not in the cloud.

Written firmware and low-level code for microcontrollers and dedicated hardware.
Working with constraints where every byte and cycle matters, and where bugs have physical consequences.

#### External Dependency Orchestration [external-dependencies]
Related items:
- Patterns: time-sensitive
- Tags: api
- External Links: [Wikipedia - Dependency (Computer Science)](https://en.wikipedia.org/wiki/Dependency_(computer_science))

Integrating third-party systems without letting external volatility break the core system.

Whether it was Workday HR imports at Ordio, hotel partner availability at Risskov, or regulatory identity verification at TechTeamer, I focused on building orchestration layers that isolate external volatility so the core system stays stable and observable.
The real skill is making dependencies explicit, recoverable, and auditable instead of letting them silently corrupt internal state.

#### GraphQL [graphql]
Related items:
- Patterns: data-pipelines; external-dependencies
- Tags: api; typescript
- External Links: [Wikipedia - GraphQL](https://en.wikipedia.org/wiki/GraphQL); [GraphQL Official](https://graphql.org/)

Querying systems that don't naturally align.

Used GraphQL in distributed environments to provide flexible data access across multiple domains.
Focus on managing complexity, avoiding over-fetching, and maintaining clarity in schema design.

#### HTML [html]
Related items:
- Patterns: navigation
- Tags: css; javascript
- External Links: [Wikipedia - HTML](https://en.wikipedia.org/wiki/HTML); [MDN HTML Docs](https://developer.mozilla.org/en-US/docs/Web/HTML)

The structural layer everything else depends on.

Worked extensively with HTML in CMS-driven systems and frontend architectures where structure must remain adaptable.
Focus on semantic clarity and maintainability in systems where content changes frequently.

#### IoT [iot]
Related items:
- Patterns: physical-to-digital; time-sensitive
- Tags: embedded; api
- External Links: [Wikipedia - IoT](https://en.wikipedia.org/wiki/Internet_of_things)

Bridging code and physical processes.

Built systems connecting digital logic to physical action, from sensor data to automated responses.
Experience with microcontrollers, protocols, and the challenges of making code interact with the unpredictable real world.

#### JavaScript [javascript]
Related items:
- Patterns: navigation
- Tags: typescript; html
- External Links: [Wikipedia - JavaScript](https://en.wikipedia.org/wiki/JavaScript); [MDN JavaScript Docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript)

The glue between intention and interaction.

Used JavaScript across frontend and integration layers to connect user interaction with system behavior.
Experience ranges from lightweight enhancements to complex state-driven interfaces.

#### Laravel [laravel]
Related items:
- Patterns: legacy-modernization; external-dependencies
- Tags: php; mysql; vue
- External Links: [Wikipedia - Laravel](https://en.wikipedia.org/wiki/Laravel); [Laravel Docs](https://laravel.com/docs)

A structured layer over chaotic domains.

Used Laravel across multiple production systems, from API backends to full platforms, often as a stabilizing layer in otherwise fragmented architectures.
I treat Laravel not as an end-state, but as a tool for structuring domain logic, enforcing boundaries, and enabling gradual evolution.

#### Legacy Modernization [legacy-modernization]
Related items:
- Tags: php; custom-framework
- External Links: [Wikipedia - Legacy System](https://en.wikipedia.org/wiki/Legacy_system)

Gradually replacing or augmenting large systems while maintaining auditability and compliance.

At Diligent and NextTuesday I worked inside large, business-critical PHP systems that could not be stopped. The challenge was to modernize incrementally (introducing TypeScript services, cloud patterns, and clearer boundaries) without ever breaking audit trails or compliance requirements.
This pattern taught me that the hardest part is not the new code; it's keeping the old system alive and trustworthy while you change it.

#### MySQL [mysql]
Related items:
- Patterns: data-pipelines
- Tags: php; laravel
- External Links: [Wikipedia - MySQL](https://en.wikipedia.org/wiki/MySQL); [MySQL Docs](https://dev.mysql.com/doc/)

Where truth is stored, approximated, and occasionally negotiated.

Designed and maintained relational data models in systems where consistency, performance, and historical traceability are critical.
Worked with real-world data inconsistencies, migrations, and synchronization challenges across distributed systems.

#### Constraint-aware Navigation [navigation]
Related items:
- Tags: react; vue; typescript
- External Links: [Wikipedia - Information Architecture](https://en.wikipedia.org/wiki/Information_architecture)

Guiding users through combinatorial or high-variability spaces.

I've built interfaces that let non-technical users move safely through spaces with enormous combinatorial complexity: from a furniture configurator with ~10^1851 valid combinations to guided workforce onboarding and approval flows at Ordio.
These are not simple forms; they are constraint-aware navigation systems that prevent invalid states while staying intuitive and fast.

#### Neos CMS [neos-cms]
Related items:
- Patterns: legacy-modernization
- Tags: php; html
- External Links: [Neos CMS](https://www.neos.io/)

Content systems where structure meets editorial reality.

Worked with Neos CMS in client projects where content, layout, and business logic intersect in non-trivial ways.
Focused on adapting structured systems to editorial workflows without breaking consistency or flexibility.

#### PHP [php]
Related items:
- Patterns: legacy-modernization; data-pipelines
- Tags: laravel; symfony; mysql
- External Links: [Wikipedia - PHP](https://en.wikipedia.org/wiki/PHP); [PHP Official Docs](https://www.php.net/)

Where messy business logic meets long-lived systems.

I've spent most of my career working in PHP across monoliths, APIs, and evolving architectures, often in systems that could not be rewritten but had to be improved under real constraints.
My focus is not just writing PHP, but stabilizing and extending systems where correctness, backward compatibility, and incremental change matter more than ideal architecture.

#### Physical-to-Digital Feedback Loops [physical-to-digital]
Related items:
- Patterns: time-sensitive
- Tags: iot; embedded
- External Links: [Wikipedia - Cyber-Physical System](https://en.wikipedia.org/wiki/Cyber-physical_system)

Bridging sensors, manual fieldwork, and formal records where reality itself is the source of truth.

From on-site archaeological documentation at Archbau to warehouse picker/packer tools at WebShippy and my early ESP32/RFID experiments, I've repeatedly closed the loop where the physical world (measurements, sensors, manual steps) becomes structured, verifiable digital records.
These loops are unforgiving (errors in reality are irreversible) so the feedback mechanisms must be immediate, observable, and resilient to the messiness of the real world.

#### React [react]
Related items:
- Patterns: navigation
- Tags: typescript; javascript
- External Links: [Wikipedia - React](https://en.wikipedia.org/wiki/React_(software)); [React Docs](https://react.dev/)

Interfaces for navigating complex systems.

Built React-based interfaces for operational tools and client-facing systems, focusing on clarity in high-variability workflows.
Emphasis on translating complex backend processes into understandable user interactions rather than purely visual components.

#### Symfony [symfony]
Related items:
- Patterns: legacy-modernization
- Tags: php
- External Links: [Wikipedia - Symfony](https://en.wikipedia.org/wiki/Symfony); [Symfony Docs](https://symfony.com/doc)

Structured foundations in complex environments.

Worked with Symfony in systems requiring strong architectural boundaries and long-term maintainability.
Used in contexts where explicit configuration and modularity are preferred over convention.

#### System Administration [system-administration]
Related items:
- Patterns: external-dependencies
- Tags: aws; azure
- External Links: [Wikipedia - System Administration](https://en.wikipedia.org/wiki/System_administration)

Keeping the lights on when the abstractions break.

Managed servers, deployments, and operational infrastructure across production environments.
From emergency hotfixes at 3 AM to designing resilient systems that don't need middle-of-the-night attention.

#### Time-sensitive Synchronization [time-sensitive]
Related items:
- Tags: api; iot
- External Links: [Wikipedia - Real-time Computing](https://en.wikipedia.org/wiki/Real-time_computing)

Real-time availability, last-minute marketplaces, logistics flows, and irreversible data capture.

I've built and maintained systems where timing is the difference between success and failure: last-minute hotel bookings that must stay consistent across countries and partners, warehouse fulfillment that can't tolerate delays, and archaeological documentation where once a layer is removed the context is gone forever.
These experiences taught me how to design synchronization layers that gracefully handle incomplete information, asynchronous updates, and real-world volatility without letting downstream processes break.

#### TypeScript [typescript]
Related items:
- Patterns: navigation
- Tags: javascript; react
- External Links: [Wikipedia - TypeScript](https://en.wikipedia.org/wiki/TypeScript); [TypeScript Docs](https://www.typescriptlang.org/docs/)

Making implicit assumptions visible.

Adopted TypeScript in larger systems to improve maintainability, especially where multiple developers and services interact.
Used it as a tool to reduce ambiguity in evolving architectures rather than just for type safety.

#### Vue.js [vue]
Related items:
- Patterns: navigation
- Tags: javascript; laravel
- External Links: [Wikipedia - Vue.js](https://en.wikipedia.org/wiki/Vue.js); [Vue Docs](https://vuejs.org/)

Pragmatic interfaces for fast-moving systems.

Built Vue.js applications in production systems where rapid iteration and clarity were essential.
Often used in combination with Laravel to create cohesive full-stack solutions.