About
Who builds the sites and how
I am a web developer building landing pages and small services in Go. Almost every project on this site is a learning/demo project: the brands are fictional, the data is demo data, and the code is private and shared on request. The exception is one delivered client site (the client is not named).
There are no testimonials or order numbers here. I only show what can be checked: working code, tests and READMEs that list the limitations.
Principles
- 01
Simple and verifiable
Go standard library, a readable package layout, and tests for what really matters: concurrent job claiming, double booking, the WebSocket protocol.
- 02
Honest limitations
Every README has a Limitations section: one token instead of roles, a single process, at-least-once instead of exactly-once. Better to say it upfront than explain later.
- 03
Accessible by default
WCAG AA contrast, visible focus, keyboard support, respect for prefers-reduced-motion, mobile-first layout.
- 04
No secrets in code
Settings come from environment variables; tokens are generated at startup when not provided.
- 05
One binary
The front end is embedded in the Go service via embed, so running it needs no extra installs; SQLite uses a driver without CGO.
How we will work
- 01
Talk
We clarify the task, the audience and the constraints. If you do not need a site, I will say so right away.
- 02
Agreement
Scope, timing and what counts as done. In writing, no surprises.
- 03
Build
Short iterations: every intermediate result can be opened and tried.
- 04
Check
Tests, mobile screens, accessibility, load on the form and the API.
- 05
Launch
A Docker image or static files, run instructions, code handover.
Honest about the limits
- Almost all projects are learning/demo projects; one site is a delivered client site and the client is not named. Testimonials and order figures are not claimed here.
- The race detector (go test -race) is not run on my working machine because there is no C compiler; it runs in CI.
- My own WebSocket layer has not been run against the Autobahn Test Suite: correctness is covered by my own tests. For production, a proven library is the better choice.
- Demo data in the projects (monitoring history, links, jobs) is generated and marked as demo in the interfaces.
- Contacts: email only. Phone and social networks are intentionally not listed.