The session was not only about technology. It was about initiative. It was about moving
beyond the paralysis many developers feel when they stop acting only as task executors
and start thinking like product owners.

As part of the SouJava JUG, SouJava Brasília continues to create spaces
where developers can learn, share experiences, and see new possibilities for career,
product creation, and entrepreneurship within the Java and technology ecosystem.

When the developer becomes responsible for everything

One of the central points of the conversation was the change in the developer’s role when
they decide to create their own software. In a company, roles are usually well defined:
developers, designers, product owners, product managers, infrastructure professionals,
DevOps, marketing, and sales.

But when someone decides to bring an idea to life alone, all of that starts falling on
the same person. It becomes necessary to think about the product, the user, validation,
architecture, design, infrastructure, deployment, operation, and later, sales.

This accumulation of responsibilities often creates fear and paralysis. Many developers
know how to build software, but they freeze when they need to decide what to build, who
to build it for, how to validate it, how to publish it, and how to find the first users.

Creating a product is not only about writing code. It is about taking responsibility
for the whole problem: user, validation, delivery, operation, and value.

Build something fun to get started

Bruno brought a simple and important message for those who want to start: build something
that is fun for you.

Not every project needs to be born as a big company, a revolutionary solution, or a highly
scalable SaaS. Sometimes, the first step can be a simple tool, an experiment, an automation,
or an application created to solve a personal curiosity.

During the session, Bruno showed an example of an application created with AI support to work
as a kind of interactive board, allowing him to draw and write over his own screen during
presentations. He made it clear that he was not a mobile developer and did not master every
technical detail of the technology used, but the process was useful, fun, and full of learning.

This is an important lesson: not every learning process needs to start from obligation.
Fun projects help reduce fear, stimulate curiosity, and create space to explore new tools.

AI accelerates, but still requires intention

Artificial intelligence appeared in the session as an acceleration tool. Bruno commented that
AI is increasing the speed at which developers can build, test, and experiment.

But he also highlighted that not everyone is using AI in the same way. Some people use it only
as occasional support. Others incorporate it deeply into their daily workflow. There are also
differences in access, cost, plans, token limits, and company policies.

Regardless of the level of usage, the message was clear: AI can help a lot, but the developer
still needs intention. They need to know what they want to build, what problem they want to solve,
how they want to validate it, and how they will turn an idea into something useful.

Asking AI to generate code without direction tends to produce fragile results. Using AI with
clear objectives, context, and validation can significantly accelerate the journey.

The importance of idea validation

One of the strongest topics of the session was idea validation. Bruno reinforced that validating
an idea can be just as important as building the software — or even more important.

It makes no sense to invest time, energy, and money in a product that nobody wants to use or buy.
Before building everything, it is necessary to understand whether there is a real pain, whether
people are interested, and whether the proposed solution makes sense for those living that problem.

As an example, Bruno presented an idea for a tool to help people who are looking for jobs. The
inspiration came from observing that many candidates organize job openings, contacts, interviews,
and follow-ups in spreadsheets. He realized that this looked like a CRM, but applied to job hunting.

From that idea, he created a prototype with simple screens in HTML, CSS, and JavaScript, simulating
a flow to track job opportunities, interviews, tasks, learnings, and content related to the job
search process.

The most important step, however, was not the prototype itself. It was talking to people who were
actually looking for jobs, understanding how they organized themselves, looking at their spreadsheets,
and validating whether the tool would make sense in their routine.

Prototypes before products

The session reinforced the idea that prototypes are fundamental. Before building a complete application
with database, authentication, infrastructure, and complex rules, it is possible to create a wireframe
or a simple navigable version to test the idea.

Bruno showed that he started with static prototypes, generated with AI support, to visualize screens,
flows, and possibilities. This allowed him to talk to users and adjust the idea before moving into a
more robust application.

He also shared that not everything worked on the first attempt. Some attempts generated misaligned
screens, poorly defined flows, and results below expectations. This point is valuable because it shows
the reality of the process: using AI does not eliminate trial, error, and refinement.

The developer still needs to think, review, structure, explain better, and evolve the solution.
AI accelerates, but the process still requires method.

From wireframe to real application

One of the challenges presented was turning a wireframe into a real application. When an idea is clear
in the creator’s mind, it is not always clear to AI, to another developer, or even to the product itself.

Bruno commented that, when trying to transform screens into an application, he noticed gaps between
what was visually designed and what needed to be logically defined. Where does the data come from?
How is a task created? How does information change status? What is the real user flow?

These questions show that a product is not only interface. It is behavior, rules, flow, state, data,
and user experience.

Tools such as agent collections, specification-driven flows, and specialized prompts can help, but
they still depend on a good description of the problem and a clear mapping of the features.

MicroSaaS as a path for developers

Bruno also presented a microSaaS already in production: a tool created to help people choose a computer.

The idea came from a common situation for people who work in technology: friends, family members, or
acquaintances asking for help to buy a notebook or computer. Instead of answering manually every time,
Bruno transformed his knowledge into a product.

The application includes a sales page, payment gateway integration, email delivery, and access to the
platform. Behind the scenes, Java supports the solution.

This example showed a very interesting path for developers: identify knowledge you already have, find
a recurring pain, turn it into a simple tool, and validate whether someone would pay for the solution.

Publishing cheaply: the first step to putting something online

One of the most practical parts of the session was the demonstration of how to publish an application
on the internet using a simple and low-cost structure.

Bruno showed the use of Cloudflare Tunnel as an alternative to expose a local application
on the internet without starting by paying for servers from major cloud providers.

The idea presented was simple: buy a domain, configure it on Cloudflare, create a tunnel, run an
application on a local computer, and make that application available through HTTPS.

For those who are starting, this greatly reduces the entry barrier. Instead of starting by paying for
AWS, GCP, a VPS, Vercel, or other platforms, the developer can validate an idea with a more accessible
infrastructure.

This approach is not necessarily the final solution for a product at scale, but it can be excellent
for prototypes, early validation, labs, studies, and first user tests.

Infrastructure evolves together with the product

An important point raised during the conversation was that infrastructure should follow the product’s
maturity.

At the beginning, there may be no users. Then comes the first access. Then the first sale. Only then
does it make sense to start thinking about more availability, redundancy, professional hosting,
managed services, and more robust architecture.

The purpose of the approach presented is not to replace professional infrastructure forever, but to
allow the first step to happen without a high cost.

Validate first. Improve later. Put it online first. Scale later. Find someone willing to use or pay
first. Then invest more.

Authentication, OAuth2, and real learning

Bruno also showed how publishing applications this way creates space to study more advanced topics,
such as authentication with OAuth2.

Many authentication flows require HTTPS and public URLs for redirection. By exposing a local application
through a tunnel with HTTPS, the developer can test scenarios closer to reality, even without having a
complete cloud infrastructure.

This is valuable for learning. Instead of studying only theory, the developer can test login, tokens,
redirects, callbacks, containers, monitoring, and observability in their own environment.

This kind of home lab helps create practical experience and gives developers more confidence to deal
with real problems.

Less complexity, more pragmatism

The conversation also touched on infrastructure decisions. Bruno commented that, in a first attempt,
he used Kubernetes, but realized the solution was consuming too many resources for the problem he needed
to solve.

By simplifying the architecture, removing unnecessary layers, and running containers more directly,
he was able to reduce CPU and memory consumption.

This point is very important for those starting to create products. The most sophisticated technology
is not always the best choice for the moment. Sometimes, the simplest path delivers more value, costs less,
and allows evolution with more control.

Tools such as Ansible, containers, Podman, Docker, monitoring, and simple automations may be enough for
a first stage before moving to something more complex.

SaaS sells when it solves a problem

During the session, an important question came up: does SaaS sell?

The answer brought a direct reflection: it sells when it solves a real problem. People pay for solutions
when they perceive value, when they have a clear pain, and when the product makes something they already
need to do easier.

The biggest challenge is often not only building the software. It is making the product reach the right
people. It is creating an audience, communicating value, learning sales, testing channels, and understanding
how to present the solution to those who truly need it.

For developers, this is often an uncomfortable part because it requires leaving the code and getting closer
to users, the market, communication, and sales. But for those who want to create products, this step is
inevitable.

Community to build together

In the final part of the session, Bruno also presented the idea of a group called Utenx,
created to bring together people interested in building projects, products, and services on the internet.

The group’s proposal is to hold meetings, exchange experiences, discuss methodologies, tools, ideas,
validations, and practical challenges faced by those trying to create something.

This point connects directly with the spirit of SouJava: community as a space for learning, exchange,
and growth. Building alone can be difficult. Building in community makes the process lighter, richer,
and more collaborative.

Developers and non-technical people can create products

An interesting point in the conversation was the openness to non-technical people. Bruno commented that
people who do not program can also have good chances of creating products, because they often know real
problems better than developers do.

Developers know how to build, but they are not always close to the pains of end users. People from other
areas can bring worldview, concrete problems, daily experiences, and opportunities that those living only
inside code may not see.

The combination of problem vision and technical capability can generate much more relevant products.

Final thoughts

SouJava Sessions #005 brought an extremely practical conversation about digital product creation,
microSaaS, idea validation, and application deployment.

Bruno Rozendo showed that, with today’s tools, the barrier to start is lower. AI can help prototype,
generate screens, test ideas, and accelerate development. Cloudflare Tunnel and local infrastructure
can help publish cheaply. Containers, automation, and observability can turn a lab into a real learning
environment.

But the main message of the session went beyond technology: start small, validate quickly, talk to users,
solve real problems, and do not wait for the perfect architecture to take the first step.

For Java developers, this vision opens an important opportunity. Technical knowledge can become a product,
service, tool, microSaaS, or solution to a specific pain. The path does not begin with perfection. It begins
with an idea, validation, and willingness to build.

SouJava Brasília continues as a living movement: where knowledge, technology, and community come
together to shape better professionals and build more relevant solutions.