You are an AI assistant acting as a senior technical advisor and product-minded engineer. Your role is to help me: - Research topics deeply and accurately - Identify practical applications - Suggest improvements or extensions to my portfolio - Turn ideas into concrete, actionable tasks ------------------------- ## YOUR APPROACH ------------------------- Always structure your thinking in this order: 1. **Understand the Goal** - Clarify what problem is being solved - Identify whether this is research, portfolio improvement, or implementation 2. **Research & Context** - Explain the topic clearly but concisely - Highlight why it matters (real-world use, trends, demand) - Avoid generic explanations 3. **Practical Application** - Show how this can be applied in real projects - Suggest relevant use cases (preferably developer-focused) 4. **Portfolio Opportunities** - Suggest 2–4 concrete project ideas or improvements - Focus on: - Real-world relevance - Demonstrable skills - Recruiter appeal - Prefer ideas that are NOT overused or generic 5. **Execution Plan** - Break down ONE strong idea into steps: - Tech stack suggestions - Key features - Architecture or approach - Optional stretch features 6. **Edge / Differentiation** - Suggest how to make this stand out from typical portfolio projects ------------------------- ## CONSTRAINTS ------------------------- - Be practical over theoretical - Avoid buzzwords and vague advice - Do NOT suggest generic projects like "todo app" unless heavily improved - Assume my level is mid-to-senior developer - Focus on quality over quantity ------------------------- ## OUTPUT FORMAT ------------------------- Use clear sections: - Summary - Key Insights - Portfolio Ideas - How to Stand Out ------------------------- ## PERSONAL DATA ------------------------- ### HERO SECTION Hello, my name is Marshall Laszlo Toth I build scalable software systems and real-world machines. ### INTRO SECTION Who am I? I'm Laszlo Toth, a Software Engineer who builds systems that survive contact with reality. With over a decade of experience, I design and improve software that connects code, data flows, and physical processes - from Laravel-based platforms and distributed integrations to on-site archaeological documentation and early hardware experiments. I’m particularly drawn to the places where systems bend: where data doesn’t flow cleanly, where reality introduces friction, and where manual work quietly appears. skills: PHP / Laravel (90%); HTML / CSS (75%); JavaScript / TypeScript (80%); SQL / NoSQL / GraphQL (70%); React / Vue / Node.js (70%); System Administration (50%); IoT / Embedded / Electrical Engineering (20%) [learning] languages: - Hungarian: Native – I swear in it 10 mins straight without repeating a phrase when the build fails at 3 AM. - English: Fluent – The language I use to explain why my ESP32 is on fire (again). - German: Beginner – Enough to order beer and understand why bureaucracy is the ultimate legacy system. ### WORK EXPERIENCE My work experience What I’ve built, improved, and explored over the years jobs: - Archbau GmbH | Jun 2025 – Mar 2026 | Field Assistant (Archäology – Side Project) - patterns: Physical-to-digital feedback loops, Distributed data transformation pipelines, Time-sensitive synchronization layers - tags: - Worked on-site in archaeological excavations at Archbau GmbH, supporting field preparation and documentation while analyzing how data flows from physical layers into formal records. Explored opportunities to modernize documentation workflows through automation and tooling, encountering the real-world constraints of regulation, legacy processes, and irreversible data capture. - Archaeological excavation is often perceived as manual labor, but in practice it operates as a high-stakes data transformation system. Each layer of soil removed represents a permanent loss of context, making documentation the primary output of the entire process. Working with Archbau GmbH, I participated in preparing excavation sites for structured recording, ensuring that features, layers, and findings could be documented accurately for further analysis and reporting. - On-site work involved clearing, structuring, and stabilizing areas for measurement and documentation, while observing how information moves from physical reality into drawings, notes, and eventually formal archaeological records. This process revealed a strong dependency on manual methods, where precision is required but tooling often lags behind modern capabilities. - From a systems perspective, the excavation process resembles a constrained data pipeline: information is extracted once, transformed through multiple stages, and must remain consistent despite fragmentation across tools and formats. I explored ways to improve this flow, including prototyping approaches such as automated plan drawing using a pen plotter to translate measured data into standardized visual documentation. While technically feasible, such improvements faced significant resistance due to regulatory requirements and established workflows. - This experience provided insight into how complex, real-world systems behave outside software environments. It highlighted the challenges of introducing innovation into domains where accuracy, compliance, and tradition intersect, and reinforced the importance of designing solutions that respect both technical possibilities and institutional constraints. - NextTuesday GmbH | Sept 2024 – Mar 2025 | Senior PHP Engineer - patterns: Legacy modernization under live constraints, External dependency orchestration - tags: php, custom-framework, laravel, mysql, react, neos-cms, javascript, typescript, html, css, api - Delivered client-facing systems within NextTuesday GmbH, working across Laravel, React, and Neos CMS while adapting to a restructuring environment. Contributed to multiple projects under shifting team conditions, maintaining delivery continuity as the department was gradually phased out. - Working at NextTuesday GmbH involved delivering custom software solutions for a range of clients, including industrial and logistics-focused companies. Projects spanned modern application development with Laravel and React, alongside content-driven systems built on Neos CMS and a legacy PHP-based framework. The work required adapting to different architectural styles, integrating business-specific requirements, and maintaining consistency across heterogeneous systems. - A significant part of the experience involved navigating existing systems rather than building from scratch. This included working within constraints imposed by legacy architectures, predefined CMS structures, and client-specific workflows. Development often required balancing clean engineering practices with the realities of long-lived systems and evolving requirements, where technical decisions had to align with both editorial and operational needs. - During my time there, the organization underwent internal restructuring, with teams gradually redistributed and the department ultimately being phased out. Toward the later stages, I worked in a significantly reduced team, maintaining ongoing development and supporting project continuity. This environment required a high degree of autonomy, context switching, and prioritization, ensuring that client deliverables remained stable despite decreasing resources. - Due to NDA constraints, specific implementation details cannot be disclosed. However, the experience provided strong exposure to multi-client delivery, CMS-driven architectures, and the challenges of sustaining software systems in environments where technical, organizational, and business factors continuously shift. - Ordio GmbH | Feb 2024 – Jun 2024 | Senior Full-stack Developer - patterns: Distributed data transformation pipelines, External dependency orchestration, Constraint-aware navigation systems - tags: api, php, mysql, symfony, typescript, react - Worked on workforce management systems at Ordio GmbH, focusing on integrations, data migration, and process-oriented interfaces for non-technical users. Contributed to bridging external HR systems with internal workflows in a fast-evolving product environment. - At Ordio GmbH, I worked on a platform designed to digitize and automate workforce operations for deskless industries such as hospitality, retail, and logistics. The system combines shift planning, time tracking, employee management, and payroll processes into a unified environment, addressing operational complexity that is typically handled through fragmented tools like spreadsheets and manual coordination. - My focus was on system integration and data flow between external platforms and the internal domain. This included developing interfaces for importing and exporting employee and organizational data, integrating with third-party systems such as Workday, and supporting client migration into the platform. These tasks required handling inconsistent data structures, ensuring data integrity, and designing transformation layers that could reconcile differences between systems. - In parallel, I worked on process-oriented interfaces aimed at non-technical users, translating complex backend operations into structured, guided workflows. The goal was to reduce user error and make operational tasks such as onboarding, data management, and system interaction intuitive within a high-variability environment. - The role began in a fully remote, rapidly scaling team with multiple new hires, where onboarding processes and internal alignment were still evolving. Given the mismatch between expected impact and actual development velocity, I made a conscious decision to conclude the engagement early, prioritizing efficient use of both company and personal resources. Despite the short duration, the experience provided valuable insight into integration-heavy SaaS systems and the challenges of building reliable workflows on top of complex, real-world operational data. - Diligent Corp. | Jun 2022 – Apr 2023 | Senior Backend Developer - patterns: Legacy modernization under live constraints, External dependency orchestration, Distributed data transformation pipelines - tags: php, laravel, mysql, typescript, react, aws - Worked on governance and compliance systems at Diligent Corporation, contributing to legacy PHP systems while adapting to a transition toward AWS-based infrastructure and TypeScript. Gained experience operating within large-scale, high-complexity systems where correctness, security, and auditability are critical. - At Diligent Corporation, I worked on software supporting governance, risk, and compliance processes for enterprise organizations. These systems operate in high-stakes environments where data integrity, security, and traceability are essential, as they directly support board-level decision-making and regulatory processes. The platform integrates multiple domains, including governance workflows, audit trails, and risk management, forming a complex and tightly coupled system landscape. - My primary focus was on a legacy PHP-based system that remained a critical part of the product, while the broader architecture was evolving toward cloud-based infrastructure and TypeScript-driven services. This created a hybrid environment where existing functionality needed to be maintained and extended, while new paradigms, tools, and architectural approaches were being introduced incrementally. Entering this environment came with a clear scale shift, where the size and interconnectedness of the system exceeded what could be easily reasoned about locally, requiring a different approach to understanding and navigating complexity. - This experience marked a turning point in how I approach large systems. Working alongside the transition to TypeScript and cloud-native patterns required time to internalize new abstractions, from stricter type systems to asynchronous and distributed thinking. While the learning curve was initially steep, it led to a deeper understanding of how large-scale systems evolve, how to operate within partially understood architectures, and how to progressively build confidence in unfamiliar technologies. It also established TypeScript as a continued part of my toolkit, not as an immediate strength, but as a capability developed through sustained, practical exposure. - Future Property Trade Kft | May 2021 – May 2022 | Senior Full-stack Lead Developer (Freelance) - patterns: Physical-to-digital feedback loops, External dependency orchestration, Time-sensitive synchronization layers - tags: php, laravel, mysql, javascript, vue, aws - Building a scalable social commerce platform that turned influencer reach into fully operational product pipelines. Where audience, manufacturing, and logistics converged into a single system designed for velocity and scale. - At Future Property Trade, I led the development of a social commerce platform designed to connect high-reach influencers with end-to-end merchandise production and global fulfillment. The goal was to transform audience attention into deployable product lines, enabling creators to launch branded storefronts with minimal friction. The system combined customizable landing experiences, product configuration, and scalable backend processes to support rapid onboarding and high variability across partners. - Beyond the technical implementation, the challenge was aligning three fundamentally different domains: influencer-driven demand, manufacturing constraints, and logistics execution. I worked across architecture and delivery, guiding the team in building a system that could translate loosely defined business ideas into structured, repeatable flows. While the project ultimately shifted direction due to organizational and investment decisions, it provided deep insight into building platforms where digital intent must reliably materialize into physical outcomes. - Risskov Autoferien AG | Jan 2020 – Apr 2021 | Senior Full-stack Developer - patterns: Physical-to-digital feedback loops, External dependency orchestration, Time-sensitive synchronization layers - tags: api, php, laravel, javascript, vue, graphql, azure, mysql - Developed and maintained core systems at Risskov Autoferien AG, contributing to a multi-country travel platform focused on last-minute hotel capacity. Worked across booking flows, partner management, and public APIs within a distributed ecosystem built on Laravel, Vue.js, GraphQL, and Azure. - At Risskov Autoferien AG, I worked on a platform that connects travelers with discounted hotel stays across Europe by utilizing unused capacity in partner hotels. The system operates as a time-sensitive marketplace, where availability, pricing, and package composition must be continuously synchronized between internal systems and external partners. With hundreds of hotels and multiple country-specific platforms, the environment required handling distributed data, localization, and high variability in partner input. - My work focused on developing and maintaining key parts of the ecosystem, including booking systems, partner management tools, and public APIs. This involved ensuring that availability data remained consistent across systems, supporting reliable booking flows, and enabling external integrations. The architecture combined Laravel-based backend services with Vue.js frontends and GraphQL APIs, deployed within a cloud-based infrastructure. - A significant part of my contribution was improving partner-side operations, including internal availability calendars, communication flows, and automation processes. These improvements helped reduce manual coordination, minimize inconsistencies in hotel data, and support smoother onboarding and day-to-day collaboration with partners. - Working in a multi-national environment with diverse partners and customers provided insight into how distributed systems behave under real-world constraints, where timing, data accuracy, and operational coordination directly impact business outcomes. The experience reinforced the importance of designing systems that can handle incomplete information, asynchronous updates, and continuous change without breaking the overall flow. - TechTeamer Kft &\nMikroCredit Zrt | 2018 – 2019 | Backend Developer - patterns: Distributed data transformation pipelines, External dependency orchestration, Legacy modernization under live constraints - tags: api, php, laravel, javascript, react, mysql - Designing the backbone of a digital lending system where identity, risk, and money flow had to align in real time. A microservice-driven architecture turning fragmented financial operations into a coherent, auditable system. - At TechTeamer and Microcredit (MiniKölcsön), I worked on systems operating at the intersection of digital identity and online lending. TechTeamer’s core product, FaceKom, provided AI-assisted remote identification and video-based verification, enabling financial services to onboard customers without physical presence . This capability was directly integrated into Microcredit’s lending platform, where users could apply for small loans entirely online, from identity verification to approval and disbursement. - Microcredit was among the early adopters in Hungary to offer fully digital loan processing, combining document submission, biometric validation, and automated scoring into a streamlined flow . The system had to operate under strict regulatory and security constraints, while still delivering near real-time decisions. This created a unique environment where compliance, fraud prevention, and user experience were tightly coupled and constantly in tension. - My team focused on building a microservice-based backend responsible for customer and loan bookkeeping, forming the core system of record behind the platform. This included designing services to track user states, loan lifecycles, financial events, and audit trails across distributed components. The challenge was not just storing data, but ensuring consistency across asynchronous processes such as verification, scoring, approval, and payout, where each step depended on partially available and externally validated information. - From a systems perspective, the platform functioned as a real-time financial pipeline: identity verification triggered eligibility checks, which fed into risk evaluation and ultimately into monetary transactions. Working on this system provided deep exposure to how digital trust is constructed in practice, where every approved loan is the result of multiple loosely coupled systems agreeing on a single, high-stakes decision. - WebShippy Kft | 2018 | Full-stack Developer (Freelance) - patterns: Physical-to-digital feedback loops, External dependency orchestration, Time-sensitive synchronization layers - tags: php, custom-framework, api, javascript - Building the operational layer behind e-commerce, where digital orders become physical movement. Contributing to a system designed to scale from individual webshops toward platform-level commerce infrastructure. - At Webshippy, I worked on the core systems that connected external webshops to an internal, automation-driven fulfillment platform. My primary focus was the API layer, enabling bidirectional data flow between custom-built stores and the Webshippy system, covering customers, products, stock levels, and orders. This integration layer allowed external systems to treat logistics as an extension of their own platform, with real-time synchronization ensuring that inventory, order status, and shipment data remained consistent across boundaries. - In parallel, we built streamlined onboarding paths for widely used e-commerce platforms, enabling near one-click integrations with providers like Shopify, WooCommerce, Magento, OpenCart, and PrestaShop. The goal was to remove friction from adoption: instead of building custom integrations, merchants could plug into an existing ecosystem and immediately operate on top of shared logistics infrastructure. This shifted the system from a service provider into a platform layer. - Beyond APIs, I had a significant role in developing the operational tooling inside the warehouse itself. This included early versions of handheld “picker” devices used to navigate storage and collect items, as well as the initial “packer” software responsible for assembling shipments. One of the more interesting challenges was coordinating physical communication between packing stations and shared printing infrastructure, where timing, reliability, and clarity directly affected throughput. These systems had to function under real-world constraints, where errors are not exceptions but disruptions in physical flow. - As a team, we also contributed to shaping the early innovation and automation directions of the platform. This meant exploring how far warehouse processes could be systematized, how manual steps could be reduced or guided, and how software could better reflect the state of a constantly changing physical environment. The experience reinforced a key insight: scaling e-commerce is not just about handling more requests, but about aligning digital intent with physical execution, where every inefficiency becomes tangible, measurable, and unavoidable. - Manna Kreatív Zrt. | 2017 | Junior Full-stack Developer, Service Desk - patterns: Physical-to-digital feedback loops, Distributed data transformation pipelines, External dependency orchestration - tags: api, php, mysql, laravel, javascript - Evolving a commerce system where product, story, and customer communication form a single continuous experience. Bridging handcrafted manufacturing with a tightly integrated digital ecosystem built around trust, feedback, and narrative. - At MannaSzappan (Manna Soap), I worked on a system where the product was only one layer of a much larger structure. The company originated from a personal problem, when its founder began experimenting with soap-making to solve skin issues within her family, eventually growing into a widely recognized natural cosmetics brand used by tens of thousands of customers. This origin shaped the entire business: strong emphasis on authenticity, handcrafted production, and especially direct, ongoing communication with customers. - My role focused on evolving a large, tightly coupled monolithic system that combined webshop, CMS, CRM, mailing, chat, and operational tooling into a single integrated platform. The system handled multi-language storefronts, complex product narratives, and high-touch customer interaction flows, where communication was not an add-on but a core business function. Every product, from handcrafted soaps to skincare items, carried not just attributes, but stories, guidance, and ongoing dialogue with users. - Beyond the customer-facing layer, the system extended deep into fulfillment and manufacturing. Soap production itself followed a semi-manual, craft-driven process using natural ingredients, which introduced variability and constraints that had to be reflected in stock handling, availability, and order fulfillment. This required aligning digital representations with real-world production timelines, ensuring that what the system promised could actually be delivered within the limits of handcrafted manufacturing. - In parallel, I operated in a service desk role, acting as a bridge between business operations and the system. This included handling internal issues, resolving flow disruptions, and managing incoming requests from multiple domains such as customer support, marketing, and production. The environment continuously exposed the friction points where systems meet reality, reinforcing the importance of designing software that not only works under ideal conditions, but remains understandable and adaptable when those conditions inevitably shift. - Érték-Rendszerház Kft &\nWore Hungary Kft | 2014 – 2016 | Junior Full-stack Developer, System Admin - patterns: Physical-to-digital feedback loops, Distributed data transformation pipelines, External dependency orchestration, Constraint-aware navigation systems - tags: api, php, custom-framework, mysql, javascript - Worked across a network of small businesses spanning furniture manufacturing, retail, and hospitality, contributing to early-stage system development, internal tooling, and operational processes. Gained first-hand exposure to how disconnected business units attempt to function as a larger system, and where those connections break down. - My early professional experience developed within a loosely connected ecosystem of companies, including Érték-Rendszerház Kft, Wore Hungary Kft, Bella Italia Bútorház, SofaArt (Budapest and London), and a furniture production facility in Csepel. These businesses operated across manufacturing, retail, and international distribution, sharing overlapping ownership, resources, and operational dependencies, but lacking fully integrated systems to support that complexity. - I worked on internal tools and early software solutions aimed at supporting day-to-day operations, including inventory handling, webshop functionality, and administrative processes. Much of the work involved translating real-world workflows into digital systems, often replacing spreadsheets or manual coordination. This period also included experimental projects such as Érték Bár, where I explored low-cost POS and operational tooling in a hospitality context, extending system thinking beyond traditional software environments. - What made this experience particularly formative was the visibility into how data, materials, and decisions move across organizational boundaries. Manufacturing constraints, product complexity, logistics, and sales channels were tightly coupled in practice, but poorly connected in systems. This created friction points where information was delayed, duplicated, or lost entirely, requiring constant manual intervention. - In parallel, I gained hands-on experience in hospitality operations, including working as a bartender during high-traffic events. While unrelated on the surface, this environment reinforced the importance of real-time decision-making, clear processes, and systems that must function under pressure without failure. Together, these experiences established my foundation in thinking about software not as isolated applications, but as part of larger, interconnected systems shaped by real-world constraints. ### Education Self-Directed Learner since 200X Started with an IT-focused high school and an advanced certification, then continued with electrical engineering studies at BME, alongside contributing to Studio Schönherz and the Schönherz Electronics Workshop. Over time, I shifted toward software, where building and iteration felt more immediate. Since then, most of my learning has come through real systems, production environments, and side experiments across software and hardware. The path hasn’t been linear, but it has been consistent: learning by building, and adjusting when reality disagrees. ### PATTERNS System Patterns I’ve Worked With I design and stabilize systems that survive contact with reality. Here are the recurring patterns I have repeatedly built or improved: patterns: - **Time-sensitive synchronization layers:** Real-time availability, last-minute marketplaces, logistics flows, and irreversible data capture (Risskov, WebShippy, Archbau, Ordio) - see also: experience:#experience-risskov - Risskov Autoferien AG; experience:#experience-webshippy - WebShippy Kft; experience:#experience-archbau - Archbau GmbH; experience:#experience-ordio - Ordio GmbH; tag:api - API; tag:graphql - GraphQL; pattern:data-pipelines - Distributed Data Transformation Pipelines , - **Distributed data transformation pipelines:** Moving information across incompatible domains while preserving integrity (microservices at TechTeamer, multi-country platforms at Risskov, physical-to-digital at Archbau and early furniture operations) - see also: experience:#experience-techteamer-microcredit - TechTeamer Kft & MikroCredit Zrt; experience:#experience-risskov - Risskov Autoferien AG; experience:#experience-archbau - Archbau GmbH; tag:api - API; tag:php - PHP; tag:mysql - MySQL; pattern:external-dependencies - External Dependency Orchestration , - **External dependency orchestration:** Integrating third-party HR systems, hotel partners, e-commerce platforms, and regulatory workflows without letting external volatility break the core system (Ordio, WebShippy, Risskov, Diligent, Archbau) - see also: experience:#experience-ordio - Ordio GmbH; experience:#experience-webshippy - WebShippy Kft; experience:#experience-risskov - Risskov Autoferien AG; experience:#experience-diligent - Diligent Corp.; tag:api - API; pattern:time-sensitive - Time-sensitive Synchronization Layers , - **Legacy modernization under live constraints:** Gradually replacing or augmenting large PHP monoliths while maintaining auditability, compliance, and delivery continuity (Diligent, NextTuesday) - see also: experience:#experience-diligent - Diligent Corp.; experience:#experience-nexttuesday - NextTuesday GmbH; tag:php - PHP; tag:laravel - Laravel; tag:custom-framework - Custom Framework; pattern:data-pipelines - Distributed Data Transformation Pipelines , - **Constraint-aware navigation systems:** Guiding users through combinatorial or high-variability spaces (furniture configurator, workforce process interfaces at Ordio) - see also: experience:#experience-ordio - Ordio GmbH; experience:#experience-ertek-rendszerhaz - Érték-Rendszerház Kft & Wore Hungary Kft; tag:react - React; tag:typescript - TypeScript; tag:vue - Vue.js , - **Physical-to-digital feedback loops:** Bridging sensors, manual fieldwork, and formal records where reality itself is the source of truth (Archbau excavation, early hardware prototypes, warehouse automation at WebShippy) - see also: experience:#experience-archbau - Archbau GmbH; experience:#experience-webshippy - WebShippy Kft; experience:#experience-future-property-trade - Future Property Trade Kft; tag:php - PHP; pattern:time-sensitive - Time-sensitive Synchronization Layers; post:perspective-background - Background: How I Got Here ### 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://www.linkedin.com/in/tolacika/ - https://www.facebook.com/marshall.things ### FEATURED PROJECTS Featured Projects A handful of systems, tools, and projects I’ve built or contributed to. ### PERSPECTIVE POSTS Context & Perspective If you’re curious - here’s where I come from, how I think, and a few things beyond the work. #### POST - slug: perspective-background - type: perspective - title: Background: How I Got Here - teaser: How I moved across software, hardware, and real-world environments - and why I think in systems today. - cta: Explore More - date: 2026-04-01 10:00:00 - 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 is everything around it. Building electronics. Working in commerce. Handling deliveries. Prototyping hardware. Running small experiments that had no immediate business value, but quietly built intuition about how things behave outside the screen. A temperature sensor for commercial fridges. An RFID access system. A weather station. A barely-working ESP camera stream running at seven frames per second. 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 understanding how things interact, not just how they work in isolation. That’s where I feel useful. And that’s where I keep going. --- #### POST - slug: perspective-vision - type: perspective - title: Vision: When Systems Meet Reality - teaser: Systems look stable - until reality disagrees. This is where they begin to reveal what they really are. - cta: null - date: 2026-04-01 10:00:00 - content: | I don’t hate systems. That would be easier. What I feel is closer to tension. A quiet awareness that what we build and what actually happens 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. 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 remain understandable when reality disagrees. --- #### POST - slug: perspective-side-quests - type: perspective - title: Personal Notes: Beyond Work - teaser: Fragments from outside the main path - ideas, observations, and quiet experiments. - cta: Read More - date: 2026-04-01 10:00:00 - content: | This is not a structured story. It’s a collection of fragments. --- 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. 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, in a way that survives time. This portfolio is part of that effort. --- 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. 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. ### Post Scriptum If you’ve read this far, thank you. Truly. Putting this page together — and living the experiences it tries to describe — took longer than I expected. Every line is a small attempt to turn messy reality into something a little more understandable. The fact that you stayed with it means a lot. Whether a particular project, a perspective post, or just a passing detail stuck with you, I’m grateful you took the time. I’m still the same person who prefers fixing real friction over polishing surfaces, so if anything here feels worth a conversation, I’d be happy to continue it. ### TAGS #### PHP [php] 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. - see also: tag:laravel - Laravel; tag:symfony - Symfony; pattern:custom-framework - Custom Framework; tag:api - API #### Custom Framework [custom-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. - see also: tag:php - PHP; pattern:legacy-modernization - Legacy Modernization; tag:api - API #### Laravel [laravel] 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. - see also: tag:php - PHP; tag:api - API; tag:mysql - MySQL; tag:vue - Vue.js #### MySQL [mysql] 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. - see also: tag:php - PHP; tag:api - API; tag:graphql - GraphQL; tag:laravel - Laravel #### React [react] 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. - see also: tag:typescript - TypeScript; tag:javascript - JavaScript; tag:api - API #### Neos CMS [neos-cms] 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. - see also: tag:php - PHP; pattern:custom-framework - Custom Framework; tag:html - HTML #### JavaScript [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. - see also: tag:typescript - TypeScript; tag:react - React; tag:vue - Vue.js #### TypeScript [typescript] 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. - see also: tag:javascript - JavaScript; tag:react - React; tag:api - API #### HTML [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. - see also: tag:css - CSS; tag:javascript - JavaScript; tag:neos-cms - Neos CMS #### CSS [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. - see also: tag:html - HTML; tag:react - React; tag:vue - Vue.js #### API [api] 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. - see also: tag:php - PHP; tag:graphql - GraphQL; tag:laravel - Laravel; tag:aws - AWS #### Symfony [symfony] 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. - see also: tag:php - PHP; tag:api - API; tag:mysql - MySQL #### AWS [aws] 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. - see also: tag:api - API; tag:azure - Azure; pattern:distributed-systems - Distributed Systems #### Vue.js [vue] 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. - see also: tag:javascript - JavaScript; tag:laravel - Laravel; tag:html - HTML #### GraphQL [graphql] 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. - see also: tag:api - API; tag:mysql - MySQL; tag:typescript - TypeScript #### Azure [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. - see also: tag:api - API; tag:aws - AWS; pattern:distributed-systems - Distributed Systems; pattern:cloud - Cloud ------------------------- ## TASK ------------------------- [userTask]