Music · Rights SystemsApplication / Alex Kostyniuk

I build the dense interfaces that professionals work in all day: multi-step flows, permission models, and tables that stay fast when the dataset stops being small.

Frontend Engineer · TypeScript & React · Stockholm

Alex Kostyniuk

Now building

B2B rights workflows

React · TypeScript · APIs · Permissions

Why we're a perfect fit

Why Spotify should hire me

I have built this shape of product
Kanban, Gantt, Scrum, and scheduling interfaces: multi-step workflows, dependent state, and permissions over data that is never small. That is the shape of the Rights Center.
Complex state, kept legible
Large datasets, pagination, streaming updates, loading and error states. I treat those as the design problem rather than an afterthought once the happy path works.
TypeScript and React daily
This is my stack, including Next.js, and I care about component and state boundaries that still hold up when three squads are working in the same codebase.
I help shape the API
I integrate REST and GraphQL services and would rather design the contract with the backend engineers than build around whatever arrives.
Performance under real data
I turned a ten-minute core workflow into a twenty-second one by challenging the architecture, not merely tuning it. Rights-scale tables reward exactly that instinct.
Accessible and tested
Types, unit and integration tests, and end-to-end coverage are how I move quickly without breaking a tool people depend on to protect their catalogue.

Why I want to join Rights Systems

The problem is genuinely hard
Content scanning, enforcement, disputes, and territory-level rights are a real domain with real consequences. Going from inception to a live platform in a year is the kind of team I want to be on.
B2B deserves consumer polish
Labels and publishers spend their working day in this tool. Giving them the clarity Spotify gives listeners is the most satisfying kind of frontend work I know.

How I work.

I start with either a problem to solve or a business idea. I shape it around customer needs and technical realities, and look for a solution that can serve many customers instead of just one. Once the core is clear, I work with Design team on the experience, break it down into a focused story, and leave it ready for a developer or me to build.

How I develop features

  1. 01

    Start with an agent

    I always work with an agent. For bigger features or bugs that aren't obvious at first, I use specific skills to help it focus. For smaller tasks, I explain what needs doing and jump in.

  2. 02

    Scope the solution

    When the work needs a plan, I turn it into a detailed spec, including edge cases and what done looks like.

  3. 03

    Implement with agents

    Once the task is clear, I let one or more agents build the feature.

  4. 04

    Create feedback loops

    Browser Use, types, and tests help the agents see what they built and catch their own mistakes.

  5. 05

    Check manually

    I still open the feature and use it myself, from start to finish.

  6. 06

    Run an agent review

    I ask fresh agents to review the work and catch anything the first ones missed.

  7. 07

    Review the code

    Then I read the diff myself and fix whatever is left.

  8. 08

    Babysit the PR

    Finally, an agent watches CI and review comments until the PR is ready to merge.

Outcome

The result is a feature that has been planned, built, checked, and reviewed from a few different angles, usually in much less time.

Let's make rights feel as simple as pressing play.

Spotify × Alex

Continue to my portfolio

Open Portfolio
Download CV