Full-stack developer — React and Node.js
I build full-stack web applications, carrying the same work from the interface through the API to the database. Usually the kind of system that turns daily admin into a process that runs on its own — booking, ordering, internal records.
The fixed point in how I work is that a failure has to be loud. Tests, linting and build-time assertions catch what a review does not: on this site, for instance, the build stops if a Hungarian sentence slips onto the English version. Anything that breaks quietly is noticed by a visitor before it is noticed by me.
I am working towards TypeScript and a broader testing practice at the moment, which is why neither appears in the stack below: I do not write production code in them yet. I am open to developer roles and to contract work. If there is a technical detail you want that is not here, write to me; a specific question gets a specific answer.
Five areas, each with a position and the specifics behind it. What matters is not whether I know the names, but what I decide on when two solutions are both available.
The smallest structure that carries the job. I add an abstraction when the second caller appears — before that, an interface with one implementation is not an abstraction, it is an extra file.
One component per responsibility, shared behaviour in hooks. State lives where it is used, and anything derivable is not stored — the language, for instance, follows from the URL rather than from state.
REST endpoints organised by resource, with predictable status codes and error responses shaped like the successful ones — so the client does not need two ways of reading the same call.
Quality is not a phase at the end. Lint and tests after every change, and the build itself is a gate: if an assertion fails, nothing is written.
Deployment is not the end of the work; it is where the earlier decisions become visible. If it cannot be rolled back or measured, I do not treat it as finished.
Six areas a working system is made of — put the way a client would ask, not the way a CV would list them.
What your customer sees and uses. On a phone just as much as on a computer — because that is where most visitors arrive from.
In practice that means React 19, Vite and Tailwind, built out of components.
Visitors back out of a slow page before they have seen anything on it. So I measure speed rather than setting it by feel.
I work from Lighthouse and the network panel, not from guesswork. Image optimisation, code splitting and cutting out needless re-renders — the goal is for even the mobile load to stay under a second. The Kovacs Electrical demo page scores 99 / 100 / 100 / 100 in mobile Lighthouse (performance, accessibility, best practices, SEO).
What works behind the screen: the booking actually reserves, the order actually arrives, and only the people who should can see the data.
Node.js and Express, with REST endpoints and JWT-based sessions. Validation runs on the server as well, not only in the browser, and every error path has a clear response. In the booking demo the free slot is recomputed at the moment of saving, so two customers cannot get the same time, and the booking list sits behind a PIN.
Your customers, bookings and orders stored so that years from now anything in them can still be found.
I choose PostgreSQL or MongoDB depending on how fixed the shape of the data is. The schema is kept in migrations, so every change is traceable, and the indexes follow the queries that actually run.
The site keeps running when I am not sitting at a computer. And if an update does break something, it is back within minutes.
GitHub Actions runs the tests and the build, and deploys from there to Vercel or to a container. Every version can be rolled back, and environment variables never make it into the repository.
You are not left dependent on me. The work is documented, so if somebody else takes it over one day, they are not starting from nothing.
A separate branch per feature, small pull requests and commit messages that say something. The README explains how to get the project running, so a new developer is not dependent on me on their first day.
Split by what can be verified. Anything running in this repository can be opened and checked; the rest comes from delivered work. No percentage skill levels, because there is nothing behind them.
Runs in this repository
Runs in this repository
Used in delivered projects
Used in delivered projects
Runs in this repository
Runs in this repository
The most checkable work I have is the page you are reading. Eight decisions, each with the reason behind it and the file it can be checked in — because a decision without its reason is a feature list, and a reason without a file is a claim.
Sections stay transparent until an IntersectionObserver switches them on. Node has no IntersectionObserver, so every section renders fully visible — headless Chrome does have one, so a snapshot would capture everything below the fold as blank. It also keeps a Chromium download out of every deploy.
Source: scripts/prerender.mjs
With the language held in state the server renders Hungarian into the HTML and hydration then flips it — a visible flash for the reader, and the crawler indexes whatever the server guessed. As a pure function of the path there is nothing to synchronise, and each language gets a real URL that can be linked to.
Source: src/i18n/locales.js
The two legal pages stay Hungarian on purpose: translating a binding document does not produce a second version of it, it produces a second document. But an hreflang pointing at a 404 makes a search engine drop the whole language cluster — so the generator checks that the twin exists before writing the tag.
Source: scripts/prerender.mjs
Maintained by hand, they went stale: llms.txt was publishing a price the pricing module no longer contained. A hand-written side file always lags behind the one thing nobody opens at deploy time. Generated from a single source, there is nothing left to forget.
Source: scripts/generate-static.mjs
The JSON-LD carried eight FAQ answers copied in by hand, and they drifted: the visible page had the new price while the structured data still had the old one. That is precisely the text a search engine quotes, so the stale copy was the likelier one to be read. The block is now built from the source, leaving no second copy to forget.
Source: scripts/prerender.mjs
Every check reports by finding nothing, so a broken checker and a clean page look identical. The build therefore hunts specifically for the failures nobody would notice: a section left transparent, Hungarian text on the English page, structured data left empty, a page title kept in two places. One of the checks exists to verify the checker itself.
Source: scripts/prerender.mjs
The script-src allows only same-origin scripts, with no unsafe-inline — so there is nowhere to put a hydration data blob, and the prerender deliberately does not produce one. The constraint shaped the solution rather than being bolted on afterwards.
Source: vercel.json
A font CDN once answered with a 200 that contained a "temporarily restricted" comment instead of CSS — body text fell back to a system face, with no error anywhere. Local files remove that, and the latin-ext subset removes the other half: the accented Hungarian characters no longer switch to a different face mid-word.
Source: src/fonts.css
I do not publish links or repositories for client projects: they are live systems holding real customer data. For my own projects I build demos anyone can open, and I am glad to walk through code in a conversation. The first client build is under way — the moment it is live, the link and the screenshot will be here.
Demo project
Demo salon site: prices on a hair-colour swatch ring, stylists in round mirrors with their own next free time, and a comb for picking the time, one tooth per half hour. My own initiative, not client work.
Design, build, deploy
The problem
A small salon needs a simple booker that works on a phone, without coordinating in Excel or chat.
What I built
Service picker, free slots, booking form, confirmation screen and admin list. The demo uses localStorage; production would add Supabase + email.
Stack
Demo project
Demo daily menu for a buffet: today's menu on a felt letterboard, with an allergen filter. Takeaway can be ordered ahead, every order is a stamp on a loyalty card kept on the phone, and the week sits on tear-off calendar pages. My own initiative, not client work.
Design, build, deploy
The problem
A small eatery often posts the daily menu as a photo of a printout on Facebook: hard to find, hard to update.
What I built
Public today board, week overview, password editor. The demo saves to localStorage; production would use Supabase auth + a table.
Stack
Demo project
Demo site for an electrician: prices on a multimeter dial, a before and after slider, the process in wire colours, and a quote form where you flip circuit breakers. My own initiative, not client work.
Design, build, deploy
The problem
A tradesperson does not need a shop, just a page that loads instantly on a phone, says what they do and where, and can be called with one tap.
What I built
One page in plain HTML and CSS, no framework, with a short script for the form. Local business schema.org data. The demo form sends no email; production would put a form service behind it.
Stack
Demo project
Demo garage site: the workshop whiteboard with the lifts of the day and the next free drop-off, booking a slot by number plate, quote requests and a pre-inspection checklist. My own initiative, not client work.
Design, build, deploy
The problem
In a small garage the phone rings all day: when can I bring it, how much will it be. The mechanic answers from under a car, the slot goes into a notebook, the quote stays in his head.
What I built
Two ways in: people who know what they need book a slot; people who only know it "knocks" describe it and ask for a call back. Slot logic is shared with the salon demo, with tests. The demo uses localStorage; production would add a database and SMS reminders.
Stack
Demo project
Demo florist: ready bouquets on twine that load into the builder with one tap, where you put the bouquet together stem by stem from today's stock. A season calendar and a care card. My own initiative, not client work.
Design, build, deploy
The problem
A small florist site usually has a photo gallery and a phone number. Anyone who wants a bouquet calls and tries to describe it in words.
What I built
A bouquet builder from today's buckets: flowers go to the middle, greens to the edge, and stems glide to their new place. Wrapping, card, pickup day and time. The bouquet logic is a tested module.
Stack
Demo project
Demo massage studio: say how much time you have and where it hurts, and the site splits the session minute by minute, with the price and the free slots it fits into. A gift voucher in minutes with a live preview. My own initiative, not client work.
Design, build, deploy
The problem
People booking a massage rarely know whether they need Swedish or sports massage. They know where it hurts and how much time they have. Most salon sites still start with treatment names.
What I built
It splits the chosen time between the areas in 5-minute steps, gives every area a minimum, and says how long is needed when they do not fit. Then it shows free slots that fit the length and end before closing. Both are tested modules.
Stack
Demo project
Demo guesthouse: only the keys of rooms free on the chosen dates hang on the reception key rack, the price includes the tourist tax, and the direct price sits next to the portal price. My own initiative, not client work.
Design, build, deploy
The problem
A small guesthouse gets most guests through booking portals and pays about 15% commission on each. Its own site is usually a photo gallery with a phone number: no availability, no price, no reason to book direct.
What I built
Given the dates, guests and a dog, only the keys of suitable rooms hang; booked hooks say in chalk when they free up. The ticket prices line by line, with tourist tax for adults only. If nothing fits, one button jumps to the first free date. The request ends by showing what the guest gets and what the owner sees: zero commission. The pricing is a tested module.
Stack
Demo project
Demo cafe that turns into a wine bar at night: dragging the sun along its arc switches the whole page from day to evening, menu included. Tables for the evening events can be requested with live seat counts. My own initiative, not client work.
Design, build, deploy
The problem
A cafe that becomes a wine bar at night is really two places: people look for coffee in the morning and for wine and events in the evening. A typical site shows both at once, so neither lands, and evening tables get booked by phone, if at all.
What I built
The full-screen landing photo fades from day to evening with the chosen time; the dial is an arc the sun (the moon at night) travels along. The menu redraws only when the daypart changes. Events show the seats left, and a request ends on the bar view. Opening hours and events come from a tested module.
Stack
Demo project
Demo gift shop: the landing present wraps itself on load and pops open on a click with three picks from the shelf. The gift finder suggests from stock, the wrap and card show live, and the shop holds the gift. My own initiative, not client work.
Design, build, deploy
The problem
Someone buying a gift wants an idea, not a product. A small shop site usually shows photos and opening hours, so the shopper never learns whether there is something for their budget, and orders online instead.
What I built
Three questions (who for, what for, how much) suggest from real stock and flag what sold out. The chosen gift is drawn as a CSS present that changes live with the paper and the card text, and a short code holds it until the next closing. Suggestions and holds are a tested module.
Stack
Demo project
Demo phone and computer repair shop: the landing shows a phone taken apart, and every layer is a fault. Tapping the broken part shows the price and the ready date right there; repairs can be tracked by job number, and there is a print calculator. My own initiative, not client work.
Design, build, deploy
The problem
The first two questions anyone calls a repair shop with are always the same: how much and by when. Most shop sites do not answer them, so the phone rings all day, and whoever cannot get through calls the next shop.
What I built
A CSS 3D phone pulls apart: the screen, the frame with the charging port, the board, the battery and the back are one fault each. The chosen layer slides out like a drawer, with the price range and ready date beside it. The full estimate also covers device and brand, printed as a thermal receipt. Estimates, job tracking and printing are a tested module.
Stack
Demo project
Demo bike service: tap the broken part on the bike drawing and the work order builds itself with price and time. The drawing spins with the scroll and zooms to the chosen part, and drop-off only offers days the job fits into. My own initiative, not client work.
Design, build, deploy
The problem
Most people bringing a bike in do not know what the broken part is called or how long it takes. The shop guesses over the phone, and jobs pile up in the workshop.
What I built
Five points on the drawing (wheel, brake, chain, gears, bars), each offering its own jobs; the chosen ones make a work order with price and mechanic time, and a package absorbs the adjustments it includes. Drop-off days show free mechanic time and only the ones the job fits into can be picked. The pricing is a tested module.
Stack
Demo project
Demo opticians: the landing is a blurred eye chart that turns sharp under a draggable loupe. It explains the prescription numbers in plain language, recommends a lens with a price, and suggests frames for a face shape. My own initiative, not client work.
Design, build, deploy
The problem
To most people a prescription is a meaningless row of numbers, with no idea what the lenses will cost. Optician sites rarely help, so the price is first heard at the counter.
What I built
The chart has two layers: a blurred one and a sharp copy the loupe cuts a circle out of; it moves by mouse, finger or arrow keys. The prescription form takes quarter steps and explains each line; from the power it recommends a lens index and a pair price. The explanation and the recommendation are a tested module.
Stack
Demo project
Demo vet clinic: the landing has a growth ruler where the puppy moves and grows with age and the vaccinations fill in as paws. The full schedule is built from the birth date, and an SMS reminder can be requested. My own initiative, not client work.
Design, build, deploy
The problem
Most owners do not know offhand when the next shot is due, and the mandatory rabies shot easily slips. The clinic reminds them by phone, if at all.
What I built
The ruler uses a square-root scale so the busy first months stay readable; the photo, the slider and the paws share that scale. Dogs and cats get their own plans. The schedule marks past shots as missed until ticked and shows the next one for yearly repeats. The plan and the reminder date are a tested module.
Stack
Demo project
Demo law office: the landing is a case file with a tab per case type. A tab brings that file forward with the expected fee and duration, followed by a printable bring-along checklist and consultation booking. My own initiative, not client work.
Design, build, deploy
The problem
Most people go to a lawyer without knowing the cost or how long it takes, and half the papers are missing at the first meeting. Most office sites only list practice areas.
What I built
Six case types, each with its own file: what we do, how long it takes, what it costs (property: 0.8% of the price, at least 80,000 HUF). Tabs also switch with arrow keys, and the choice carries into the details and the checklist, which can be ticked and printed. The fee logic is a tested module.
Stack
Demo project
Demo tattoo studio: the flash designs draw themselves as stencils, each is tattooed only once, and taken ones are struck through. The estimator gives a price and time range, the number of sessions and a pain level from placement, size and style. My own initiative, not client work.
Design, build, deploy
The problem
Anyone wanting a tattoo messages the studio the same questions: how much, how many sessions, how painful. Answers take days, and meanwhile the client asks elsewhere.
What I built
The designs are SVG line art that draws itself as a stencil when the sheet comes into view and redraws in red ink on hover; each can be claimed once, never under 18. The estimator works from body part, size and style, split into sessions of at most 4 hours. The estimate is a tested module.
Stack
Three kinds of enquiry reach me, and all three land in the same place. You do not have to decide in advance which one you are — just say what the situation is.