Kollod — Endless Progress
Kollod.dev is the portfolio and experimental workshop of Anson, also known as Anson10124, a full-stack developer based in England, United Kingdom. This site documents ongoing ideas, interactive web experiments, and current projects. The work is intentionally iterative: a project can be useful and well-crafted while it continues to evolve.
Current Focus (Now — Week 36)
“Improving Jellyfish accessibility and navigation while adding TTML support and cleaning up LyricsDB codebase.”
Active Development This Week:
Total weekly velocity: 24 commits across 2 public repositories (+21 in private repos).
What Kollod does
Kollod is a good fit when a product needs both a high-quality frontend and solid backend engineering. The focus is not merely on making a page look finished. It is on making an interface clear, responsive, maintainable, and pleasant to use while ensuring the systems behind it have sensible contracts, predictable failure modes, and performance appropriate to the product.
Frontend work includes responsive user interfaces, reusable components, interaction design, design-system refinement, and animation or motion that improves comprehension and feedback. Strong frontend implementation pays attention to hierarchy, alignment, touch and keyboard use, loading states, breakpoints, and the small details that let an interface feel deliberate rather than assembled.
Backend work includes type-safe application services, API design, validation, error handling, database-query performance, caching, and service boundaries. A dependable backend makes its behavior understandable to callers, fails in actionable ways, and remains maintainable as a project acquires new requirements. The goal is speed and scale without sacrificing the clarity needed to change a system safely.
How to work with Kollod
Start with the outcome you need rather than a vague technology request. Explain who will use the product, what they need to accomplish, the platform or stack already in place, and any non-negotiable constraints such as accessibility, deadlines, privacy, deployment target, or performance budgets. A concise description of the problem makes it easier to identify the right scope and implementation path.
For a design or frontend task, share the source design, an existing interface, a component library, brand constraints, and examples of interactions that should feel similar. State whether the request is a prototype, a production feature, a redesign, or a refinement pass. If responsive behavior matters, identify the breakpoints and devices that are important to the product rather than assuming a desktop layout will translate automatically.
For an engineering or integration task, share repository links, API documentation, data models, expected request and response shapes, and a reproducible example if something is broken. Explain the acceptance criteria: for example, whether the priority is latency, correctness, resilience, observability, development speed, or a balance of those concerns. Clear acceptance criteria help avoid solutions that are technically impressive but wrong for the actual constraint.
Useful context also includes what has already been tried, which decisions are fixed, and where there is room to propose alternatives. Existing code and production constraints deserve respect. The strongest collaboration happens when implementation details are connected to real user outcomes and when risks such as migrations, compatibility, content ownership, or third-party service limits are surfaced early.
Frontend development approach
A frontend should make the next useful action obvious. That requires a clear information hierarchy, readable content, predictable controls, and feedback for state changes. Responsive design is more than scaling a desktop layout down: it considers the available space, input method, reading order, and whether an interaction still makes sense when a user is on a smaller screen or a slower connection.
Motion is useful when it communicates structure, continuity, or cause and effect. It should not obscure content, delay an action, or become a requirement for understanding a page. Kollod experiments with physics-driven animation and fluid transitions, but the enduring product value remains the semantic structure, usable controls, and meaningful content available in the initial response.
Component work benefits from explicit states and constraints. A button, form field, card, or navigation element should account for its normal, hover, focus, disabled, loading, empty, and error states where relevant. That discipline reduces one-off styling, makes later changes safer, and gives users a more coherent experience across a product.
Backend engineering approach
Backend systems are designed around clear boundaries. APIs should state what they accept, what they return, and how they report errors. Validation, authorization, idempotency where appropriate, and observability are not optional polish; they make a service safer to operate and easier for other developers to integrate. Types can make contracts more explicit, but they need to be paired with runtime validation at trust boundaries.
Performance work starts with evidence. Query shapes, cache behavior, payload size, and the paths a user actually takes are more useful than premature micro-optimisation. A fast system avoids unnecessary work, returns only what a caller needs, and uses caching deliberately with clear invalidation assumptions. Error handling should preserve enough context for diagnosis without exposing sensitive internal details to users.
Reliability is supported by maintainable structure. Small, composable services with explicit inputs and outputs are easier to test than large units that combine data access, business logic, transport concerns, and presentation. When a feature crosses a boundary, document the assumptions and failure cases so future changes do not accidentally turn an implicit behavior into an outage.
Featured projects
Jellyfish
Jellyfish is a third-party web client for Jellyfin with Seerr integration. Visit jellyfish.kollod.dev for the project.
Palmus Music
Palmus Music is a music-player concept featuring Apple Music-style lyrics and 30-second previews. Visit palmus.kollod.dev for the project.
Kosmos
Kosmos is a custom panorama viewer built for Google Street View. Visit kosmos.kollod.dev for the project.
Contact and machine-readable resources
To discuss a project, email hi@kollod.dev. Include the intended outcome, timeline, platform, current stage, and any links or material that will help establish the context. You can also find Anson10124 on GitHub, GitLab, npm, and Docker Hub.
Agents and crawlers should use the Kollod agent guide for specific use cases and calling guidance, the XML sitemap for canonical public URLs, and robots.txt for crawl policy. The homepage also supports content negotiation: request it with an Accept: text/markdown header to receive a compact Markdown representation instead of the HTML interface.