Flutter Developer Competency Map
Six areas, forty-eight topics, and for each one: what it is, what to understand about it, what competence looks like at junior, middle and senior level, what to practise, and where the good material already is.
It is a map, not a course. Nothing here teaches a topic — other people have done that better and at greater length, and each page points at their work. What the map gives you is the shape of the whole territory, so you can see what you have not looked at.
Use it to assess where you actually are, find the next thing worth learning, structure a mentoring conversation, or write a review that is about skills rather than impressions.
Levels
The same four levels apply across every area. They describe scope of responsibility, not years served.
| Level | Scope | Technically | With people |
|---|---|---|---|
| Junior | A task | Does things well with clear examples and templates. | Follows the instructions they are given. |
| Middle | A feature | Solves ordinary problems and builds features within the existing structure. | Organises themselves and works as part of a team. |
| Senior | A product | Designs architecture, solves hard problems, finds creative solutions. | Spots problems, escalates early, leads discussions, helps others do their jobs. |
| Lead | A team | Sets methodology across a team and several projects, and sees the consequences of decisions before they land. | Runs team processes and takes people somewhere. |
Every topic page carries its own junior/middle/senior table for that specific skill, because nobody is one level across all six areas.
1. Foundations
Engineering thinking that outlives any language or framework.
- Algorithms and Data Structures — choosing how to store and process data so it still works when there is more of it
- Architecture and Code Organization — where code lives and what is allowed to depend on what
- Data Modelling — turning a domain into entities, relations and constraints that hold up
- Networking and HTTP — what actually happens between an app and a server, and how it fails
- Debugging and Problem Solving — finding the cause instead of changing things until it works
2. Dart
The language, and everything that runs on the server.
- Type System and Null Safety — using types to make wrong states impossible rather than merely caught
- Asynchrony, Futures and Streams — single-threaded concurrency and the ordering bugs that come with it
- Isolates and Concurrency — real parallelism, and when it is worth it
- Collections and Functional Style — expressing transformations clearly without hiding what they cost
- Code Generation — letting the build write the boilerplate
- Server-Side Dart — running the backend in the same language as the app
- APIs and Contracts — designing the boundary so it can change without breaking
- Databases and Migrations — querying efficiently, and changing a schema that already holds real data
- Authentication and Authorization — proving who someone is, and deciding what they may do
- Realtime — pushing changes to clients over a connection that keeps dropping
- Background Jobs and Scheduling — work that happens without a request, and fails silently
- Files and Uploads — moving bytes without routing them through your server twice
3. Flutter
Everything on the client.
- Widgets and Composition — how the widget tree actually works
- Layout and Rendering — constraints down, sizes up, and why it says unbounded height
- Navigation and Routing — where the user is and what back should do
- Theming and Design Systems — appearance decided once, so features never mention a colour
- Adaptive and Responsive UI — phone to desktop without four layouts
- Animation — motion that explains what happened, within frame budget
- Accessibility — usable by people your testing never included
- State and Data Flow — where state lives, who changes it, how the UI finds out
- Working with Data — fetching, caching, and behaving well with no network
- Platform and Device — permissions, notifications, deep links, native code
- Performance — measuring before optimising
- Testing Flutter Apps — which failures each level can actually catch
4. Engineering Practices
How work gets from an idea to users, repeatably.
- Git and Workflow — a history someone can read
- Code Review and Conventions — reviews that catch real problems without becoming a bottleneck
- Static Analysis and Linting — letting the analyzer enforce what people otherwise repeat
- Testing Strategy — what to test, at which level, and what to leave alone
- CI/CD — every change built and shipped the same way, by a machine
- Release and Distribution — getting a build to users, and what to do when it is wrong
- Monitoring and Crash Reporting — finding out before your users tell you
- Security — assuming the client is hostile
- Planning and Estimation — being wrong less expensively
5. AI in Development
A real skill area now, with its own technique and its own failure modes.
- Working with Coding Agents — what to delegate and what to keep
- Context and Conventions for AI — making a codebase an agent can work in
- Reviewing Generated Code — reading a change written by something that is never uncertain
- Limits and Failure Modes — where these tools reliably fail
- AI in Review and Testing — pointing it at verification, where a second reader is cheap
6. Product and Team
What separates someone who closes tickets from someone who ships products.
- Requirements and Scope — understanding what is needed before deciding how to build it
- UX Fundamentals — the hundred small decisions nobody specifies
- Analytics and Impact — knowing whether what you shipped helped
- Working with Designers — turning a design file into a product without guessing
- Technical Communication — writing so decisions get made
How to use it
- Pick one area that is blocking real work right now. Not the one you find most interesting — the one costing you time this month.
- Read that topic's levels table and locate yourself honestly. The gap between where you are and the row below it is your next piece of work.
- Take one task from Practice. They are product tasks rather than exercises, because the topic is easier to learn where it actually appears.
- Answer the questions under Check yourself. The valuable ones are those you cannot answer.
- Read one thing from Resources, properly, rather than five things partly.
- Come back in a few weeks and move on. Nobody is senior across six areas, and trying to be is a good way to be middle at all of them.
Used with someone else — a mentor, a lead, a peer — the Check yourself questions work better as a conversation than as a self-assessment. They are written to be asked out loud.