Professional profile · Architecture and leadership
I work across business reality, software, data, infrastructure and people. I reconstruct unfamiliar problems, find the governing decision and carry a dependable solution into operation.
Architecture, leadership and delivery
The work behind this profile spans implemented systems, measured runs, code and project history. Follow the examples to see how I approach difficult problems and what I can take responsibility for.
Explore my working method, technical range and leadership through the systems, decisions and outcomes that shaped them.
Professional profile
I work at the point where a difficult operational problem needs one person to hold the system together: the business meaning, the technical design, the delivery path and the operating consequences.
“I make complex reality reconstructable: find the failure beneath the visible symptom, expose the governing rule and turn it into a solution people can inspect and operate.”
My differentiator is not one language or product. It is getting productive in unfamiliar systems quickly, making the real operational problem explicit and turning uncertainty into a clear design and dependable delivery.
My work spans principal solutions architecture, technical R&D leadership, technology-function leadership, client solutions and platform ownership. The exact title matters less than the mandate to connect the whole decision.
My technical foundation combines live audio, lighting, software and scripting. In concert and broadcasting systems, I used automation, equipment configuration and system integration alongside signal flow, electricity and physical fault diagnosis. Independent web delivery and developer leadership broadened that work into business applications, data, infrastructure and applied AI.
The same problem-solving approach holds across unrelated domains: trace the system, understand the constraints and make the result dependable. The project record shows how that translates into systems built, decisions made and outcomes owned.
My work includes direct engineering, architecture, technical direction and team delivery. The portfolio connects those responsibilities to concrete examples, with working models, code and the decisions behind them.
Career / Earned scope
From live production to independent client delivery and technical leadership, the setting has changed. Understanding the whole system and solving the real problem has remained the thread.
I joined Fortis in 2021 for a supplementary stable income stream, alongside independent client delivery and programmer leadership. The initial remit was telemarketing and field-service coordination, not the beginning of my technical problem-solving career. I built the overview the process lacked, then separated tools by audience: agent/customer-service capacity and routes, and coordinator-only area history and planning. Their usefulness and longevity exposed a recurring need for dedicated technical work.
I turned that need into Fortis R&D, helped add developers and led the evolution of Insight. The wider business has historically included approximately 50–150 remote agents. That is operational context, not the size of my engineering team.
Today I connect product and domain direction, architecture, developer support, infrastructure and selected external engagements. Major spending remains with company leadership. Technical structure, sequencing, refactoring and quality sit largely with me.
Website work became my main income after becoming location-independent. Growing demand exceeded my own implementation capacity, so I hired programmers and moved into scoping, direction and quality assurance across client deliveries.
A central production and technical role across live broadcasts, events, podcasts and studio recording. Readiness and live fault resolution mattered as much as the output.
Signal flow, grounding, interference, impedance, DMX, MIDI and console-triggered automation. A practical systems education in environments where failure was immediate and the whole path had to be understood.
01 · How I work
A request is often only the visible symptom. I trace data, behaviour, incentives, exceptions and failure modes until the real decision is clear. Then I make the rule inspectable before the implementation hides it.
Learn the work from inside and identify where labels, data and reality disagree.
Separate facts, policy, assumptions and exceptions into an explainable decision.
Use examples, counterexamples, code and measurement where prose could create false confidence.
Choose a durable platform, adapted reuse or a narrow tool according to lifecycle and risk.
Leave people with the model, constraints and acceptance evidence they need to own the result.
02 · Distinctive capability
Across unrelated environments, the recurring pattern is systems reasoning with ownership: understand the dependency model, locate the invariant and turn it into something another person can inspect and operate.
I infer architecture and behaviour from interfaces, outputs and inconsistencies. When documentation or precedent does not exist, I use experiments and first-principles reasoning rather than stopping at the abstraction.
I connect business process, application logic, data, infrastructure, security and human workflow into one solution model. A locally sensible decision is not accepted if it makes the system worse somewhere else.
I turn human judgement into logic that remains fair, testable and explainable when time, ownership, exceptions and imperfect records interact.
I build what the constraint demands while understanding existing code and dependencies deeply enough to adapt and own them. Reuse is not a black box and novelty is not a virtue by itself.
Walkthroughs, sample data, counterexamples, pseudocode and working proofs carry difficult intent to developers, stakeholders and AI, preserving the context behind each important decision.
I explain the mechanism behind consequential decisions and revise the model openly when evidence changes it. That makes the reasoning clear enough for others to use and build on.
I normally give the causal bridge behind a consequential decision so another person can challenge it, implement it and recognise when the premise has changed.
I correct the model openly when new evidence changes it. I keep facts, assumptions and open questions clear so the next decision starts from a sound basis.
Truth, reliability, consequential edge cases and visible craft deserve deep attention. Low-risk cleanup can wait when the operational need is more urgent.
I use developers, AI and existing work readily, but only where the result can be understood, verified and responsibly owned.
A rule can be mechanically consistent and still be operationally false. I test policy against attribution, control and real human consequence.
Current tool knowledge determines where investigation begins, not the limit of the result I will accept.
03 · Professional range
The continuity from discovery to operation prevents important meaning being lost at each handoff. Specialists are brought in where depth or capacity requires them, but the overall decision remains coherent.
Process, incentives, failure modes and the actual need beneath the request.
Data meaning, decisions, interfaces, security and system boundaries.
.NET, Blazor, PowerShell, JavaScript, APIs, SQL, web systems and applied AI.
Developer direction, specialist coordination, acceptance evidence and governance.
Observability, recovery, performance, maintainability and iterative refinement.
From opportunity discovery and feasibility through scope, assumptions, specialist procurement, delivery governance and sustainable service models.
Documented and undocumented APIs, browser-compatible flows, acquisition, normalization, enrichment and operational analytics.
Self-managed Kubernetes, CI/CD, persistent storage, monitoring, controlled ingress, backup paths and pragmatic operational security.
04 · Leadership
Across live production, independent client delivery and technical R&D, I have repeatedly made overlooked problems solvable. The same systems approach connects architecture, product direction, developer leadership, platform responsibility and client delivery.
My role is to make the difficult parts clear enough that people can build around them. Routine implementation can be delegated. High-consequence intent is transferred through shared reasoning and executable evidence.
Understand the work from inside.
Remove immediate friction with something real.
Expose the shared need and governing rule.
Provide people, process, direction and accountable delivery.
Business and technical discovery, solution and workflow architecture, feasibility and dependency analysis, technical direction, implementation planning, prioritisation and quality assurance.
Documented and undocumented integrations, automation, acquisition and enrichment, operational analytics, business-rule design and controlled AI-assisted processing.
Opportunity discovery, solution shaping, proposals, scope and assumptions, specialist procurement, delivery governance, contract boundaries and ongoing-service design.
Self-managed application platforms, CI/CD, persistent storage, monitoring, controlled ingress, recovery paths, operational security and practical administration.
I am hands-on with C#, .NET and Blazor architecture, implementation, debugging and review; PowerShell; JavaScript, HTML/CSS, PHP and Apps Script; SQL Server, PostgreSQL, SQLite and MySQL variants; Linux, Bash, Python and Groovy as required. Earlier work includes C/C++ and embedded control systems.
I choose the appropriate level of engineering: a careful narrow tool when it is truly enough, adapted reuse when the foundation is sound, or a durable application and operating platform where people will depend on it.
05 · Communication
My communication style is practical. A working discussion tests the model using real examples. Once the decision is understood, direction becomes direct, traceable and usable by the person taking the next step.
I use concrete cases to expose a false premise, test a rule and revise openly. The goal is a shared model that leads to clear decisions.
Technical peers receive mechanism. Leaders receive consequence, governance and decision framing. Operations receives sequence and ownership. The facts stay consistent.
Direction normally includes the causal bridge needed to survive handoff. I advocate from contribution and consequence, and own correction when better evidence is available.
06 · In practice
My contribution is usually the combination of investigation, a better model, direct engineering and a path other people can operate. These are recurring forms that work takes.
I model histories, ownership, time zones, tolerances and exceptions explicitly so outcomes remain fair and auditable when the source data changes.
I reconstruct authentication and protocol behaviour, preserve durable state and add idempotency, recovery and audit evidence around brittle external systems.
I shape concurrency around network, memory, database and stage limits. Throughput matters, but so do backpressure, cleanup, observability and restart behaviour.
I separate provider schemas from business-owned concepts so a working first system can evolve into a durable multi-source architecture without discarding what it taught us.
I can take an opportunity through discovery, feasibility, scope, assumptions, specialist procurement, contract boundaries, delivery governance and ongoing service.
AI is part of my everyday engineering workflow, from investigation and design to implementation, testing and review. Problem definition, constraints, acceptance, integration and production consequences remain mine, and generated work is tested according to risk. In the 2026 analytics work, this means explaining the operational reason for a rule, using real timelines to challenge the model, and keeping attribution, permissions and review decisions explicit. The leverage comes from turning a clear operational model into a dependable product without losing the intent along the way.
07 · What stands out
The strongest signal is the repeated ability to enter an unfamiliar system, find the decision that actually governs it and stay accountable as the answer crosses technical and organisational boundaries.
I move between software, data, infrastructure, operations, physical systems and commercial delivery, connecting the specialist knowledge each problem needs. I go deep personally where the governing risk demands it.
I choose between a narrow tool, adapted reuse, direct engineering and a durable platform according to consequence and lifecycle—not according to which technology is fashionable.
Examples, counterexamples, measured runs, code, decision records and visible boundaries make the result challengeable. Another person can see why it works and where it stops.
The record includes creating a technical function from demonstrated need, providing platform capability, supporting operational recovery and carrying product and client responsibility beyond a narrow engineering assignment.
I explain what I believe, why I believe it and what would change the conclusion. That keeps the reasoning explicit and the decision clear enough to improve.
I do not consider a design finished at the diagram. Deployment, authentication, failure handling, monitoring, recovery, user behaviour and maintainability are part of the same system.
08 · Maker mindset
My technical foundation spans physical systems and code. Software and scripting were part of concert and broadcasting work: automating tasks, connecting systems and configuring hardware, alongside signal flow, electricity and fault diagnosis.
I still repair objects, design and print functional parts, modify electronics and improve machines for safety, capability and longevity. Across hardware and software, the instinct is the same: understand what is actually happening, respect the constraints, expose the failure and leave the system more useful and maintainable than I found it.
It makes abstraction a choice rather than a hiding place. I am comfortable tracing a behaviour through physical constraints, user workflow, data, infrastructure and code until the real boundary is visible.
That is why the same approach appears in fault diagnosis, offline policies, business-rule engines, integrations and operational platforms. The material changes; the habit of making a system understandable does not.
History / Live production
Sound engineering, events and live broadcasting brought hardware, software and people into one working system. Automation, configuration and signal flow all served the same requirement: the production had to work when it went live.
Picture, sound, switching and monitoring had to work as one signal chain. With a broadcast live, a fault was not a ticket for later. I built and worked behind these systems with my coworkers, where readiness and fault diagnosis were part of the job.
The challenge was not one API call. It was reproducing browser-oriented authentication, retaining durable state and safely coordinating several systems with different concepts of a candidate.
The population-data system grew from early parallel experiments into a long-running processing runtime that feeds completed work through dependent national-data stages without imposing full-batch barriers.
The Hanna invoicing workflow automated daily enrichment of customer invoices with property identifiers and personal identity data—a task considered impractical to perform manually at operational volume. It handles messy input through progressively broader identity searches, accepts only unique results, records match strength and uses coordinate perturbation when map points fall near property boundaries.
The Amazon and Eva projects show AI used as an engineering component: inputs are prepared, outputs constrained, costs measured, results normalized and the final data made useful to an operational workflow.
I designed and built the complete spreadsheet layer. Provider A-connect feeds complementary audience-specific surfaces, while formula-driven time grids, data movement, policy logic and exception states behave like application code inside a far less forgiving language.
The real-estate exporter turns several CRM endpoints into a user-facing qualification workflow. It gathers viewing participants, excludes unsuitable contacts through parallel checks and produces ready-to-use exports.
Independently created a multi-system recruitment pipeline processing about 60 daily applications. Replaced an expanding manual backlog and reduced lost or delayed candidates by an estimated 60–75%. Includes browser-compatible authentication, OTP/TOTP, GraphQL ingestion, durable state, idempotent synchronization, outcome reconciliation and operational logging.
Brought a client opportunity through solution shaping, alternative commercial models and a signed fixed-fee engagement. Scoped a 16–22 week Pimcore-to-WordPress transformation spanning discovery, UX/UI, multilingual governance, approximately 40 pages, 35 GB of assets, integrations, migration, SEO transition, QA, training, launch and warranty. Drafted the client agreement and risk controls, recruited and contracted specialist implementation capacity, aligned subcontractor milestones with delivery, and designed post-launch support plans for continued revenue.
I lead the design and evolution of an internal platform spanning sales performance, KPI analysis, work logging, CRM workflows, protocols, reporting and external-system integrations. It progressed from spreadsheet-proven rules through React and Blazor generations into Insight Web’s business-owned canonical model, normalizing projects, interactions, sales processes and bookings across three providers. I defined the domain logic, architecture and product direction, worked with developers on application delivery and directly implemented selected high-complexity features: authentication and container integration, offline service workers, reporting and the 2026 temporal qualification engine. The latest work connects manager and agent analytics with inspectable qualification rules, review workflows, source/custom/paid-time totals, own-activity permissions and historically fair booking/order attribution. Real timelines and operational counterexamples guide the design and acceptance decisions.
Conceived the algorithm that turns mutable booking records into fair, historically accurate performance events. It reconstructs each customer’s chronology, divides activity into project-configurable commercial cycles, prevents repeated records from inflating results, preserves original booking credit, dates later cancellations and deletions as separate debits, restores fully soft-deleted histories, and attributes resulting orders to the original booking owner. I derived the rules from deep knowledge of what the available data represents and how it is used or misused, verified the edge cases, then conveyed the solution through meetings, functional snippets, clean sample datasets and pseudocode for reliable .NET implementation.
Designed a six-stage acquisition and enrichment runtime for Swedish person, geographic, property, vehicle, pet, employment and company information. Live MSSQL evidence contains 7,947,815 people; 502,253 distinct IDs were completed on 23 June 2024, a historical 24-hour average above 20,000/hour, not a general throughput promise.
Consolidated fragmented histories for roughly 45,000 customers, restoring operational visibility and supporting renewed active handling; about 13,000 were ultimately classified as expired or lost. Related PowerShell systems normalized purchased lists, enriched people, properties and companies across several sources, applied geographic/recency/ownership/phone rules and delivered processed records into signed Provider A calling workflows.
Built a pipeline to retrieve recordings, transcribe calls and return structured metrics for customer profiling, agent coaching and performance analysis across telemarketing systems.
Directed the architecture and optimization of a large catalogue-acquisition system, mentoring a developer in concurrency, resource limits, network resilience, database performance and retry design; then created AI-assisted vendor classification and commercial sizing workflows.
I replaced rigid clock-hour validation with a C#/.NET engine that interprets a full day as timezone-safe activity intervals. It finds call-density-supported spans, clusters continuous activity, earns capped gap recovery from productive work, identifies eligible lunch, combines different project thresholds proportionally, and emits an explainable timeline of qualified, missing, lunch and tolerated time. I stepped into direct implementation when the policy's interacting rules were losing fidelity through normal handoff layers. The development sequence shows my working method: build the complete model, tighten it against real boundary cases such as lunch treatment and zero-duration calls, then make remaining judgement visible through validation, warnings and controlled review rather than burying it in hidden rules.
Created a .NET/Blazor foundation with a carefully designed service-worker approach enabling offline behaviour for defined request classes and cached resources—solving a repeated weakness across previous WASM projects.
Turned CRM bookings, dialer history, customer geography, open slots and map data into audience-specific field decisions. Akono Helper serves agents and customer service with capacity and route validation; the separate coordinator workbook supports area recency, readiness and geographic sequencing. Both survived far beyond their intended prototype life and helped establish the case for R&D and Insight.
Built an access-controlled browser application for selecting offices and date ranges, retrieving paginated CRM participants, concurrently checking booking/buyer/seller/contact/property conditions, tracking progress and query outcomes, persisting preferences and generating CSV or XLSX exports.
Status matters: the commercial case establishes a signed and scoped engagement, not completed launch. Platform recovery architecture is not the same as a tested restore. Estimated reductions remain estimates.
11 · Roles and responsibilities
The strongest fit is a role where ambiguity is part of the job and technical decisions must survive contact with operations, clients and commercial reality.
Principal solutions architect, technical R&D lead or technical client-solutions lead describe the work I do best. They reflect difficult solution design, business-rule authorship, developer leverage, infrastructure ownership, operational accountability and commercial solution formation.
Head of R&D or technology fits where the mandate is hands-on and the organisation needs one accountable technical centre across architecture, platforms, delivery quality and product direction.
My experience centres on small and mid-sized organisations where architecture, product direction, platforms and delivery need one accountable technical lead. I work close to the systems and the decisions, combining principal-level engineering with functional ownership.
12 · Explore my work
Explore the portfolio for the engineering, working models and operational decisions behind these capabilities. Each case connects the problem to the approach, my role and the result.
