Frontend architecture
Module boundaries, rendering strategy, state and performance budgets — written down as decisions your team can build to.
Detail A1Scale 1:1
Good software is drawnbefore it’s built.
Phöenix Group is the contracting practice of László Simon, a frontend and design-system architect. Every engagement starts on paper: the layers, the contracts between them and the budgets they have to hold — so the product can grow without a rewrite.
NoteBooking new engagements from [month year].
UX note 1 This button sits in the header, here and at the end, with the same words every time, so it is never more than a screen away.
What I plan and build
3 detailsUX and information architecture
Research, user flows and structure: who needs what, in which order, in the fewest steps. Settled on paper, before anything is drawn.
Detail A2 · see Fig. 02Scale 1:1
Design systems
Tokens, web components and the docs around them: one library that serves every framework you run, accessible by default.
Then — design
Then it’s designedto be used.
I design in Figma with the same rules I code by: tokens instead of hex values, every state of every component drawn, and accessibility checked on the canvas — not after launch.
Client · on Fig. 02
Looks right. Will the button stay reachable on a phone?
You · now
Yes — pinned to the bottom, 48 px tall, and it never covers the text you’re reading.
UI design
Layouts, type and colour systems, and component libraries drawn to be reused, not redrawn.
Detail S11:1Interaction details
Hover, focus, empty and error states; sensible defaults, undo, keyboard paths — the details people feel.
Accessibility
WCAG 2.2 AA from the first frame: contrast, focus order, target sizes and reduced motion.
Design-to-code handoff
Figma variables mapped one-to-one to design tokens, so the design and the code never drift.
How the work runs
Small steps, in order, each one finished before the next depends on it. When the job needs it, I take it end to end — API, data and deployment included.
primarysecondarydefaultRequest availabilitySee the componentshoverRequest availabilitySee the componentsfocusRequest availabilitySee the componentsdisabledRequest availabilitySee the components
- DiscoveryGoals, users, constraints — and what “done” means.
- ArchitectureThe structure, written down as decisions before any code.
- Design and tokensEvery state drawn; design decisions stored as data.
Network
- 4components.jsWeb components, tested in real browsers
- 5integration.tsWired into your framework and your CI
- 6auditAccessibility, performance, visual diffs
- 7handover.mdDocs and Storybook — your team owns it
7 steps0 blockingfinished when your team owns it
Then it’s built, and tested.
Tested in real browsers, written down as decisions, measured against budgets. The toolbox, and the habits that come with it.
Styles
body.engineer {engineer.css:1
- --languages
- TypeScript, HTML, CSS
- --components
- Lit, custom elements
- --frameworks
- Angular
- --testing
- Vitest, Playwright
- --docs
- Storybook, decision records
- --backend
- Node, Hono, PostgreSQL
- --ships
- Docker, CI
}
Console
engineer.principles()
Accessibility is a requirement, not a ticket.engineer.js:3
Every component ships with tests and docs.engineer.js:4
Decisions are written down before they are coded.engineer.js:5
Rewrite requested — proposing a refactor plan instead.plan.js:9
ux.check(page)
Focus order follows reading order; every control has a name and a 24 px+ target. UX note 4ux.js:1
Principles that ship with every component
Small, reversible steps
Every change is small enough to review and safe to roll back.
Gates on every commit
Lint, types, unit and real-browser tests run before anything merges.
Decisions on record
Decision records say why, so the next developer doesn’t have to guess.
TESTING · CI/CD
❯ phoenix test --explain
how a change is checked, fastest first — the same layers on every project
▾ static lint · types · format pre-commit
catches ✘ a typo in a prop, an unused import
▾ unit vitest · logic, tokens, utilities every PR
catches ✘ an off-by-one in a date range
▾ component real browsers: Chromium · Firefox · WebKit every PR
catches ✘ a focus trap that never lets go
▾ visual VRT: every story × 3 widths × light/dark every PR
catches ✘ a 2 px shift in dark mode, a lost focus ring
▾ accessibility axe on every story · contrast gate · keys every PR
catches ✘ a button with no name, 3.9 : 1 body text
▾ end-to-end playwright · the journeys that matter every PR
catches ✘ a form that submits twice
▾ contract API schema checked against the types every PR
catches ✘ a field renamed on the backend
▾ smoke after deploy · health, key pages, vitals production
catches ✘ a missing env var, a 500 on one route
✔ 8 layers a red check blocks the merge · flaky tests get fixed
❯ phoenix availability
[month year] — request a slot below ↓
❯
WHERE IT RUNS
- pre-commit
- static
- every PR
- unit · component · visual · a11y · e2e · contract
- nightly
- full browser matrix · dependency audit
- after deploy
- smoke · vitals, then a human says done
RULES
- A bug fix ships with the test that would have caught it.
- Visual changes need an approved baseline.
- Flaky tests are quarantined and fixed, never retried until green.
- Coverage is a floor, not a target.
- Every gate also runs on your machine.
And then — it ships
Let’s build somethingthat lasts.
You scrolled through four layers and three tears, and the page still works. That is the job: frontends that keep working through new frameworks, new teams and new brands.
- 04 Ship — The product. You are here.
- 03 Build — Inspector — measured, tested.
- 02 Design — Canvas — every state drawn.
- 01 Plan — Blueprint — the structure first.
Teams I’ve worked with
- [Client]
- [Client]
- [Client]
- [Client]
- [Client]
- [Client]
Contact
Have something that needs to last?
Tell me what you’re building and when you need it. I reply within [two working days] with availability and a first plan.
Booking from [month year]
- laszlo.simon@phoenixgroup.hu
- CV
- Read online · Download PDF
- Phone
- +36 30 217 3377
- Based in
- Uden-Veghel area, Netherlands
- Languages
- English · Hungarian · German (basic)
“[One or two sentences from a client: what changed, and what is still standing a year later.]”