GitHub
LinkedInIt started in Hungary
Small client work, Wordpress websites, creative projects, and a lot of learning by doing. It was the beginning of figuring out that building software is also about trust, ownership, and making something useful for real people.
About me
Hey, I'm David!
I've spent the last decade building for the web, working across startups, agencies, and product teams, learning that good software is part skill, part patience, and occasionally part staring at one bug for longer than I'd like to admit.
Available for projectsCoffee-driven
Former dancer
Remote ready
Stack flexible
01 — The journey
From client work to product engineering
I've been working in front-end development for over a decade. I started in Hungary, continued my career in the Netherlands, and worked across agencies, startups, and product teams along the way.
That mix taught me a lot about how software gets made in different environments. Sometimes the job is to move fast and get an idea into people's hands. Other times it's about making sure a growing product stays stable, maintainable, and pleasant to work on - which is usually where the real fun begins. Depending on your definition of fun.
Over the years, I've worked on content-heavy websites, service platforms, mobile apps, dashboards, scheduling tools, account systems, payment flows, and real-time product experiences.
That variety shaped the way I work today: practical, detail-oriented, and always aware that a product needs to make sense for the people using it, and for the team building it.
Drag, swipe, or use the arrow keys to explore the journey.
1 of 9
1 of 9: 2010 - It started in Hungary
02 — Philosophy
How I like to build
I like starting projects by understanding what we are really trying to build, and why it matters.
Before thinking too much about components, libraries, or technical setup, I try to define the purpose of the product, the main goals, and what the first meaningful version should achieve. This does not mean planning every feature upfront. It means agreeing on the shape of the MVP, the important constraints, and a clear Definition of Done, so the team knows what ready to ship actually means.
Define it now
vs
Define it when we use it
You avoid both chaos and premature abstraction.
Structure early
vs
Keep it light early
Architecture has timing, and too much structure too soon can slow the product down.
Test first
vs
Test where risk lives
I value TDD, but use it pragmatically around behavior that matters.
Reusable component
vs
Feature-owned component
Not every UI element needs to become part of a shared system immediately.
Global state
vs
Local state first
Mature React work often starts by keeping state as close as possible.
Storybook early
vs
Storybook when reuse appears
Component documentation is useful structure, not automatic overhead.
Figma prototype
vs
Code prototype
Different product questions need different ways of validation.
Feature flag
vs
Simple release
Release strategy should match the risk and reach of the feature.
Optimize now
vs
Measure first
Performance matters most when it is guided by a real signal.
Micro-frontend
vs
Modular monolith
I prefer simpler boundaries until scale proves they are not enough.
Perfect consistency
vs
Useful flexibility
Good systems balance discipline with real product needs.
Click, tap, or press Enter to move through the stack.
1 of 11: Define it now versus Define it when we use it
03 — Technical focus
The stack I reach for
Most of my work sits around React, TypeScript, and modern front-end development. That’s where I feel strongest: building interfaces that are understandable, easy to extend, and solid enough to support real product growth over time.
Depending on the project, I’ve also worked with Next.js, React Native, Node.js, NestJS, PostgreSQL, GraphQL, and the usual supporting tools around product development. When a product starts to need more consistency, I also like adding Storybook to document reusable components, test states, and keep the UI easier to maintain.
My main focus is still front-end, but I’m comfortable stepping into backend work when a feature needs it. Understanding the full path from data to interface usually leads to better decisions on the front end too.
ReactTypeScriptNext.jsJavaScriptNode.jsNestJSPostgreSQLTailwind CSSGraphQLDockerSocket.ioViteSlackClaude
React & TypeScript
Product UI, architecture, and safer front-end code
Next.js
App structure and SSR
Node & PostgreSQL
Backend support and complex relational data
Explore my tech stack
See everything on StackShare
04 — AI the way I use it
AI armed with context
AI is an important part of how I work, mostly through Claude and Codex models. They help me move faster, but I do not see them as a replacement for thinking, structure, or code review.
At the beginning of a project, I like clarifying the basic development rules early: formatting with Prettier, linting with ESLint, naming rules, folder structure, component patterns, testing expectations, and boundaries around what it can and cannot change. To make AI genuinely useful in that environment, I give it project-level context through AGENTS.md or CLAUDE.md documents.
Those files act as a shared instruction layer. They describe the purpose of the project, the coding style, the boundaries, the workflows, and the expectations the AI should follow. The goal is simple: make the AI adapt to the codebase, not the codebase to the AI.
AI works well when it gets not only a task, but also understands the project environment. That still does not mean I let go of the wheel. The decision is mine: prompt precisely, check the answer, and decide what can go into the code.
01
Context first
Before I expect results, I give AI the detailed project description, rules, structure, conventions, and boundaries.
02
Small tasks
I mainly use AI for repetitive or well-scoped tasks that are already safe enough to delegate.
03
Mapping
It helps compare approaches, find alternatives, understand trade-offs, and navigate existing code faster.
04
Implementation
It can be useful for first solutions, refactors, tests, boilerplate code, and technical cleanup.
05
Review
It helps check assumptions, find edge cases, question the solution, and notice possible technical debt.
06
Documentation
It helps turn decisions, rules, component behavior, and project context into documentation that is easier to maintain later, or easier for new teammates to understand after the team grows.
05 — Today
The direction
These days, I’m most interested in the space between product thinking and front-end architecture: how a feature is planned, how the codebase supports it, how the interface feels, and how the team keeps it maintainable after release.
I still enjoy writing React and TypeScript every day, but the part I care about more and more is the thinking around the code. Clear boundaries, useful conventions, good feedback loops, practical AI workflows, and enough structure to help a product grow without making the team fight the system later.
This portfolio is a small snapshot of that: the kind of work I’ve done, the way I approach problems, and the kind of products I enjoy helping forward.
Product clarity
Understanding what we are really trying to solve before jumping into implementation.
Front-end structure
Keeping React and TypeScript codebases understandable as they grow.
Practical AI
Using tools like Claude and Codex with context, boundaries, and review.
Long-term quality
Thinking beyond the first release: testing, monitoring, documentation, and maintainability.
06 — Contact
Let's build something that lasts.
Have an idea, a product that needs fresh energy, or just want to exchange thoughts about React and architecture? My inbox is open. No bots. No auto-replies. Just a real conversation.
Start the conversation