Product Engineer
Software should fit the work.
👋 I'm , a product engineer in . I build AI-native business software for teams whose core systems were supposed to make work easier, but left the real work running through spreadsheets, email and workarounds.
Part of that process is worth keeping. The rest only exists because people had to work around the software. Sorting out which is which comes first. Then I build something that carries the work instead of sitting next to it.
I do the product thinking, the design and the , usually starting from a problem nobody has written down properly yet.
Expertise
How I help
Build the product
You bring a problem, even a vague one. I work out what the product should be, design and build it, and get it to your users.
Prove the idea
Before you commit a big budget, I build a small first version and put it in front of real users. You see whether people use it and whether it's worth building further.
Remove the manual work
If your team copies data between systems, checks the same things again and again, or looks things up by hand, I build software to do those steps. AI handles the parts where plain code isn't enough.
Experience
- Founded
- build/ship Founder & Product EngineerNubeasoft Co-Founder
- Advised
- ROCKS & BIRDS MEDIA CTO & Advisory Board
- Worked
- Lufthansa Head of Solution ArchitecturePwC Senior IT Strategy ConsultantIBM IT Portfolio ManagerCredit Suisse IT Project Manager
Stack
- Product
- SvelteKit TypeScript Tauri
- Development
- Claude Codex Cursor
- Design
- Tailwind CSS shadcn-svelte Figma
- Data
- PostgreSQL Drizzle ORM Supabase MySQL
- Hosting
- Hetzner Cloudflare Vercel
- Other
- Better Auth Stripe Vercel AI SDK
Questions
Business processes that run on spreadsheets, email threads and old systems, where people spend half their day chasing each other for updates. I build software that handles that coordination for them.
Usually not. In most cases I build a smaller tool that sits on top of the systems you already have. Replacing everything is a big, risky project, and the problem rarely needs it.
Yes. If a process is bad, automating it only makes the bad parts run faster. We go through the steps together, keep the ones that give you an edge, and drop the rest before I build anything.
In the steps where someone reads, searches or writes by hand: pulling data out of documents, drafting replies, checking work, preparing a decision. If plain software does the job better, I use plain software.
In most cases, yes. I start from your APIs, your data and the enterprise tools you already run. A new product that can't talk to those isn't much use to you.
Directly, with both the business side and IT. I stay involved from the first conversation about the problem through design and build, so nothing gets lost between teams.
Early. I'd rather put one small, working workflow in front of real users than spend months writing a spec for the whole system. How they use it tells us what to build next.



