In March, 2026, Joris de Haas reached out to us. From years of experience in hyper-growth companies, he'd seen leaders answer their hardest questions on gut-instinct rather than real, tangible data and actions.
We initially spoke about his plans for skillfora, what he wanted to test, and how I'd recommend approaching the project.
I could tell Joris knew the problem really well. He'd already put together multiple prototypes in Figma Make and was trying to get eyes on them.
This is where the industry has changed recently. Previously, Joris would've come to us for these prototypes. Now he had them in-hand, before we'd even spoken.
And that was a good thing.
I encouraged Joris to not subscribe to our services just yet. I was keen for him to get his prototypes in front of a few more interested parties and understand how it could be refined, before we jump into a full brand, site and app design.
We agreed that he'd continue iterating and prototyping himself until he was ready to turn his concept into a reality.
Two months later, in June, Joris returned with updated prototypes and an eagerness to get building.
Between June and September, we:
- Created the skillfora brand
- Designed and launched the marketing site, with live in-browser demos of the product
- Designed the entire product in Figma, and built and shipped it to production
- Built fora, the AI assistant at the heart of the product, on Anthropic's Claude models
- Turned onboarding into a single upload: a company drops in the documents it already has, and skillfora builds its skill profiles and job level framework from them
- Shipped over 600 commits backed by more than 1,400 automated tests
Brand first
We started with a brand, as fundamentally that branding would feed into every piece of design work we did, whether it was the marketing site or the product. Within a couple weeks, I brought a few concepts to him, and we decided which to move forward with.
A marketing site that feels like the app
Next, we designed and launched the skillfora marketing site.
We encouraged the build of the marketing site before the product, as it would allow Joris to get eyes on the idea faster, easily share it and capture early-access sign-ups from interested companies.
Typically, we would've suggested a build on Webflow, but we were both keen on the idea to let people feel as though they could try the actual product on the site, quickly, without an account.
So, we advised him to build his marketing site with Next.js. This meant we could simulate an app-like experience for demos in-browser, but we could also build re-usable components across the marketing site and the product. People would be learning how to use the product before they'd even set up an account.
We launched the site with some information about Joris, the product and a selection of real demos which covered all of the key functionality, backed by a demo company sandbox. These demos produced results and insights which were pretty much identical to the real thing. Visitors could chat with fora, build a skill profile or create a job level framework, all against the sandbox company's data.
Every piece of copy on the site lives in Sanity, so Joris can rework the messaging as he learns from conversations with customers, without waiting on a deploy.
From there, we designed and built the real skillfora product.
The principle behind the product
Most companies have tried to track skills before. It usually ends as a spreadsheet someone filled in six months ago that nobody has opened since. Skills tools fail when they ask people to do admin, so the brief was the opposite: skillfora should do the reading, suggest what it finds, and let a person make the final call.
That principle, skillfora suggests, you decide, shaped almost every design decision that followed. fora never writes straight into an organisation's data. It drafts a proposal, shows its working, and waits for someone to accept it.
How we worked
Joris's Figma Make prototypes gave us a real head start: they showed exactly what he wanted the product to do. I took them as the brief and designed every flow properly in Figma, on the new brand, refining things as I went, before a line of it was built. Then I implemented each one against the design, flow by flow, testing it with realistic company documents before it shipped.
I built with AI coding agents alongside me, which is what made a product of this scope possible for a team this small. I owned the design, the product thinking and the architecture; the agents covered the boilerplate. To keep that honest we set up a few guardrails:
- A decision log. Every meaningful product and technical call, more than 120 of them, was written down with its reasoning and the condition for revisiting it. When something needed changing weeks later, the reasoning was right there.
- A test suite as the safety net. Every feature landed with tests, and nothing deployed unless they passed.
- Independent review. Before real users arrived, we had a second model audit the onboarding flow purely for ways it could trap someone, then fixed everything it found.
A walking skeleton first
The biggest unknown was the AI itself. You can't design the right data model for a skill profile until you've seen what the model actually produces, how verbose it is, and how people react to its drafts.
So rather than building the whole product up front, we built a thin slice that went all the way through: ask fora for a skill profile, watch it draft one live, accept it, see it saved. Once that loop worked, we rebuilt the underlying model properly around what it had taught us.
Onboarding: from a pile of documents to a working platform
The feature that changed the product most came from a prospect. They didn't want to fill in forms; they wanted to hand over the files they already had and have the platform make sense of them.
So onboarding became five steps: create the organisation, define a proficiency scale (between three and five levels, each named and described by the customer), upload context, review, and go. In the upload step, a company can drop in job descriptions, an existing levelling framework, staff lists or performance reviews in whatever format they live in. fora reads them and turns them into skillfora's structure: skill profiles for each role, a job level framework, and the people in the organisation, each matched to the profile they belong to.
A few design decisions mattered most here:
- Show the work. Analysis can take a while, and a spinner on its own seems broken. Each stage now reports its progress and turns green as it completes, so people can see something real is happening.
- Review before anything is written. Nothing reaches the organisation's data until someone has seen a preview of it, split into tabs for skill profiles and people, and approved it.
- Make it escapable. Every step can be revisited from the sidebar, and a failure part-way through can always be picked up where it stopped, rather than leaving someone stuck on a screen with no way out.
- Scale quietly. A 45-row staff list is small. A 5,000-row HR export isn't, so large spreadsheets are read by having the model map the columns from a sample, then applying that mapping to every row in code.
A welcome worth waiting for
Immediately after onboarding comes a short welcome sequence before the product itself. I wanted it to feel light and inviting, and to build a little excitement.
For people invited into an existing organisation, a guided tour then walks them through the key features. Rather than just describing what's possible, it has them do things, like opening a skill profile to review it or comparing a person against a profile, with a pulsing marker that eases from one feature to the next.
fora, the assistant
fora sits in a side chat across the whole app and can be opened into a full conversation. Ask it to draft a skill profile and it streams the draft as it writes; ask it to change the job level framework ("remove PD3", "add a track for QA", "move Design Engineer to E4") and it proposes the change for you to accept. It can see the organisation's people, so "who's the closest skill match now Jenny's leaving?" gets an answer with names and evidence. When a question is really a comparison, fora answers it and links straight into the comparison view to dig deeper.
It's the same chat box visitors meet in the marketing site's demos, which is the re-usable component idea paying off: anyone who tried a demo already knows how to talk to fora when they sign in.
The rest of the product
- Skill profiles for every role, with a radar chart of the skills required and the level each one is needed at. Profiles can be shared with colleagues for comments and sent to several reviewers for calibration, with everyone able to see who still needs to approve. They also download as PDFs.
- Job level framework. Company-wide levels alongside department tracks, built from a template, an import or scratch. Headings can be renamed and recoloured, profiles dragged between tracks, and each level carries written competency descriptions, which fora can draft for any that are left empty.
- People. Each person's page shows their skills against the thresholds their role expects, with bars that animate up and change colour as they meet or exceed the line. People are private to their organisation and only visible to its admins.
- Comparison. Compare two profiles, two people, or a person against a profile. The insights focus on readiness: how ready someone is for a role, based on the skills they have and the skills it needs.
Privacy by design
skillfora handles information about people's careers, so privacy couldn't be an afterthought.
Admins can correct, export or delete everything held on an individual, and data that is no longer needed expires on its own: uploaded documents and onboarding proposals after a month, old notifications and resolved comment threads after a month, and conversations after six months. We also drafted the terms page covering how data is used and which third parties process it.
We designed skillfora to be GDPR compliant.
The outcome
In four months, skillfora went from a set of Figma Make prototypes to a brand, a marketing site capturing early-access sign-ups, and a live product in production, with a design partner programme running alongside it.
Designing and building it ourselves meant no gap between how a screen was meant to work and how it actually did. When something felt off in testing, it was fixed that afternoon.