TechsityAll work

Case study — careers

Averil.

A career operating system for the person doing the work — not the recruiter hiring them.

StatusLive — averil.ai
Built byTechsity Labs — in house
Who it servesMid-career professionals
Business modelDirect to the individual

The problem

Career advice is written for whoever is paying for it.

Almost every tool in this category earns its money from employers. That shapes everything downstream: the advice optimises for filling a role, not for the person's next five years. The rest of the market sells motivation — courses, certificates, and rewritten résumés with no read on whether any of it is what the field is actually asking for now.

So the person doing the work is left guessing at two separate jobs at once: staying employable in the role they have, and building toward the one they want. Nothing on the market treated those as one system.

The brief we wrote for ourselves: build the thing that tells someone the truth about their own market position, and then what to do about it this month.

What we built

Four surfaces, one loop. Each one answers a question the user actually asks out loud.

Standing

Where you actually are

A read on the user's current skills against what their field is hiring for — stated plainly, including the parts that are weakening. No score theatre, no gamified badge.

The gap

Between now and next

The distance between the job they hold and the one they're aiming at, broken into work that fits around a full-time role.

This month

Small, real moves

A short list of actions with a reason attached to each. If a recommendation can't be justified in one sentence, it doesn't ship.

What it won't do

Designed-in refusals

No mass-applying on the user's behalf, no employer seat, no resale of candidate data. Each of these was a real product decision with revenue attached — and each one is the reason the advice can stay honest.

How we worked

Four phases. The product only got its name at phase three — that's the lab rule.

Phase one

Study

Interviews with people mid-career, plus a read of what the incumbent tools optimise for and who pays them.

Phase two

Prototype

A single screen answering one question, put in front of real users before any account system existed.

Phase three

Name & ship

It survived users, so it earned a name, a domain, and a roadmap. Averil went live on averil.ai.

Phase four

Run it

The build team operates it. Every support thread lands with the people who wrote the feature.

Stack & architecture

Four layers, each replaceable. The evaluation layer is the one we'd never cut.

Layer — signal

What the market is asking for

Ingest and normalise role requirements over time, so "in demand" is a trend rather than a snapshot.

Layer — profile

What the user can actually do

Structured skill and history model owned by the user, editable by the user, never sold on.

Layer — reasoning

Model work, tightly scoped

The model compares, explains, and drafts. It doesn't decide anything the user can't see the reasoning for.

Layer — evaluation

Guardrails before features

Every recommendation path is tested against cases where the honest answer is "don't move yet". Advice that can't pass doesn't ship.

Named technologies per layer are deliberately left off the public write-up.

Screens

The product as it stands today, straight out of the running build.

Averil — the standing screen

Averil — the gap view

Averil — this month's moves

Outcome

What's true today, with the figures reported as they're confirmed.

In production

Averil is live at averil.ai, run day to day by the team that built it.

Held the line

Zero employer seats sold and no candidate data resold — through every revenue conversation so far.

People using Averil

Figure pending publication.

Weeks from prototype to live

Measured from phase two to phase three.

Retention or return rate

Measured over rolling ninety days.

Founder's note

The hardest part wasn't the model. It was agreeing, in writing, to the things Averil would refuse to do — and then not quietly walking them back when revenue asked.

Joseph AyobamiFounder, Techsity

What we'd do differently

Three things we got wrong first time, kept in the write-up on purpose.

Ship the refusals earlier

The "won't do" list was written after the first build, not before it. Next time it's part of the prototype brief.

Fewer surfaces at launch

Two of the early screens existed because they were easy to build, not because anyone asked for them.

Measure the advice, not the app

Engagement told us nothing useful. What matters is whether a recommendation changed something in someone's actual career.

Next case study

LobeStack

Marketing intelligence that runs the whole loop — and closes it.

Build with the lab

Want this write-up to be about your product?