There is no shortage of content for people learning tech.
The harder part is often knowing what to do next.
Which area should I explore? What should I learn after choosing one? How should I organize that learning? And once I understand the basics, what should I actually build?
Those questions are usually answered in different places.
That was the starting point for Rota.tech.
The problem I wanted to work on
When someone starts learning technology, having more information does not always make the journey easier.
You can find courses, roadmaps, videos, documentation, career tests, project ideas and AI tools within minutes.
But the user still has to connect all of that:
direction → learning → practice
I wanted to see what would happen if those decisions were part of the same product instead.
What Rota.tech does today
Rota.tech is a web platform designed around different moments of that journey.
Today, someone can:
- explore different areas of technology before choosing one;
- answer a tech career discovery test and receive a personalized direction;
- generate a learning roadmap organized into six progressive phases;
- create a structured project proposal based on the technologies and type of project they want to practice.
There is also a personal area where saved results can be accessed again.
The important part for me was not simply putting several tools on the same website.
They needed to feel like possible next steps of the same journey.
Where AI actually makes sense
One decision I made early was that AI should not be everywhere just because Rota.tech is an AI-oriented product.
Some information does not need to be generated every time.
The area exploration section, for example, is public editorial content. Its purpose is to clearly explain what Backend, Frontend, Mobile, Data Engineering, AI, DevOps and Cybersecurity actually involve.
Personalization becomes more useful when the answer depends on the person.
That is where AI is used in Rota.tech: career discovery, personalized roadmaps and project generation.
The goal is not to let a model freely decide the whole experience. The application defines the inputs, expected structure and business rules around each generation.
Generated responses are validated before the rest of the flow accepts them.
That became especially important once the product moved from experiments to something people could actually use.
Building the learning flow
Roadmaps were an interesting product challenge.
A roadmap can easily become either too generic to be useful or so detailed that it becomes another course.
Rota.tech currently structures them into six progressive phases. Depending on the user's goal, the flow can help someone discover a technology inside an area, learn a chosen stack, or move from one technology to another.
Each phase combines technical content with something practical to build.
The roadmap is generated first as a temporary preview. Only after confirmation does it become the saved roadmap for that user.
That distinction between generated and confirmed state ended up being useful in other parts of the product too.
Turning learning into something to build
More recently, I worked on the project lab.
I did not want it to be another "give me 10 project ideas" generator.
The user provides the technical area, technologies they want to use, project size, priority and a context of interest.
From that, the platform generates one project proposal with a defined problem, solution, estimated effort, technical scope, core capabilities and criteria that make those capabilities verifiable.
It is intentionally not a tutorial or a finished architecture.
The idea is to provide enough structure to start building while leaving the implementation decisions to the developer.
A few engineering decisions that mattered
The frontend is built with Next.js, React and TypeScript.
The backend uses Java and Spring Boot, with PostgreSQL for persistence and Spring AI for the AI integration. The backend is organized into domain modules for identity, discovery, roadmaps and projects, with shared infrastructure separated from the domain logic.
One lesson from adding AI to real product flows was that a model call cannot be treated like a function that always returns the expected result.
It can fail.
It can time out.
It can return something structurally invalid.
And if that happens, the user should not lose one of their available generations for a result they never received.
So generation, validation, temporary state and persistence are deliberately separated in the flows where that distinction is needed.
This sounds obvious afterwards, but it changed how I thought about AI features. The difficult part is often not making the model answer. It is deciding what the application should do around that answer.
The product principle I keep coming back to
While building new features, I started using one question as a filter:
Does this simplify the user's journey?
It sounds basic, but it has been useful.
Adding another option, another screen or another AI-generated field is easy.
Making the next decision clearer is harder.
Sometimes the better solution has been to remove something instead of adding more intelligence to it.
Where the project is now
Rota.tech is already live in production and has passed 50 registered users, besides people who use the public parts of the platform without creating an account.
It is still early.
I am currently much more interested in understanding real usage, improving the journey and discovering which parts deserve to grow than in filling the product with features.
The platform is currently available in Portuguese.
If you want to try it:
I would especially like feedback on one thing:
Does connecting direction → learning → practice in the same experience make sense to you, or would you rather use specialized tools for each step?
Top comments (0)