I've been quieter on CoderLegion for a little while.
Not because I ran out of things to write about. Quite the opposite.
I've been spending a lot of time building Dulvarn, and one thing I've been learning as a solo founder is that a surprising amount of product work doesn't look like product work from the outside.
You can spend days working on infrastructure, CI, security, project rules, or deployment processes and have very little new UI to show for it.
It's still important work.
But it also raises a difficult question:
How much time should you spend making the foundations better before you get back to building what users actually see?
I'm still learning how to answer that.
The part of SaaS building that doesn't make a good screenshot
When people imagine building a SaaS, they often picture the visible parts.
A landing page. A dashboard. A new feature. A product demo. A first customer.
Those are the exciting milestones.
But behind them there is another layer of work.
Development environments. CI pipelines. Infrastructure. Secrets. Deployment configuration. Database migrations. Monitoring. Security. Documentation. Rules for how the codebase is maintained.
None of those automatically creates customer value on its own.
But when they're missing or unreliable, they can make every future change slower and riskier.
Recently, a lot of my attention has been on that less visible layer of Dulvarn.
Why I started taking the internal setup more seriously
Dulvarn is not a single small application anymore.
There is a backend, a web application, supporting tools, and AI-related components. They need to work together, and changes in one part can affect another.
As a solo founder, I don't have separate teams looking after infrastructure, backend, frontend, QA, and operations.
I have to make decisions across all of them.
That creates a temptation to solve problems quickly and move on.
A configuration works locally? Fine.
A pipeline passes? Great.
A deployment succeeds? Move to the next task.
But over time, small inconsistencies accumulate.
Different environments. Different assumptions. Different project rules. Different ways of running quality checks.
Eventually, the cost of those inconsistencies starts showing up in every new piece of work.
That's when I started treating the internal development setup as part of the product's foundations rather than just something I needed to get out of the way.
CI is not just about getting a green check
One of the recent areas I've been working on is how CI workloads are executed.
I've been moving selected trusted quality and deployment-validation jobs onto internal runners while keeping a separation for pull-request execution where appropriate.
The interesting part wasn't simply changing where a job runs.
It was thinking about what should run where, what the trust boundary is, and how to keep the workflow maintainable.
A self-hosted runner can give you more control over resources and execution, but it also gives you responsibility for the machine, its security, its availability, and its maintenance.
That's the trade-off.
You don't get operational control for free.
And this is exactly the kind of decision that is easy to underestimate when you're focused on shipping features.
Rules become important when you're no longer working in one repository
Another area I've been working on is consistency across the codebase.
When you have several repositories and AI-assisted development workflows, it's surprisingly easy for different parts of the system to drift toward different assumptions.
One repository follows one convention. Another has an older rule. A tool makes a change that is locally reasonable but doesn't fit the wider architecture.
So I've been working on shared governance and project rules, including a newer version of the agent governance model that is inherited across the main repositories.
That may sound like internal process work, and it is.
But the goal is practical: make it easier to understand which rules are authoritative, which decisions belong to which components, and how changes should be reviewed.
I don't want every new task to require rediscovering the architecture.
At the same time, I'm learning that governance can become its own form of complexity if you're not careful.
The goal isn't to create more documents.
It's to reduce ambiguity.
The danger of enjoying the infrastructure too much
This is probably the most uncomfortable lesson for me.
I genuinely enjoy building systems.
I like understanding how the pieces fit together. I like improving development workflows. I like making infrastructure more reliable.
And because I enjoy it, it's easy to spend more time there than I originally intended.
There is always another improvement available.
Another configuration to clean up.
Another workflow to standardize.
Another tool to integrate.
Another architectural decision to revisit.
Some of that work is necessary.
Some of it is probably just interesting engineering.
As a solo founder, I have to learn the difference.
Because a better internal system is not the same thing as a better business.
The product still has to reach users
Dulvarn is a release intelligence and decision platform.
The core problem I'm working on is how teams can turn fragmented engineering, QA, security, change, and operational signals into an explainable release decision.
That is the reason the product exists.
Not because I wanted to build a complicated infrastructure setup.
Not because I wanted to collect as many technologies as possible.
Not because I wanted to create a perfect internal engineering environment.
The infrastructure is there to support the product.
The product is there to solve a problem.
And the problem has to matter to real users.
That's the part I need to keep returning to.
What I'm trying to do differently
I'm becoming more deliberate about separating foundational work from product work.
When something is genuinely blocking development or creating unacceptable risk, it needs attention.
But once the blocker is removed, I need to resist the urge to keep polishing the foundation indefinitely.
The next question should be:
What is the smallest useful product step I can take now?
That might be improving onboarding.
It might be making the release decision easier to understand.
It might be simplifying a workflow.
It might be preparing a demo.
Or it might be talking to someone who has the problem Dulvarn is supposed to solve.
Those steps can be less satisfying than solving a difficult technical problem.
But they're necessary if the goal is to build a product rather than just a technically interesting system.
Building while working full-time makes prioritization unavoidable
I'm building Dulvarn alongside a full-time job.
That means I can't treat every task as equally important.
Time and energy are limited.
If I spend an evening improving infrastructure, that's an evening I didn't spend on onboarding, customer discovery, documentation, or marketing.
Sometimes that's the right decision.
Sometimes it isn't.
And I don't think there's a perfect formula for it.
I'm trying to get better at asking what a task actually unlocks.
Does it remove a blocker?
Does it reduce a meaningful risk?
Does it improve the experience of a potential user?
Does it help me learn whether the product solves a real problem?
Or am I doing it because it's interesting and I know how to do it?
That last question is often the hardest one.
I want to share the work that doesn't look impressive
One of the reasons I started this series was to share the real process of building a SaaS, not just the polished milestones.
That includes the weeks when the visible product doesn't change much.
The architecture decisions.
The infrastructure work.
The mistakes.
The features I decide not to build.
The moments when I realize I've spent too much time on something.
And the process of getting back to the actual product.
I think those parts are worth sharing because they're part of what building a SaaS really looks like.
Especially when you're doing it as a solo founder.
What comes next
My focus is to keep moving Dulvarn toward a product experience that is useful and understandable for real teams.
That means continuing the work around onboarding, release workflows, evidence, and the way users understand release decisions.
It also means getting back to conversations with potential users and learning which parts of the problem are painful enough that teams would actually want help solving them.
I don't want to pretend that every feature is finished or that every part of the roadmap is equally mature.
There is still work to do.
And I'd rather share that honestly than turn the journey into a series of perfect progress updates.
Building a SaaS is teaching me that progress isn't always visible.
Sometimes progress is a new feature.
Sometimes it's removing a blocker.
Sometimes it's making a difficult architectural decision.
And sometimes it's realizing that the next thing you need to build isn't more infrastructure.
It's a better way for someone to understand and use the product.
The challenge is knowing which kind of progress matters most right now.
This is the second article in my How I’m Building a SaaS series.
If you're building your own product, how do you decide when the foundations are good enough and it's time to get back to features, users, and validation?