Hi, I'm Alex
Research · Risk · Operations
What I doI help teams investigate operational problems, understand risk, and make sense of messy systems and processes.My work can include research and OSINT, due diligence, operational investigations, process analysis, and intelligence gathering — depending on what the problem requires.Who I helpI work best with founders and small teams dealing with operational complexity, risk, uncertainty, or problems that are difficult to see from inside the system.Problems I solveYou may know that something is wrong, but not what is actually happening, why it is happening, or where the problem sits.
I help you find that out — and determine what to do about it.
My work sits at the intersection of investigation, operational intelligence, risk, and systems.
I’ve spent most of my career working inside real-world operations rather than following a conventional career path. I’ve built and run small businesses, managed teams and contractors, coordinated logistics in Germany, worked in quality control, and spent 3.5 years progressing through operational roles at eBay.Across very different environments, the work kept coming back to the same problem:What is actually happening here — and what needs to change?That means looking beyond the documented process. Understanding where controls break down, where people work around them, where information gets lost, and where the reality of an operation differs from how it is supposed to work.I’m most useful when the situation is messy: fragmented information, unclear ownership, inconsistent processes, operational risk, or something that doesn’t quite add up.I investigate the situation, connect the evidence, identify what is actually happening, and turn that understanding into practical action.
Something isn’t adding up? Let’s find out what’s really happening.
Systems & Workflow Investigation
I help you find that out — and determine what to do about it.
Investigations & Intelligence
Investigative research
OSINT investigations
Company & people research
Suspicious activity research
Behaviour / pattern investigation
Marketplace abuse investigation
Research briefs
Competitive intelligence
Evidence gathering and analysis
Investigation support / overflowCTA
Risk & Due Diligence
Company due diligence
Third-party due diligence
Supplier / partner research
Reputational risk research
Counterparty research
Risk mapping
Background research
Pre-engagement research
Ongoing monitoring research
Risk & Marketplace Operations
Suspicious account / activity investigation
Marketplace risk investigations
Fraud / abuse investigation support
Case investigation
Pattern identification
Investigation backlog support
Risk operations support
Manual review / quality investigation
Process and control analysis
Operations & Process
Operations support
Delivery coordination
Operational problem-solving
Process improvement
Workflow analysis
Process documentation
SOP development
Operational quality review
Cross-functional coordination
Systems & Workflow Investigation
Manual workflow testing
Operational QA
User / operator journey testing
Process-vs-system gap analysis
Failure-point identification
Workflow troubleshooting
Operational requirements analysis
Recommendations for process / product improvements
I've spent most of my career building and operating things rather than following a conventional career path.
Research
I approach unfamiliar problems by first understanding how the system actually works.Throughout my work, research has usually been practical rather than academic. I investigate how people, processes, information, tools, and dependencies interact, identify where the real bottlenecks or risks are, and use that understanding to decide what should change.Whether I was investigating risk patterns at eBay, understanding why a repair operation wasn't working, mapping a paper-based logistics workflow, or figuring out how to coordinate external freelancers, I tend to start with the same approach:Observe → Investigate → Connect the dots → Identify the real problem → Decide what to change.For me, research is not the final deliverable. It is the foundation for building better operations.
Operations & Risk
Progression from Seller Support to Risk Operations at eBay
Building a Distributed Freelance Delivery Operation
Digitizing and Coordinating a Logistics Operation in Germany & Poland
Let's figure out what's happening.
Audit / Reset
Short engagement
For situations where something isn't working and you need an outside perspective.I investigate the situation, identify the main bottlenecks or risks, and give you a practical picture of what is happening and what could be changed.
Project
Defined scope
For a specific operational, investigative, or systems problem.I take ownership of the defined problem and work through the investigation, analysis, process design, implementation, or other agreed deliverables.
Fractional
Ongoing support · 5–20 hours/week
For teams that need someone to take ongoing responsibility for investigation, operations, risk, or process improvement without hiring a full-time specialist.
Start with the problem
You don't need to know which engagement model you need.
Tell me what is happening, and I'll help determine the appropriate way to approach it.
Let's talk
From Informal Repair Work to a Multi-Location Operation
Building a functioning repair operation from an informal setup, developing people into operators, and scaling execution across multiple locations.
Context
Initially, my role was simple: I collected phones from customers, and the owner would pick them up once or twice a day, take them for repair, and return the repaired devices.As the operation became less reliable, I started taking responsibility for more of the process. I built relationships with experienced repair technicians, sourced parts myself, coordinated repairs, and returned completed phones to customers.Eventually, I was effectively running the day-to-day delivery while the original owner became less involved.When his father later tried to take over the business after seeing that it had become successful, I chose to end the relationship and build my own operation instead.What I did
IA few weeks later, I found an opportunity to take over an empty location inside a supermarket.
The director told me I needed to become self-employed to rent the space. I registered as self-employed and started operating independently within days.From there, I built the operation progressively.Building the first team memberInitially, I was handling almost everything myself.To reduce the amount of time I spent on errands and parts collection, I hired a local person who had been around the business and knew the area.His initial responsibilities were simple: collecting and delivering phones and purchasing parts.As I saw potential in him, I gradually taught him repair work and increased his responsibilities. He moved from occasional support to regular work and eventually became a full-time operator, with compensation tied to the business's performance.This allowed me to delegate more of the actual repair work while focusing on customers, sourcing, coordination, and the broader operation.Scaling to additional locationsOnce the first operation was working, I started looking for opportunities to replicate the model.I opened a second location in another part of town and recruited another person to operate it.Rather than trying to personally run both locations, I structured the second operation around its own operator and repeated the delegation model that had worked previously.I also opened a third location, but the location itself proved unsuitable and I closed it relatively quickly.Instead of continuing to spread my attention across every location, I focused on the second location because it demonstrated stronger potential.Moving from ownership to delegationEventually, the first location had its own capable operator.We initially agreed to split the business 50:50, but as the second location required more of my attention, I realized that continuing to manage everything myself would turn me into the bottleneck.I ultimately gave the first location to the operator who had helped build it.The result was not simply multiple locations—it was an operation where another person could independently own and run one part of the business.Result
I progressed from working in an informal repair arrangement to building and operating my own self-employed repair business.Over time, I:- Built a functioning repair operation from scratch.
- Established supplier and technician relationships.
- Progressively delegated operational responsibilities.
- Developed an informal helper into a full-time repair operator.
- Opened and tested multiple locations.
- Built a second location around another operator.
- Closed an underperforming location rather than continuing to invest in it.
- Shifted management attention toward the operation with greater potential.
- Eventually transferred ownership of the first location to its operator.The biggest lesson was that scaling isn't simply about opening more locations. It's about creating enough ownership and structure that other people can operate them without everything depending on you.What I Bring to ClientsI have practical experience building operations from the ground up and progressively removing myself from the parts of the business that can be delegated.My approach is:Start small → Understand the workflow → Build the process → Develop people → Delegate ownership → Test the model → Scale what works → Remove what doesn'tThis is the same principle I apply to operational problems today: find the bottleneck, build around it, create ownership, and make the operation less dependent on a single person.
Building a Distributed Freelance Delivery Operation
Designing a remote delivery model that connected client demand with distributed external talent.
Context
In 2020, my girlfriend and I started freelancing on Fiverr. We developed a recurring relationship with a client whose work became a significant part of our business.Rather than personally executing every task, we built a delivery model around external freelancers. This allowed us to take responsibility for the client relationship and overall delivery while distributing production work across a remote network.The challenge was to make that model reliable: the right people needed to receive the right tasks, understand the requirements, meet quality expectations, and deliver on time.What I did
I became the operational layer between the client and the people performing the work.I handled:- Client communication and requirement gathering.
- Breaking projects into clear tasks and deliverables.
- Selecting and coordinating freelancers based on the work required.
- Briefing contributors and communicating requirements.
- Managing work across multiple people and locations.
- Reviewing deliverables and maintaining quality standards.
- Coordinating revisions and resolving delivery issues.
- Managing deadlines and final delivery to the client.
- Taking on additional one-off projects across design, consulting, and website audits.My girlfriend supported the operation as a facilitator, while I focused on coordinating the overall delivery system.The important shift was from personally performing the work to designing and managing a system that could reliably produce the work.Result
We built a functioning distributed service operation that could support recurring and one-off projects without requiring us to personally perform every production task.The model allowed us to:- Expand delivery capacity beyond our own working hours.
- Match different types of work with different specialists.
- Coordinate contributors remotely.
- Maintain a single point of responsibility for the client.
- Handle multiple projects without building a traditional in-house team.The experience gave me practical experience in distributed operations, contractor management, quality control, workflow design, and service delivery.What I Bring to ClientsI understand what happens between "the client wants this" and "the work is successfully delivered."I can help businesses design that layer: breaking work into processes, assigning responsibilities, coordinating distributed contributors, establishing quality controls, and creating workflows that don't depend on one person doing everything themselves.
Digitizing and Coordinating a Logistics Operation in Germany & Poland
From day-to-day logistics coordination to designing and digitizing the operational system behind it.
I understand operations as a system of dependencies—not simply as a list of tasks.
Context
n 2018, I moved to Germany and joined a logistics operation working across Germany and Poland as a Disponent (Logistics Coordinator).The operation was heavily dependent on physical documentation and manual coordination. Orders were managed through physical folders, while invoices, CMR documents, faxes, and other paperwork moved between people as part of the daily workflow.My role was to coordinate the operation and keep activities moving, but I quickly saw that the way information was organized created unnecessary dependencies on paper, manual communication, and individual knowledge.The owner wanted to move the operation toward a more digital workflow rather than remain dependent on physical documentation.**.What I did
I went beyond the day-to-day coordination role and worked on designing, creating, testing, and implementing a more digital operating system.- Mapped how orders and operational information moved through the business.
- Identified where the existing paper-based workflow created delays and dependencies.
- Designed a digital approach for organizing and accessing operational information.
- Created and tested the new workflow before transitioning it into day-to-day use.
- Supported the transition from physical folders and paper-based processes toward digital operations.
- Worked with documents including orders, invoices, CMRs, and other operational records.
- Designed and managed a GPS-based system for monitoring and coordinating trucks.
- Created a visual system using colors and assignments to give each dispatcher clear responsibility and visibility over their vehicles.
- Coordinated logistics activities across different locations and people.
- Continued managing daily operations while improving the systems supporting them.The important part was that I wasn't simply using an existing system.I was designing the system while simultaneously operating within it.Result
The operation began moving away from a workflow dependent on physical folders and manual document handling toward a more structured digital system.The new approach improved visibility over orders, documentation, and vehicle allocation while reducing dependence on paper-based coordination.The GPS and visual allocation system also gave dispatchers a clearer overview of the trucks and their responsibilities.My role evolved beyond traditional dispatching: I was simultaneously coordinating operations, identifying inefficiencies, designing solutions, testing them, and managing their transition into real-world use.What I Bring to ClientsThis experience taught me how to improve operations from inside the operation itself.I can work with businesses where processes have developed organically over time and help transform them into more structured systems:Understand → Map → Design → Test → Transition → Operate → OptimizeWhether the problem is paper-heavy administration, fragmented information, unclear responsibilities, manual coordination, or limited operational visibility, I focus on building systems that make the operation easier to manage and less dependent on individual people.
Progression from Seller Support to Risk Operations at eBay
From frontline operations to risk investigation, process design, and operational optimization.My experience at eBay took me from frontline Seller Support through Premium Services and ultimately into Risk Operations. This gave me a perspective across the full operational chain—from handling individual cases to identifying systemic problems and designing processes to address them.
Context
I started in Seller Support and progressively moved into Premium Services and Risk Operations.Working across these functions allowed me to see how operational problems developed at different levels: how they appeared to frontline agents, where existing workflows created gaps, and how individual cases could reveal broader operational or risk patterns.When I moved into Risk Operations, I began focusing on patterns that were difficult to identify through standard workflows and on turning those observations into structured, repeatable processes.The Challenge
One of my first major challenges involved a suspected coordinated-abuse pattern that was difficult to establish using the existing process.The issue was known among frontline teams, but there was no sufficiently clear workflow for consistently identifying, documenting, and escalating cases of this type.Rather than treating each case independently, I started looking for the broader pattern—recurring behaviors, relationships between cases, and signals that could help distinguish legitimate activity from coordinated abuse.Later, I applied a similar approach to account-takeover risk, where individual cases could be difficult to establish without looking at the wider pattern.What I did
I approached these problems as operational systems rather than isolated cases.- Investigated recurring patterns across cases and accounts.
- Documented relevant signals and indicators to support investigation and decision-making.
- Learned from experienced agents and incorporated effective practices into my own approach.
- Worked with team leads and colleagues to validate findings.
- Turned repeated investigative decisions into structured, repeatable procedures.
- Helped establish new SOPs for more consistent handling across teams.
- Continuously refined workflows as new patterns and edge cases appeared.
- Identified opportunities to automate and optimize repetitive operational work.The key shift was moving from:"How do we handle this case?"
to:
"How do we build a process that handles this type of case consistently?"Result
The work contributed to new operational procedures being introduced across teams and incorporated into the handling of similar risk cases.Over time, colleagues began bringing comparable cases and questions into the process rather than treating them as isolated incidents.I also progressively structured, optimized, and automated much of the repetitive workflow, reducing the amount of manual work required and creating more capacity for higher-value investigation and problem-solving.Most importantly, my role evolved from executing an existing process to identifying operational gaps, investigating underlying problems, designing solutions, and turning them into scalable processes.What I Bring to ClientsThis experience is the foundation of how I approach operational and risk projects today.I can work across the full operational chain:Frontline Operations → Quality → Investigation → Risk → Process Design → SOPs → Automation & OptimizationIf your team is dealing with recurring operational problems, inconsistent decision-making, manual investigations, unclear workflows, or processes that have grown organically over time, I can help turn them into structured, repeatable, and scalable systems.