Business ↔ Technology
I can move between customer conversations and technical implementation: understand what someone actually needs, challenge assumptions, then turn the result into a concrete technical approach.
About me
My background is a mix of consulting, solution engineering, software development, integrations and infrastructure. I enjoy the space where the problem is not fully defined yet — because that is where asking the right questions and building a small experiment can create more clarity than another meeting or document.
Builder mindset
I would rather have a rough working prototype tomorrow than a perfect architecture diagram next month. A prototype gives everyone something real to react to.
Comfortable with ambiguity
When information is missing, I make assumptions explicit, try an approach and let reality provide the next piece of information. I ask for help when I have exhausted the useful experiments I can do myself.
Curious by default
I regularly pick up unfamiliar technologies by playing with them. I care less about memorising every feature and more about understanding what a tool can actually do.
Selected projects
NDA-safe examples of things I have built or helped shape. Customer names, screenshots and proprietary implementation details are intentionally omitted.
AI Support Assistant
Prototype chatbot embedded into an ERP interface. It used company documentation and defined behaviour to answer questions, provide relevant links and route users toward support when the chatbot could not help.
Case study
Problem: Users needed a faster way to find product and support information without searching through documentation manually.
Approach: Created a focused chatbot with supplied documentation and behavioural rules, then integrated it directly into the ERP workflow.
Result: A tangible prototype that demonstrated the user experience and showed how AI could sit directly inside an existing business process.
Infrastructure on Demand
Terraform-based AWS environments for quickly evaluating and demonstrating API gateway technologies. Provision, configure, demonstrate, preserve what matters, then destroy the environment again to avoid unnecessary running costs.
Case study
Problem: Comparing several gateway technologies manually made demos and evaluations slow and repetitive.
Approach: Designed reusable Terraform infrastructure covering Gravitee, Kong, Envoy, Broadcom Layer7 and Boomi, with APIs imported and configuration automated.
Result: A repeatable demo environment that could be created when needed and shut down afterwards.
API Translation Layer
REST-based integration layer translating modern API requests to legacy ERP endpoints, allowing different backend generations to coexist behind a more consistent interface.
Case study
Problem: A legacy backend exposed endpoints that did not match the interface expected by newer consumers.
Approach: Built a translation layer that accepted the desired REST contract and converted requests to the legacy system's format. The approach was later extended to support a newer backend generation as well.
Result: Consumers could work against a stable integration concept while the underlying systems evolved.
Lead Territory Visualization
Customer-facing map experience combining ERP lead data with Google Maps and territory information. Users could see territories, lead locations and status details directly on the map.
Case study
Problem: The customer needed a visual way to understand which franchise or territory owned which leads and where those leads were in the process.
Approach: Connected ERP data to Google Maps, added territory overlays and interactive lead markers, and surfaced lead details on selection.
Result: A business-facing visualisation that turned distributed CRM data into an immediately understandable map.
Dynamic Workflow Board
Replaced a frontend component that had become commercially impractical with a rapidly built alternative. The first version prioritised functionality, then was iterated until it became a more complete solution.
Case study
Problem: A third-party table component introduced a per-instance cost that no longer made sense for the use case.
Approach: Used AI-assisted development to build a dynamic ticket board with movable elements, status changes and overdue-state handling, then refined the implementation.
Result: A working replacement without depending on the paid component.
Distributed Product Data
Central product catalogue distributed dynamically to multiple systems, with receiving systems able to control which products and fields they consumed and managed.
Case study
Problem: Product data needed to stay consistent across multiple servers while different receivers had different requirements.
Approach: Built around a central catalogue and configurable distribution model, then adapted the transmission approach as data volume exposed infrastructure constraints.
Result: A more controlled distribution process that could evolve with the growing data set.
Technical toolkit
Practical experience matters more to me than collecting technologies. These are tools and areas I have worked with hands-on or used regularly in projects.
Experience
Current · ~1.5 years
Junior IT Consultant
Confidential / NDA
- API management and gateway work across Gravitee, Kong, Envoy, Broadcom Layer7 and Boomi.
- Hands-on AWS work including EC2, AMIs, Route 53, CloudWatch, IAM and S3.
- Infrastructure as Code with Terraform and GitLab pipelines.
- Customer and stakeholder-facing consulting around integrations, APIs and technical solutions.
- Working knowledge of Kubernetes for gateway and cloud deployments.
Previous · ~2 years
Junior Solution Engineer
ERP startup · Solar industry
- Worked across backend development, frontend work, integrations and customer success.
- Developed API and gateway solutions around a Ninox-based ERP platform.
- Built integrations and REST interfaces connecting ERP data with external systems.
- Worked directly with customers and internal teams to translate business requirements into technical solutions.
- Presented the product and technical capabilities internally and at customer-facing events.
How I work
My default loop is simple: understand enough to start, build something small, observe what breaks, then improve it. I call it being a gardener rather than an architect — you still need structure, but you learn what the system needs by working with it.
1. Clarify the real problem
Ask questions, separate symptoms from the underlying problem and make assumptions visible.
2. Build the smallest useful thing
Start locally or with a small environment and get a working version in front of people quickly.
3. Learn from reality
Use the prototype to discover missing requirements, technical constraints and better approaches.
4. Turn learning into a solution
Once the direction is clear, improve the implementation and make the result robust enough for real use.
Currently exploring
I deliberately keep experimenting with tools that can shorten the distance between an idea and a working implementation.
AI & agentic workflows
What I am trying to learn
Not just what an AI model can generate, but where agentic systems genuinely improve a business workflow — and where a simpler automation or conventional software solution is the better answer.
Let's build something useful.
Interested in AI, automation, integrations, cloud infrastructure or turning a messy process into something that works? Get in touch.