ArchitectureConference50min
Build or Buy an iPaaS? We Built It. Here's the Honest Story.
A candid case study of building an iPaaS from scratch while migrating 100 business processes in under a year. Covers pipeline-based architecture, pragmatic tool choices, event-driven autoscaling, and the tradeoffs between ideal vision and shipped reality, with lessons on build-vs-buy and deliberate technical debt.
talk.summaryAiDisclaimer
Michał FurdynaTesco Technology
talkDetail.whenAndWhere
Wednesday, June 17, 14:10-15:00
Room 4A
We had a deadline, a vision, and a stack we thought we understood. Only two survived contact with reality. So what does it actually take to build an integration platform from scratch—while the business keeps running?
This is the honest story of how a small team built an iPaaS, migrating ~100 business processes from a vendor platform in under a year while simultaneously designing and building the platform itself. We’ll cover the pipeline-based execution model we built, the architectural decisions behind it, and the tools we chose—not because they were exciting, but because they worked: Java, Spring, KEDA, JSLT, GitOps.
But this isn’t just an architecture talk. We’ll be candid about the gap between the vision—a no-code canvas, reusable building blocks, full self-service—and what we actually shipped. We’ll explore where the complexity really went, and what it means to take that debt on deliberately.
Key takeaways:
Target audience: Software engineers, architects, and engineering managers dealing with integration sprawl or considering internal platforms.
This is the honest story of how a small team built an iPaaS, migrating ~100 business processes from a vendor platform in under a year while simultaneously designing and building the platform itself. We’ll cover the pipeline-based execution model we built, the architectural decisions behind it, and the tools we chose—not because they were exciting, but because they worked: Java, Spring, KEDA, JSLT, GitOps.
But this isn’t just an architecture talk. We’ll be candid about the gap between the vision—a no-code canvas, reusable building blocks, full self-service—and what we actually shipped. We’ll explore where the complexity really went, and what it means to take that debt on deliberately.
Key takeaways:
- How to design a pipeline-based integration platform using familiar, “boring” tools
- How to make isolated deployments cost-effective with event-driven autoscaling
- Why “build vs buy” is often a false choice—and how to reason about it
- How to earn the right to build it right by shipping something real first
Target audience: Software engineers, architects, and engineering managers dealing with integration sprawl or considering internal platforms.
Michał Furdyna
Michał is a Software Development Manager at Tesco Technology with over 10 years of experience in software engineering and 6 years leading engineering teams. He is pragmatic by nature and technical by choice — the kind of manager who still reads the code, asks the questions that make engineers think twice, and believes that the best teams are the ones who surprise themselves with what they achieve.
Based in Kraków, he leads engineering teams building and operating integration infrastructure for one of the UK's largest retailers — serving 330,000 colleagues across payroll, HR, finance, and property domains.
When he is not shipping integrations, Michał teaches Cuban Salsa and gigs with a band playing Cuban music. He will tell you that the best social dances are never the ones with the most complicated steps — they are the ones where two people build a real connection, even on the basics. He has a feeling this applies to IT too.
Based in Kraków, he leads engineering teams building and operating integration infrastructure for one of the UK's largest retailers — serving 330,000 colleagues across payroll, HR, finance, and property domains.
When he is not shipping integrations, Michał teaches Cuban Salsa and gigs with a band playing Cuban music. He will tell you that the best social dances are never the ones with the most complicated steps — they are the ones where two people build a real connection, even on the basics. He has a feeling this applies to IT too.