What I Actually Do When I Say I'm “Working on My SaaS”

Spoiler: It's not just coding. When I say “I'm working on my SaaS,” people usually imagine me coding all day, deep in terminal tabs, launching features like a machine. But the truth is, code is maybe half of it. The other half? Talking to users, writing, fixing things, overthinking copy, dealing with bugs, and just trying to stay sane. Here's what “working on my SaaS” really looks like. 1. Reading Feedback. Again. Before writing any code, I check my feedback board. This is where everything starts. What's broken? What's unclear? What's being asked for again? I built UserJot to organize feedback not just for my users, but for myself too. A place to actually think through what's being said — not just dump it into a spreadsheet and forget about it. Sometimes a single post makes me rethink a feature. Sometimes it reminds me that people actually care. 2. Splitting Time: 50% Dev, 50% Marketing This one took a while to learn the hard way: If I spend 100% of my time building and 0% of my time telling people about it, nothing happens. So these days, I try to keep a rough 50/50 split: First half of the week: build, fix, ship Second half of the week: write, promote, reply, engage, repeat It's not exact. Some weeks I go full dev mode. Some days are all marketing. But overall, I try to give equal weight to both. Because writing a feature is only half the work. Getting someone to care about it — that's the real job. 3. Spending 2 Hours a Day on Support Support isn't a chore. It's product research. Every bug report, every “hey this doesn't work,” every “how do I even…” — it's a direct line to the friction users feel but don't always articulate. So I spend about 1–2 hours a day just on support. Sometimes that means answering emails. Sometimes that means fixing something small on the spot. Sometimes it's helping someone onboard and seeing where they get stuck. If multiple people are asking the same thing on UserJot, that's usually the next item on my roadmap. Support gives me clarity. It tells me what's real — and what's just in my head. 4. Debating Features With… Myself You'd think being a solo founder would mean fast decisions. Sometimes it does. But more often than not, I just end up arguing with myself for days. Should I build this now or wait? Is this useful or just cool? Will this help users — or confuse them more? Half the job is learning what not to ship. 5. Marketing (aka Talking to the Void) A lot of my day is marketing — but not in the traditional sense. It's not ads or cold outreach. It's mostly: Sharing what I'm building Writing blog posts like this Answering questions on Reddit, Twitter, Discord Figuring out what actually resonates Sometimes I'll rewrite a single headline 12 times. Sometimes I'll make a dumb meme that accidentally drives more traffic than a full blog post. Marketing isn't a switch you flip. It's a habit you build. 6. Fixing Bugs I Swore I Already Fixed No matter how good I feel after shipping, there's always something. Usually found by a user using a device I forgot existed. Then it's: Dig through logs Try to reproduce it Realize I only fixed part of the issue last time Actually fix it this time (maybe) Debugging is like archaeology. You're digging through layers of past decisions. 7. Doubting Everything Some days I feel like I'm onto something. Other days I wonder if I should've just made a newsletter or something. The hard part of building alone isn't the tech — it's managing your own brain. Am I wasting my time? Should I be growing faster? Is this even good? Doubt is part of the process. It means you care. I've just learned not to make decisions on low days. Ship something small. Talk to a user. Keep going. 8. Shipping Anyway Even when I don't feel like it. Even when it's not perfect. Even when no one is watching. Because this is how products get built: One tiny ship at a time. TL;DR What I actually do when I say I'm working on my SaaS: Read feedback Talk to users Fix bugs Market quietly Support daily Ship consistently Doubt often Keep going anyway If this is something that you're interested in, I highly suggest you go and start building something and figure it out as you go. It's one of the most rewarding things you can do and you will learn a ton during the process. In case you're more interested in what I'm building, you can find more about it here. I'd love to hear what you think!

Apr 13, 2025 - 20:30

What I Actually Do When I Say I'm “Working on My SaaS”

Spoiler: It's not just coding.

When I say “I'm working on my SaaS,” people usually imagine me coding all day, deep in terminal tabs, launching features like a machine.

But the truth is, code is maybe half of it. The other half? Talking to users, writing, fixing things, overthinking copy, dealing with bugs, and just trying to stay sane.

Here's what “working on my SaaS” really looks like.

1. Reading Feedback. Again.

Before writing any code, I check my feedback board.

This is where everything starts.

What's broken? What's unclear? What's being asked for again?

I built UserJot to organize feedback not just for my users, but for myself too. A place to actually think through what's being said — not just dump it into a spreadsheet and forget about it.

Sometimes a single post makes me rethink a feature.

Sometimes it reminds me that people actually care.

2. Splitting Time: 50% Dev, 50% Marketing

This one took a while to learn the hard way:

If I spend 100% of my time building and 0% of my time telling people about it, nothing happens.

So these days, I try to keep a rough 50/50 split:

First half of the week: build, fix, ship
Second half of the week: write, promote, reply, engage, repeat

It's not exact. Some weeks I go full dev mode. Some days are all marketing.

But overall, I try to give equal weight to both.

Because writing a feature is only half the work.

Getting someone to care about it — that's the real job.

3. Spending 2 Hours a Day on Support

Support isn't a chore.

It's product research.

Every bug report, every “hey this doesn't work,” every “how do I even…” — it's a direct line to the friction users feel but don't always articulate.

So I spend about 1–2 hours a day just on support.

Sometimes that means answering emails.

Sometimes that means fixing something small on the spot.

Sometimes it's helping someone onboard and seeing where they get stuck.

If multiple people are asking the same thing on UserJot, that's usually the next item on my roadmap.

Support gives me clarity.

It tells me what's real — and what's just in my head.

4. Debating Features With… Myself

You'd think being a solo founder would mean fast decisions.

Sometimes it does. But more often than not, I just end up arguing with myself for days.

Should I build this now or wait?
Is this useful or just cool?
Will this help users — or confuse them more?

Half the job is learning what not to ship.

5. Marketing (aka Talking to the Void)

A lot of my day is marketing — but not in the traditional sense.

It's not ads or cold outreach. It's mostly:

Sharing what I'm building
Writing blog posts like this
Answering questions on Reddit, Twitter, Discord
Figuring out what actually resonates

Sometimes I'll rewrite a single headline 12 times.

Sometimes I'll make a dumb meme that accidentally drives more traffic than a full blog post.

Marketing isn't a switch you flip. It's a habit you build.

6. Fixing Bugs I Swore I Already Fixed

No matter how good I feel after shipping, there's always something.

Usually found by a user using a device I forgot existed.

Then it's:

Dig through logs
Try to reproduce it
Realize I only fixed part of the issue last time
Actually fix it this time (maybe)

Debugging is like archaeology. You're digging through layers of past decisions.

7. Doubting Everything

Some days I feel like I'm onto something.

Other days I wonder if I should've just made a newsletter or something.

The hard part of building alone isn't the tech — it's managing your own brain.

Am I wasting my time?
Should I be growing faster?
Is this even good?

Doubt is part of the process.

It means you care.

I've just learned not to make decisions on low days.

Ship something small. Talk to a user. Keep going.

8. Shipping Anyway

Even when I don't feel like it.

Even when it's not perfect.

Even when no one is watching.

Because this is how products get built:

One tiny ship at a time.

TL;DR

What I actually do when I say I'm working on my SaaS:

Read feedback
Talk to users
Fix bugs
Market quietly
Support daily
Ship consistently
Doubt often
Keep going anyway

If this is something that you're interested in, I highly suggest you go and start building something and figure it out as you go. It's one of the most rewarding things you can do and you will learn a ton during the process.

In case you're more interested in what I'm building, you can find more about it here. I'd love to hear what you think!