From Open Source to Product
When I joined Kreuzberg, it had already earned the trust of the developer community. The open-source document processing framework had grown to more than 2,500 GitHub stars, proving there was real demand for a simpler way to build document pipelines for AI applications.
The technology solved a difficult engineering problem.
The product didn’t exist yet.
There was no commercial platform, no onboarding experience, no product positioning, and no clear path for developers to move from experimenting with the framework to running document processing reliably in production.
As Co-founder, Product Lead, and Product Designer, I partnered closely with engineering to define and design Kreuzberg Cloud-the commercial product built around the open-source framework. My work spanned product strategy, developer experience, UX, visual design, positioning, and go-to-market.
Over the following six months, Kreuzberg evolved from an open-source project into a commercial platform. During that time, the GitHub community grew from 2,500 to more than 8,500 stars, and the platform reached around 40 daily active users shortly after launch.
Project Overview
Role Co-founder · Product Lead · Product Designer Duration 6 months Team Founder + Engineering + Product Product Kreuzberg Cloud Platform Web application + Marketing website Audience AI developers and engineering teams building production AI systems Focus Product Strategy · Developer Experience · UX/UI · Go-to-Market
| Role | Co-founder · Product Lead · Product Designer |
| Duration | 6 months |
| Team | Founder + Engineering + Product |
| Product | Kreuzberg Cloud |
| Platform | Web application + Marketing website |
| Audience | AI developers and engineering teams building production AI systems |
| Focus | Product Strategy · Developer Experience · UX/UI · Go-to-Market |
The Challenge
The open-source project had already proven that developers wanted the technology.
What hadn’t been proven was whether it could become a business.
Open-source adoption and commercial adoption are different problems.
Developers could already integrate Kreuzberg into their projects, but organizations needed much more before they could confidently use it in production. They needed infrastructure, authentication, project management, monitoring, documentation, and an experience that reduced operational complexity.
The challenge wasn’t redesigning existing software.
It was defining the product itself.
The central question became:
How do you transform an open-source framework into a commercial platform without losing what made developers trust it in the first place?
That question guided every product decision we made.
Product Strategy
Designing for adoption, not conversion
When I joined Kreuzberg, the technology already had something many startups struggle to achieve: an active open-source community. Developers trusted the framework because it solved a real problem, was transparent, and could be self-hosted.
The goal wasn’t to replace the open-source project with a commercial offering. It was to create a natural next step for teams whose needs had outgrown the library itself.
That thinking shaped every product decision we made.
Instead of building an enterprise-focused sales experience, we adopted a developer-first go-to-market strategy. Developers could discover Kreuzberg through GitHub, understand its capabilities, start using the open-source framework immediately, and transition to Kreuzberg Cloud when they needed a managed production environment.
Rather than treating the website as a marketing asset, we designed it as part of the product experience. Every page focused on helping developers quickly understand what Kreuzberg solved, how it fit into their workflows, and how they could get started with minimal friction.
This approach created a seamless journey:
Discover → Try → Build → Scale
Instead of asking users to talk to sales before experiencing the product, we prioritized self-service adoption. The product itself became the primary driver of growth.
Designing trust for developers
Developer tools are evaluated differently from consumer products.
Developers don’t just ask whether a product is easy to use—they ask whether they can trust it in production.
That meant our design decisions focused on reducing uncertainty rather than adding visual polish.
We emphasized clarity over marketing language, surfaced technical capabilities instead of hiding them, and designed workflows that made the platform feel predictable and transparent. Every interaction—from the landing page to the cloud dashboard—was intended to help developers understand what the system was doing and why.
The goal wasn’t simply to create an attractive interface. It was to build confidence that Kreuzberg could become part of a production AI stack.
Decision 1 – Designing the Landing Page
The landing page wasn’t designed as a marketing website.
It was designed as the beginning of the product experience.
Developer audiences evaluate products differently from traditional enterprise buyers. Instead of persuasive marketing copy, they look for technical clarity, documentation, examples, and evidence that a product fits naturally into their workflow.
The website therefore focused on explaining:
- What problem Kreuzberg solves
- how it fits into AI document pipelines
- Why developers should trust it
- how to start immediately
Every section was designed to reduce friction rather than maximize conversions.
The website became the first step in the product journey.
Discover → Understand → Build → Scale
Decision 2 – Turning Infrastructure into a Product
The open-source framework has already solved document processing exceptionally well.
The challenge was making it usable as a commercial platform.
Rather than exposing every technical capability, we focused on the workflows developers actually needed to manage in production.
The dashboard was designed around those workflows, allowing users to:
- create and manage projects
- configure processing
- monitor activity
- access credentials
- understand system status
Instead of adding complexity, the platform organized powerful infrastructure into a predictable experience.
The goal wasn’t to simplify the technology.
It was to simplify how developers interacted with it.
Decision 3 – Designing for Trust
Developer tools are judged differently from consumer products.
Developers don’t simply ask whether a product is intuitive.
They ask whether they can trust it with production systems.
This changed the way I approached the entire experience.
Throughout the platform, we prioritized transparency over abstraction.
Interfaces clearly communicated what the system was doing, how workflows were structured, and what users could expect at every step.
Rather than hiding technical concepts behind simplified UI, we surfaced them in ways that felt understandable and predictable.
Design wasn’t about making the platform feel magical.
It was about making it feel reliable.
Building a Cohesive Product Experience
Although users experienced Kreuzberg through multiple surfaces, I approached them as one connected product.
The marketing website introduced the value proposition.
The onboarding experience helped developers get started.
The dashboard supported day-to-day workflows.
Together, these touchpoints created a continuous experience that helped developers move naturally from discovering the framework to adopting the commercial platform.
Thinking across the entire journey-not just individual screens-was essential to creating a coherent product.
Working Across Product, Design, and Engineering
As a founding team member, my role extended well beyond interface design.
Working closely with engineering, I helped shape how the commercial product should work, how developers would interact with it, and how the overall experience aligned with our go-to-market strategy.
Product decisions, technical constraints, and user experience evolved together. Rather than treating design as a handoff, we worked collaboratively, iterating quickly as we learned from early users and refined the platform.
This environment required balancing product thinking, technical understanding, and business priorities throughout the entire development process.
Outcomes
In six months, Kreuzberg evolved from a successful open-source framework into a commercial product.
The project achieved several meaningful milestones:
- GitHub adoption grew from 2,500 to 8,500+ stars.
- Kreuzberg Cloud launched as a commercial platform.
- The platform reached around 40 daily active users shortly after launch.
- A complete end-to-end developer experience was established, spanning discovery, onboarding, and production workflows.
While the numbers reflected growing adoption, the more significant achievement was demonstrating that an open-source technology could become a product with a clear commercial direction.
Reflections
Kreuzberg fundamentally changed how I think about product design.
The most important challenges weren’t visual—they were strategic.
Turning infrastructure into a product required understanding developer behavior, aligning business goals with technical realities, and reducing complexity without hiding capability.
It reinforced my belief that product designers create value not by designing individual interfaces, but by connecting technology, business strategy, and user needs into a coherent product experience.
That perspective continues to shape how I approach every product I build today.
Building a Cohesive Product Experience
Although users experienced Kreuzberg through multiple surfaces, I approached them as one connected product.
The marketing website introduced the value proposition.
The onboarding experience helped developers get started.
The dashboard supported day-to-day workflows.
Together, these touchpoints created a continuous experience that helped developers move naturally from discovering the framework to adopting the commercial platform.
Thinking across the entire journey-not just individual screens-was essential to creating a coherent product.
Additional Contributions
Beyond leading product strategy and designing the commercial platform, I also contributed to strengthening Kreuzberg’s product development process and design culture.
Data-Informed Product Decisions
Throughout the project, I used Mixpanel to analyze user behavior and product adoption. Product decisions were informed by usage data rather than assumptions, helping us better understand how developers interacted with the platform, identify friction points, and prioritize improvements based on real user behavior.
Mentoring Future Designers
As part of our collaboration with IconHochschule (IconHochschule students), I mentored a team of design students during their final project. I guided them through the product design process, helping them understand the problem space, define their approach, and present their work.
The collaboration resulted in design explorations for the Sandbox and onboarding experience, providing fresh perspectives while giving students hands-on experience working on a real AI product.