Coder Legion - Recent posts tagged building

How a QA Problem Turned Into the SaaS I’m Building

Sat, 29 Aug 2026 14:19:38 +0000

I didn’t start building Dulvarn because I wanted to become a SaaS founder.

At least, not at first.

I started with a problem I kept seeing again and again in software delivery.

A team could have:

green CI
passing tests
successful builds
approved pull requests
deployment steps ready

And still, one question remained difficult to answer clearly:

Are we actually ready to release?

That question stayed with me.

Because in theory, software teams already have many signals.

CI tells us something.

Automated tests tell us something.

QA tells us something.

Security tools tell us something.

Pull requests tell us something.

Monitoring tells us something.

But those signals are often scattered across different tools, dashboards, tickets, reports, and conversations.

And when it is time to make the final release decision, the answer is not always as clear as the pipeline color suggests.

That gap is where Dulvarn started.

Green does not always mean confident

One of the ideas I kept coming back to was simple:

A green pipeline tells you that the checks you defined passed.

That is valuable.

But it does not automatically tell you that the release risk is low.

For example:

Build                     PASS
Automated tests           PASS
Security scan             PASS

Database migration        YES
Authentication change     YES
Rollback confidence       MEDIUM
Observability coverage    PARTIAL
QA coverage               LIMITED

Nothing here is necessarily red.

But it also does not feel like a release decision that should be made blindly.

The build passed.

The tests passed.

The scan passed.

But the release still deserves thought.

What changed?

How risky is the change?

Can we roll it back?

Do we have enough visibility after deployment?

Do we understand the weakest part of the release?

That difference between technical validation and release confidence became more interesting to me over time.

And once I noticed it, I started seeing it everywhere.

QA taught me to ask uncomfortable questions

Working in QA changes the way you look at software.

You naturally start asking:

What could fail?
What was not covered?
What assumption are we making?
What happens if the user does something unexpected?
What changed between environments?
What evidence do we actually have?

At first, those questions were mostly about features.

Does login work?

Can the user complete checkout?

Does validation behave correctly?

Does the API return the expected response?

But as I moved deeper into automation, CI/CD, DevOps, observability, and release engineering, the questions became broader.

I started asking:

What happens if the deployment succeeds, but the system becomes unhealthy?

What if the tests pass, but rollback is unclear?

What if the release includes a risky migration?

What if different teams each have part of the evidence, but nobody has the whole picture?

At that point, the problem was no longer only testing.

It was release decision-making.

Release readiness is often spread across too many places

In many teams, release evidence is not missing.

It is fragmented.

One signal lives in CI.

Another lives in test reports.

Security findings live somewhere else.

Deployment status is in another system.

Approvals may be in a ticket.

Important context may be in Slack.

Risk may be understood by one engineer, but not written down anywhere.

And then someone has to decide whether the release should go out.

That decision can become strangely informal compared to everything that came before it.

Code review is structured.

CI is structured.

Testing is structured.

Deployment is often structured.

But the release decision itself can still depend on scattered context and human memory.

That bothered me.

Not because people were careless.

But because the tools around them were usually optimized for execution.

Build.

Test.

Deploy.

They were less focused on the decision between those steps.

Dulvarn started as a release control idea

The idea behind Dulvarn came from that gap.

I wanted to explore a simple question:

What if release decisions were based on collected evidence instead of scattered signals and assumptions?

Not to replace CI.

Not to replace QA.

Not to replace DevOps.

And definitely not to replace people.

The point is not to make software delivery fully automatic and hope for the best.

The point is to make release risk more visible.

Something like:

CI
QA
Security
Change Context
Deployment Readiness
Operational Signals
Approvals
        ↓
Release Evidence
        ↓
Risk Context
        ↓
GO / CONDITIONAL GO / NO-GO

The label matters less than the explanation behind it.

A good release decision should not only say:

GO

It should also explain why.

And if the answer is:

CONDITIONAL GO

Then the team should understand the condition.

And if the answer is:

NO-GO

Then the reason should be clear enough to act on.

That is the direction I started building toward.

I am not trying to build another giant platform

One thing I care about is keeping the core idea clear.

Software teams already have enough tools.

They do not need another huge platform that tries to replace everything they use.

The interesting part is the layer between existing systems.

Collect the signals.

Understand the context.

Evaluate the risk.

Make the decision visible.

Keep the evidence.

That is the part I keep coming back to.

Dulvarn is not meant to be a magical AI system that takes control away from teams.

It is meant to support human-controlled release decisions.

The software can help organize evidence.

It can highlight risk.

It can make patterns easier to see.

It can preserve decision history.

But the responsibility still belongs with people.

That matters to me.

Especially because release decisions are not only technical.

They involve judgment.

Building the idea was easier than defining the product

This was one of the first lessons I learned.

Writing code is only one part of building a SaaS.

You also need to answer questions like:

Who exactly is this for?
Which problem is painful enough to solve?
What belongs in the MVP?
What should not be built yet?
How should onboarding work?
What should users see first?
What should remain manual?
What should be automated?
What is useful now, and what is just interesting?

Those questions are often harder than building another endpoint or UI component.

And they do not have clean pass/fail answers.

As a QA engineer, I was used to looking for defects.

As a product builder, I had to start looking for unnecessary complexity too.

That is a different skill.

And I am still learning it.

The temptation to build too much is real

When you build your own product, every idea feels useful.

Add another integration.

Add another dashboard.

Add another AI feature.

Add another report.

Add another workflow.

Add more settings.

Add more intelligence.

The product can become impressive very quickly.

It can also become impossible to understand.

I had to learn that a technically strong feature is not automatically a product priority.

Sometimes the better decision is:

Not yet.

That is surprisingly difficult when you are the person imagining the system and building it at the same time.

Because you can see the future version in your head.

But users do not start with the future version.

They start with the first useful version.

And that version has to be clear.

Building while working full-time changes everything

There is another reality behind Dulvarn.

I am building it while working a full-time job.

That means time matters.

Energy matters.

Focus matters.

You cannot treat every idea like an emergency.

You cannot spend weeks polishing something nobody has asked for.

You cannot rebuild the architecture every time a more elegant solution appears.

At least, not if you want to ship something.

This has forced me to think much more seriously about priorities.

What moves the product forward?

What creates evidence that the idea is useful?

What helps me get closer to real users?

What is just interesting engineering?

Those are different things.

And as a technical founder, it is very easy to confuse them.

Building Dulvarn changed the way I think about QA

Interestingly, building a SaaS has also made me think differently about QA.

When you own the whole product, quality becomes much bigger than testing.

A confusing onboarding step matters.

A broken deployment matters.

A slow page matters.

A missing error message matters.

Security matters.

Observability matters.

Documentation matters.

Support experience matters.

Pricing clarity matters.

The product is not only the code.

The product is the whole experience around the code.

That perspective feeds back into how I think about software quality in general.

Quality does not start when testing begins.

And it does not end when QA says passed.

It exists across the full lifecycle of the product.

This is still early

Dulvarn is not a finished story.

It is still early.

There are things I will probably change.

Features I will remove.

Assumptions I will test.

Positioning I will sharpen.

Workflows I will simplify.

Technical decisions I will rethink.

That is part of the process.

I do not want to write this series as if I already have everything figured out.

I do not.

I am building, learning, cutting scope, testing ideas, and trying to turn a real QA and release engineering problem into something useful.

That is exactly why I want to document it.

Not as a perfect founder story.

More as a record of what I am learning while building.

In this series, I want to write about the real process behind building Dulvarn.

Things like:

how I decide what belongs in the MVP
how I think about release risk
what I learn from user feedback
how I approach onboarding
how I avoid building too much
how I think about pricing
how I balance AI with human control
how I work on infrastructure
how I manage product decisions while working full-time
what I build and later remove

Not as a tutorial for building the perfect SaaS.

I definitely do not have that.

More as a practical founder log from someone trying to build a product from a problem he understands deeply.

Dulvarn did not start because I wanted to become a SaaS founder.

It started because QA kept leading me toward bigger questions.

Testing led to automation.

Automation led to CI/CD.

CI/CD led to DevOps.

DevOps led to release engineering.

And release engineering led to one question I could not stop thinking about:

If all our systems produce signals, who actually turns those signals into a release decision?

I am still working on the answer.

And I am building a product around it.

This is the first article in my How I’m Building a SaaS series.

In the next article, I want to write about one of the hardest lessons so far:

how to decide what not to build.

Why Building Projects Beats Watching Tutorials

Mon, 01 Jun 2026 13:52:04 +0000

The internet has made learning to code more accessible than ever. With thousands of free and paid tutorials available on platforms like YouTube, Udemy, and coding blogs, aspiring developers can learn almost any programming language or framework from the comfort of their homes. While tutorials are valuable learning resources, relying on them alone can limit your growth as a developer. If your goal is to become a skilled programmer, building real projects is far more effective than endlessly consuming tutorials.

The Tutorial Trap

Many beginners fall into what developers often call "tutorial hell." This happens when someone spends countless hours watching coding videos, following step-by-step guides, and completing example projects without ever creating something independently.

Tutorials provide a sense of progress because you're constantly learning new concepts. However, the learning process is often passive. You follow instructions, copy code, and see immediate results, which creates the illusion that you've mastered the material. The problem appears when you try to build something on your own and realize you don't know where to start.

Watching tutorials can teach concepts, but it rarely develops the problem-solving skills required in real-world development.

Projects Force You to Think

When building a project, there is no instructor telling you exactly what to do next. You must decide how to structure your code, which technologies to use, and how to solve unexpected problems.

This process develops critical thinking and problem-solving abilities that tutorials cannot fully provide.

For example, a tutorial might show you how to build a simple weather application. But when you decide to create your own version, you may encounter issues with API integration, user authentication, responsive design, or data storage. Solving these challenges helps you understand programming at a deeper level.

The struggle itself becomes part of the learning experience.

Real Learning Happens Through Practice

Programming is a practical skill, much like learning a musical instrument or playing a sport. You cannot become an expert guitarist simply by watching guitar lessons. Eventually, you must pick up the instrument and practice.

Coding works the same way.

The more projects you build, the more comfortable you become with writing code, debugging errors, and understanding how different technologies work together. Concepts that once seemed confusing begin to make sense because you have applied them in real situations.

Practice transforms theoretical knowledge into practical expertise.

Projects Build Confidence

One of the biggest benefits of creating projects is the confidence it generates. Completing a project proves that you can take an idea and turn it into a working solution.

Every finished project becomes evidence of your abilities. Even small projects such as calculators, task managers, or portfolio websites can significantly boost your confidence as a developer.

As your skills grow, you can tackle increasingly complex projects and challenge yourself with new technologies and programming concepts.

Confidence is not built by watching others code—it is built by writing code yourself.

Employers Care About What You Can Build

When applying for internships or software development jobs, employers are often more interested in your projects than the tutorials you have completed.

A portfolio filled with original projects demonstrates initiative, creativity, and technical ability. It shows that you can apply your knowledge to solve real problems rather than simply follow instructions.

Projects provide tangible examples that you can discuss during interviews. Recruiters and hiring managers often ask candidates to explain the challenges they faced and how they solved them. Having real projects gives you meaningful experiences to share.

In many cases, a strong project portfolio can outweigh formal credentials or certificates.

Projects Reveal Knowledge Gaps

Another advantage of building projects is that they expose weaknesses in your understanding.

While following a tutorial, you may feel comfortable because someone else has already solved the difficult parts. However, when creating your own application, you quickly discover areas where your knowledge is incomplete.

Perhaps you struggle with database design, API development, authentication systems, or deployment processes. Identifying these gaps allows you to focus your learning efforts more effectively.

Instead of randomly consuming content, you learn exactly what you need to solve a specific problem.

Tutorials Still Have Value

This does not mean tutorials are useless. Tutorials are excellent for introducing new concepts, learning unfamiliar technologies, and understanding best practices.

The key is to use tutorials as a starting point rather than the final destination.

A productive approach is to watch a tutorial, learn the basics, and then immediately build something different using the same concepts. Add new features, redesign the interface, or combine multiple technologies into a unique project.

This method reinforces learning while encouraging independent thinking.

Start Small and Keep Building

Many beginners hesitate to start projects because they believe they need an advanced idea. In reality, simple projects are often the best learning tools.

Start with manageable applications such as:

To-do lists
Calculator apps
Weather dashboards
Personal portfolios
Expense trackers
Blog platforms
Habit trackers

Each project teaches valuable skills while preparing you for larger and more ambitious applications in the future.

The goal is not perfection. The goal is consistent practice and continuous improvement.

Conclusion

Tutorials can help you learn programming concepts, but projects are where true growth happens. Building projects strengthens problem-solving abilities, develops practical skills, increases confidence, and creates a portfolio that demonstrates your capabilities to employers.

If you want to become a better developer, spend less time passively consuming content and more time creating. Watch tutorials when necessary, but make building your primary learning strategy.

The fastest way to learn programming is not by watching someone else write code—it is by writing code yourself.