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.
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.
What I want to share in this series
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.
