—About
From Java plugins
to complete products.
My name is Bartosz Szymański. I study computer science and I design and build websites, web applications and custom systems. Below — where I come from and why I work the way I do.
Story
I do not just want to write a feature. I want to know why it exists and how it should work as part of the whole — from screen to server.
01Design × development
Design and code
moving as one.
Most problems in web projects appear at the seam: the mock-up does not anticipate states, and the code loses the design intent. I work on both sides of that line, so decisions are not lost in a hand-off between people.
The lens beside this text shows it literally: beneath every interface surface there is structure — components, logic and data. I design the view knowing how it will be built, and build it so it keeps the design’s quality: on phones, in form errors and with longer content.
One product, seven layers.
Scroll to take the application apart. I can design and build each of these layers — or join where your team needs support.
- 01
Structure
Site map, content priorities and user journeys. Before the first screen exists, it is clear what matters most and where each view should lead.
structure map - 02
Interface
Layout, hierarchy and typography. I design views so people immediately know where they are and what to do next — on a phone as well as on a monitor.
screen design - 03
Components
Buttons, fields, cards and tables as one system. Consistency comes from rules written into the code, not from copying screens by hand.
component library - 04
Interactions
Loading, errors, empty states and motion. What happens between clicks decides whether a product feels solid.
states and behaviour - 05
Logic
Rules, statuses, permissions and server-side validation. The back end does exactly what the process requires — without workarounds.
business rules - 06
Data
A SQL data model and integrations with email, calendars or external APIs. Information goes where it is needed and nobody has to retype it.
database and integrations - 07
Infrastructure
Server, domain, SSL certificate and release. The product has to keep working at its final address, also when a campaign brings more traffic than usual.
server and release
04From wireframe to product
Decisions you only see
in the finished whole.
A good interface is not born in full colour. As you scroll, one screen passes through successive design decisions — and you will see why each of them matters.
01Structure
First we agree what is on the screen and in what order.
A wireframe has no colour or decoration — on purpose. We discuss whether people instantly find the next booking and know how to add a new one. A change at this stage costs minutes; in code it costs days.
02Spacing and rhythm
Space groups information before anyone reads a word.
The same elements with considered spacing form readable blocks: header, summary, list. A tight layout fits more but tires; a loose one needs scrolling. I look for the measure that fits how often someone uses the screen.
03Hierarchy
One primary action. Everything else is quiet.
When every button looks the same, they all compete for attention. Emphasising “New booking” and quietening the secondary actions means nobody has to wonder what to do next.
04Finished interface
Typography, contrast and states — on phones and desktops.
Only now does the full visual layer arrive. The structure stays the same, which is why earlier decisions save rework in code. The same component system later supports light and dark themes without rewriting views.
05Components
Details that
add up to a whole.
Frontend is a system of repeatable parts. When each one is refined, new views are built faster and look consistent.
- States, not just looks
- Every button and field has rest, hover, press, loading, error and success. I design them together rather than adding them afterwards.
- Validation that helps
- The message says what to fix — “the domain is missing, e.g. @company.com” — instead of just “invalid address”. A form does not shout before you finish typing.
- Accessibility from the start
- Visible focus, keyboard and screen-reader support, contrast checked in both themes. It is part of quality, not an extra.
02How it shapes projects
Four habits
I bring to the work.
- 01
Process first, screens second
Before I draw the first view, I want to understand how the work happens today: who does what, where information gets lost and what frustrates people most. The interface should organise that process, not decorate the mess.
- 02
Systems thinking
Minecraft plugins taught me that every feature affects others: game state, permissions, player data. Web applications are the same — so from the start I ask what happens when data is incomplete, a user makes a mistake or an external service does not respond.
- 03
Design with the build in mind
Because I write the code myself, I do not design things that cannot sensibly be built. Every component has states, responsive rules and a place in the system — which shortens the path from design to a working version.
- 04
Verified in the browser
A design is finished only when it works on a real phone, with real content and on a slower connection. I test forms, errors and keyboard use, not just the happy path.
03Tools
Technologies
I use every day.
I pick tools for the problem, not the other way round. Where lean code is enough, I do not add a framework.
- HTML / CSS
- Semantic structure, responsive layouts, interface motion.
- JavaScript
- Interactions, forms, browser-side logic — including the labs on this site.
- PHP
- Application logic, panels and CRM (NaprawProjektor), this website.
- SQL
- Data models, relations and queries in systems with a back end.
- Java
- Where it began: Minecraft server plugins.
- Linux / Git
- VPS deployment, server configuration, version history.
04Beyond code
Why
space?
Astronomy is a personal interest, hence the motifs on this site: the black hole, the gravitational lens, the waves. It is also a good metaphor for product work — structure has to be pulled out of a chaos of requirements and ideas, and everything in a good interface should naturally pull towards what matters most.
→Next step
Have a project that
needs structure?
Write a few sentences about the goal and the current situation. I reply personally — usually with questions that help define a sensible first release.
Have an idea, a website to rebuild or a process that needs its own tool? I don’t need a finished specification — a few sentences about what you want to achieve are enough.
- 01
You write. One short form — a few sentences are enough.
- 02
I reply personally. Usually with questions that help clarify the scope.
- 03
We agree a direction. A short call, then a scope proposal and estimate.