Mid, Senior, Master: How Visuality Defines Seniority

"We need two seniors and one mid." A sentence that opens most project conversations. Our clients look for people who won't need constant supervision, who notice the problem before it becomes an incident, who can be trusted. What the market usually hands them is a job title.

Our pricing page puts a number of years next to every level. Junior at 1 to 3, mid at 4 to 7, senior from 7, master from 13, expert from 18. Those numbers are the least interesting part of the definition. They aren't the criterion. They're what we've observed the criterion usually costs in calendar time.

Seniority Is Not Measured in Years

A senior developer at Visuality isn't a person with seven years of experience. It's a person mature enough to see the future consequences of today's decisions, who thinks about the application rather than the single feature currently in progress.

In our experience that maturity takes about seven years to form. Sometimes it arrives earlier, and we've hired people where it did. Those are exceptions, and treating the exception as the rule is how a team ends up with three seniors on paper and none in practice.

What Mid Level Means: Independence Within the Task

A mid-level developer is independent on standard work. Give them a well-understood feature and they deliver it without breaking what's around it. Inside the task they're reliable, and the task is the boundary.

What doesn't come up yet is everything around it: what happens when the data volume increases 100x, when the next person has to change it, or when the requirement it was built for turns out to be wrong. And that's not criticism - but rather a proper stage of experience applied at its best.

What Senior Level Means: Foreseeing the Consequences

The step from mid to senior changes the unit of work. A senior's unit isn't a task, it's the application over time.

The question shifts from "how do I do this" to "what will this cost us in a year". A senior reads a requirement and sees the places in the codebase that assume the old behaviour. They know which decisions are cheap to reverse and which will outlive everyone who made them.

A senior can safely change a system they didn't build. They know what techniques to apply when it lacks tests or a properly defined SDLC. With experience comes knowledge - usually backed by a good portion of technical literature. As a result, seniors name things precisely and are fluent in discussing complex aspects of the software they build.

And finally, they often excel at mentoring the less experienced - which solidifies the team into one well-oiled machine.

What Master Level Means: Technical Depth and Product Leadership

Master level starts where the application stops being the largest object in view.

A master-level engineer is a technical virtuoso. Not across the whole field, nobody is, but with at least one niche where they're among the best, usually more than one. That depth doesn't stay in its niche. Someone who has been to the bottom of one thing (a db query planner, service oriented architecture, a payment domain) reasons differently about everything else, because they know what the bottom looks like and how far short of it most explanations stop.

On top of that depth sits leadership. A master can take technical or strategic ownership of a product, holding the architecture and the reasoning behind it: which constraint came from the business, which from the budget, which from a decision in 2019 that nobody has revisited. They can run the analysis with a client and come back with a scope that solves the actual problem rather than the one described.

Master is rare, and the year count is the weakest predictor here. Thirteen years is where this becomes possible, not where it happens.

Experience Alone Doesn't Produce Seniority

Plenty of developers with 15 years of experience are still working with mid-level mental models. Most good developers at that point are seniors. A few are masters. The distribution isn't a function of time, and it pays to understand the reason behind it.

Consequences arrive late. A decision about the data model shows its real cost 18 months later, when a requirement arrives that the model can't express. If you weren't still there, you never received the feedback. Five years spent starting ten six-month greenfield projects is five years of beginnings. Five years spent on one system that kept growing is five years of consequences. Both look identical on a CV.

This is the mechanism behind the year ranges, and behind our reluctance to shorten them. Judgment is assembled out of closed feedback loops, and closing a loop takes calendar time that working harder doesn't compress. What does compress it a little is spending that time somewhere the loops actually close: on products that live for years, under review by people further along than you, on systems where you are the one who gets called when your decision from last spring breaks.

A related consequence is that staying senior isn't a failed attempt at master. Senior is where most of the strongest engineers we know operate, and a team of seniors who know exactly how far their judgment reaches is priceless.

Expert Level: Beyond What the Market Asks For

Above master there's one more level on our pricing page. Expert, from 18 years: former CTOs, people who have run startups, owned products, and been involved in hundreds of projects.

What an expert adds is calibration. They have watched a lot of systems work and a lot of good ideas fail, and that judgment is what makes them useful as a fractional CTO on somebody else's product.

The market rarely shops at this level, because the vocabulary stops earlier. In many companies senior is the top of the ladder, so master already sits past the edge of what a job posting can express. Expert exists because the work exists, not because anyone asked us for the label.

We Don't Rush the Label

A title costs nothing to award, and it moves risk onto whoever is paying for it. When a company calls a developer with four years of experience a senior, the client who booked a senior gets barely mid-level judgment on a decision that will outlive the project. Nobody notices at the time. The cost surfaces about 1 or 2 years later, in the same window where seniority itself becomes visible.

So we hold our own definitions, and the years on the pricing page stay where they are. They aren't a claim about how long somebody has been employed. They're the shortest honest answer to the question a client is really asking, which was never "how experienced is this person" but "how far ahead will they see".