There is usually one technical concept sitting quietly on your mental backlog. You may have bookmarked articles about it, saved a course or watched someone else build it, without ever finding a strong enough reason to tackle it yourself.
For me, that was building a REST API end to end.
It was not something I had avoided because it felt beyond me. I simply had not needed to do it in my day-to-day work. My professional experience had given me depth in other areas, while APIs, databases and authentication sat slightly outside the work I normally owned. That made the gap easy to leave alone.
I wanted to close it because I did not want my experience to become too narrow. Building the application was a chance to connect concepts I understood individually and become a more rounded engineer.
The gaps we can afford to ignore
Some gaps persist because they do not cause an immediate problem. If your current role does not require a particular technology or type of system, there is rarely any pressure to learn it properly. You can understand the broad concepts, follow technical discussions and still never have to connect the pieces yourself.
That was my position with REST APIs. I understood the individual ingredients, but I had never owned the complete journey from endpoint design and validation through to persistence, authentication and testing.
The gap was not holding me back in my current work. But closing it would broaden the kinds of systems I could understand and build.
Reading helps. Tutorials help. Documentation definitely helps. Eventually, though, learning becomes avoidance wearing sensible shoes.
A real project gave the gap a deadline
The Eagle Bank REST API began as a take-home test, and it gave the gap a deadline. There was a defined problem, clear requirements and an expected result — and five days to deliver it. That ruled out spending another week comparing frameworks, researching patterns or designing the perfect folder structure. I had to start making decisions.
The project was a REST API for a fictional bank, covering users, bank accounts and transactions, with authentication, persistence, validation and automated tests. None of those ideas were unfamiliar on their own. What I had not done before was connect them into one coherent application, and that was the part the project finally forced me to do.
End-to-end means more than CRUD
It is tempting to describe the project as a CRUD API. That is technically true, but it misses the useful part. Creating, reading, updating and deleting records was not the difficult bit — the interesting work happened around those operations:
- authenticating requests
- validating input
- enforcing business rules
- modelling database relationships
- handling errors consistently
- restricting access to owned resources
- testing successful and unsuccessful paths
For example, creating a bank account was straightforward. Making sure an authenticated user could access only accounts belonging to them required more thought. The ownership check itself was simple:
account = get_account_by_number(db, account_number)
if account is None:
raise HTTPException(
status_code=status.HTTP_404_NOT_FOUND,
detail="Bank account was not found",
)
if account.user_id != current_user.id:
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail="The user is not allowed to access this account",
)
return accountThe value was not in writing a clever conditional. It was in understanding the wider request flow around it: authenticate the caller, identify the current user, retrieve the requested account and reject access when ownership did not match. That is exactly the kind of problem tutorials skip while rushing towards the next endpoint, and building the whole application forced me to deal with those awkward edges rather than stopping once the happy path worked.
Use the gap as a project brief
I now treat a persistent gap in my technical experience as a useful project prompt. The aim is not to learn every technology for the sake of it. It is to notice when a missing piece would make me a more capable and rounded engineer, then find a practical way to explore it. That means building something small enough to finish, but complete enough to expose the difficult parts.
A toy example can prove that a library works. It rarely teaches you how an application fits together. The Eagle Bank API made me work through authentication, persistence, ownership rules, testing and application structure as connected concerns.
JWT authentication sounded like a substantial topic when it was still a box on an architecture diagram. Once I had implemented token creation, validation and protected endpoints, it became another part of the request flow. The same happened with database relationships and ownership checks.
The problems did not disappear. They simply stopped being mysterious.
Using AI without outsourcing the understanding
My working loop throughout the project was simple: build a feature with help from AI, then question the parts I did not understand until I could explain what the code was doing and why.
AI helped me move through unfamiliar territory without getting stuck on every small implementation detail, but I did not want code that merely appeared to work — I wanted to understand the decisions underneath it.
That meant asking follow-up questions:
- Why does this dependency run before the endpoint?
- Where does the current user come from?
- Why should this error be a 403 rather than a 404?
- What happens when the database transaction fails?
- What should the test prove beyond the happy path?
Used this way, AI became a fast feedback loop rather than an answer machine. It helped me build momentum while still forcing me to engage with the concepts. The rule I followed was straightforward: never keep code in the project that I could not explain.
What I got from shipping it
Finishing the project changed how I thought about the technologies involved. I no longer understood them only as separate concepts — I had seen where they connected, where responsibilities became unclear and where apparently simple decisions created knock-on effects elsewhere.
Instead of saying I had been learning about REST APIs, authentication or testing, I could share the finished Eagle Bank REST API and talk about the decisions I made.
Finishing it also created a sense of possibility. Once the pieces connected, I stopped thinking only about the API I had built and started thinking about everything else I could build with the same knowledge. The repository is now a useful reference for future work too — I can return to it, criticise old decisions, reuse patterns that worked and see where my thinking has changed.
A completed project keeps teaching you after you ship it. A folder of tutorial notes rarely does.
When not to do this
“Go build it” is useful advice, but only when the project is designed to survive contact with your free time. Do not choose something so large that finishing it becomes unrealistic — building an entire banking platform is a terrible learning project, while building a small banking API with a limited set of resources is manageable.
Do not rely entirely on motivation either. A deadline, take-home test, public commitment or clearly defined deliverable creates useful pressure; without one, it is easy to spend weeks polishing the plan and never starting the work.
For the Eagle Bank API, finishing meant adding tests for invalid data, missing resources and unauthorised access, and writing setup instructions so someone else could run the project. Do not stop when the first successful request comes back. Keep the scope small, then finish all of it.
Go do the thing
Pick the gap in your experience that you have not needed to close yet. Define the smallest complete project that forces you to use it properly — AI can help here too: give it the technology you want to learn and ask it to create a realistic, tightly scoped project brief.
Then give yourself a deadline. Build the working path, then add the validation, errors, tests and documentation that make it complete. Question anything you do not understand.
You do not need to feel ready. Readiness often arrives shortly after you start.