Velory

IT Lifecycle 


New Platform

& Principle Engineer

Project

Velory is a B2B SaaS platform for IT lifecycle management — helping companies buy, track and responsibly retire workplace technology, from employee onboarding through to end-of-life.In January 2026 we decided to rebuild the entire platform from scratch. Not refactor it, not migrate it — start again on a new stack, with a new way of working. A group of five people was pulled out of the company to answer one question: in three months, can we get the new platform far enough that we can let a real customer in and try it?
‍
Company: Velory, Stockholm
Role: Head of Design → Principal Engineer, Experience
Period: January 2026 – ongoing
Team at start: 5 people

My role

I owned UX and UI for the new platform. The bigger change is that I also built it: I take features from problem definition through to production myself — research, design, then the code, and the pull request that ships it.

Over the first seven months that meant owning whole areas of the product end to end, not just their design: employee onboarding and starter kits, the asset lifecycle, service and repair, software and licence management, procurement and store surfaces, and the settings around them.

Alongside the product work I built what lets everyone else hold the design line — the design system in Storybook, a written design specification, and AI tooling that makes our design and UX principles enforceable on every pull request, no matter who wrote it.

Discovery

Why rebuild rather than improve
The existing platform was built on an ageing Ruby on Rails codebase that had grown without enough structure. Three things had become true at the same time:

‍• Development was slow and expensive. Maintenance ate a disproportionate share of our engineering capacity, and every new capability cost more than it should.
‍
• Customers needed flexibility the platform couldn't give them. The system was chunky and tightly coupled; the kind of configurability our customers were asking for was very hard to reach from where we stood.
‍
• AI-assisted development was effectively off the table. The step change in AI coding tools had just landed, but the old codebase was not a place where those tools could work usefully. Adopting them meant a codebase built for them.

So the rebuild was not a technology preference. It was the only route to the speed and flexibility the business needed.

Unknown territory
There was no playbook for this. Building a platform this way — a small group, AI-native from the first commit, designers shipping production code — was new enough that we could not look up how anyone else had done it. We had to find the working method while we built the product.

Define

Five people, one question, no distractions
Everyone in the group was senior, and that was deliberate. Five people hand-picked both for experience and for how well they would work together — senior enough to make decisions without asking permission, and to keep moving when nobody could tell us what the right answer was. We isolated ourselves from everything else going on in the company and worked to a single goal: get the new platform to the point where one customer could come in and use it, within three months.

The motto in the group was: we are all builders.

That was not a slogan about attitude. It was the operating model. There were no handovers to wait for, no standups, no tickets thrown over a wall. Whoever picked a problem up carried it to production.*

What that changed for me
My working life changed more than anyone's. My previous process was Figma-shaped: FigJam for discovery and insights, Figma for prototypes, at best a lightweight clickable prototype to test with, then a long specification handed to developers describing what they should implement.

Now I was the developer. Same problem definition and research at the front, but the output was working, production-ready functionality instead of a document describing it. The design system moved out of Figma libraries and into Storybook, built in code.

The first week I was genuinely confused — about how the pieces fitted together, about how we should structure anything, about what my job now was. I also understood something clearly: I needed to be on this train, or I would not have a job on it. So I got on.

Solution

We started fresh, choosing tools that AI coding agents work well with and that let five people operate like a much larger team.

Next.js
React
TypeScript
Supabase (Postgres)
Supabase Auth
Edge Functions
Vercel
Storybook
Bun
Monorepo
next-intl
Playwright
Claude Code
Cursor
Claude Code
Linear

Two decisions mattered more than the individual tools. Everything ran through pull requests with preview environments and database branches, so any change — mine included — could be opened, seen and reviewed as a working thing rather than a description. And the repository documented itself for AI agents as well as people, so the context needed to build correctly lived next to the code.

Design

I started building the design system in Storybook in the first days of the project, in code rather than as a Figma library. Components, typography, tables, dark mode — the pieces the product would be assembled from, as real code the team could import immediately instead of rebuilding from a spec.

The harder problem was consistency at speed. When everyone is a builder and AI writes a large share of the UI, a design system decays quickly unless something actively holds the line. So I wrote the design system down as a specification, and then made it enforceable:

- A design skill for Claude, so that anyone building front-end — designer or not — generates UI that follows our patterns by default.
‍
-A design review step that can be run locally before pushing, so problems get caught before review.

- A design reviewer on every UI pull request, checking it against Velory's design and UX principles. It launched as advisory and moved to blocking, with accessibility standards as non-negotiable criteria.

The point was to stop the system drifting one merge at a time — without becoming the bottleneck that every UI change has to queue behind me.

Build

My first pull request went up on day two of the project — the first one I had ever opened. From there the work stopped being design deliverables and became features. The areas I took from problem to production:

- Employee onboarding. The onboarding wizard, fixed and flexible starter kits, hardware variant selection, over-allowance swaps with approval, software provisioning on day one.

- The asset lifecycle. The full lifecycle flow end to end, the renewal wizard, and the employee asset view with report-a-problem and start-renewal built into it.

- Service & repair. The admin case flow, the employee side for reporting and following a repair, swap pickup — then wiring the whole thing into the workflow engine.

-Software & licences. Bulk licence assignment, quick-assign on detail and plan pages, agent handling.

-Procurement & store. Catalogue and store surfaces, bundles, ordering and approval flows.

- Platform surfaces. Organisation settings, projects with sections, steps and tasks, CSV import, event log, localisation.

Design decisions got made in the medium they would ship in, which removed a whole category of loss — the gap between what a specification said and what actually got built. It also changed what a design decision costs. When you are the one implementing it, you find out immediately whether an idea survives real data, real edge cases and real load, instead of finding out weeks later in review.

I also kept building the tooling around the work, not just the product: /velory-deck, a skill that turns a feature description into a presentation with real screenshots from the platform dropped into Velory-templated mockups — so shipping a feature and being able to show it stopped being two separate jobs.

Testing

Every pull request produced a preview environment with its own database branch, so features could be tested as real software early, by anyone. Automated end-to-end tests, type checking and the design review ran as gates. What we could not automate we tested internally end to end before letting customers near it.

Go live

The three-month question was answered: the platform reached a state where customers could be brought in, and the first pilot customers started working in it. From there it moved from proof of concept to a product with real customers migrating onto it, feature by feature, with a builder from the team attached to each customer.

The group of five became the seed of something much larger.

5 → 28
people building on the new platform
~3,300
commits in the first seven months
~2.5M
lines of code

Optimization

Speed has a bill, and it arrives later. Once real data volumes and real customers hit the platform, we found the places where version one of a subsystem did not hold: queries that assumed they were getting every row, listing pages counting far more than they needed to, search patterns that scanned whole tables, sync processes that ignored the limits of the services they ran on.

Working in the open the way we do, those problems surfaced fast and got fixed in days rather than quarters. The same is true of design: customer-reported UX issues come in as tickets and get fixed by whoever picks them up — often the same person who designed the flow in the first place.

Conclusion

Professionally this is the biggest shift of my career. I went from specifying work for other people to building and shipping it myself, and my job became two things at once: owning features end to end, and making good design reproducible by everyone else through the system, the specification and the AI tooling around them. The role has since been renamed to match what it actually became — I moved from Head of Design to Principal Engineer, with experience as my focus.

What I would keep: the small isolated group, the single question with a deadline attached, and the rule that whoever picks a problem up carries it to production. It removes an enormous amount of coordination cost and it is the reason five people got this far in three months.

What I would do differently: invest earlier in the guardrails. The design reviewer, the specification and the automated checks all came after the first wave of building, which meant paying down inconsistency we could have avoided. When AI can produce UI faster than anyone can review it, the thing that defines quality has to exist before the volume arrives, not after.

On who builds what, I had a hunch going in, and the project confirmed it. AI is a supertool, but it does not flatten expertise, and it is worth having real respect for the entry point every new builder arrives from. I came into this from UX and UI — having AI tooling does not make me an expert in database migrations or backend architecture. It runs the other way too: a full-stack developer with the same tooling has not become a UX and UI specialist. Where you came from still shows in the work.

So the conclusion is not that we should all work alone now that we technically can. It is that we should collaborate on purpose — pair up on features and projects, and use the strengths we each came in with. Being able to go end to end by yourself is what makes you fast on your own ground.

We are all builders — but the speed comes from collaborating, not from working alone.