Forem: Christoffer Madsen

Working 30% on a 100% Job: What I Learned as a Solo Developer

Christoffer Madsen — Tue, 25 Nov 2025 13:31:18 +0000

There’s something I wish more employers understood — something I didn’t fully have the words for until I lived through it myself:

when a developer says the work requires a full-time position, they’re not exaggerating. They’re telling you what it actually takes to build the thing you’re asking for.

I learned that lesson from the inside, as the developer whose role didn’t match the expectations placed on it.

Stepping into a system built on shaky ground

A while back, I joined a small Norwegian company as their only developer. They handled services related to cemeteries and memorials, and they had a system that had grown organically over the years. The database was… let’s say “creatively structured,” and every architectural decision seemed to lean in a different direction.

I wanted to do good work, so I began the slow process of rebuilding, refactoring, and trying to bring some order to the chaos.

But I was hired at just 30% employment.

That number quickly became its own kind of constraint. Every task required more context-switching. Every bug meant reacquainting myself with parts of the system I hadn’t touched in weeks. Things that should have been straightforward became long, fragmented stretches of work that never quite fit together cleanly.

Expectations that didn’t match reality

Despite the part-time contract, the expectations were… not part-time.

There was a steady stream of pressure to move faster, fix more, deliver more. “Why isn’t this ready yet?” became a familiar question. I explained — more than once — that the work required more hours. That rebuilding a shaky system isn’t something you can do in small bursts. That software needs focus, not fragmented leftovers.

I was told repeatedly that my position would be increased. “Soon,” or “next month,” or “once a few things settle internally.”

But those promises never became reality.

The quiet feeling of being set up to fail

Looking back now, I can see the imbalance more clearly. They wanted stability built on top of a foundation that needed replacing. They wanted polish when I barely had time to sketch prototypes. They wanted full-time output while keeping me in a part-time role.

At the time, I pushed through because I cared. When you’re the only developer, you carry the work in your mind even when you’re not being paid for it. You want the system to succeed, even when the conditions make that nearly impossible.

And then things fell apart

Eventually, progress slowed — not because of lack of willingness, but because there were simply not enough hours to solve the problems in front of me. The system wasn’t where they wanted it to be. It had bugs. It needed more refinement.

All of that was true.

But the missing piece was the time I never received.

In the end, I was let go — just three days before my parental leave.
It took a while for the silence of that moment to settle.

What I took with me

I’m not sharing this to blame or to vent. I’m sharing it because I know other developers end up in similar situations:
the lone engineer carrying an entire product, expected to deliver more than the hours, support, or structure will ever realistically allow.

If there’s one thing this experience taught me, it’s this:

When a developer tells you the work requires a full-time position, listen.
They’re not asking for more hours for themselves — they’re asking for enough space to build something stable, reliable, and meaningful.

I’ve carried that lesson with me into every role since.
And if it helps even one other developer recognize the signs earlier than I did, then the experience becomes something I can look back on with a little more clarity — and a lot more purpose.

The Quiet Threat of AI “Undress” Apps

Christoffer Madsen — Mon, 24 Nov 2025 11:21:54 +0000

Why the tech matters far less than the harm

AI tools that supposedly “remove clothes” from photos aren’t new, but their leap into the mainstream signals something more troubling than a technical novelty. What used to live on the fringes—crude, hidden, and hard to access—is now polished, widespread, and nearly impossible to contain in an open-source world. But focusing on the tools themselves misses the point. The problem isn’t the AI. It’s what this trend reveals about consent, power, and the normalization of digital violations.

This is a human problem wearing a technological mask.

A Violation Without Physical Contact

Non-consensual sexual imagery has always been a form of harm. AI doesn’t change that—it expands it. These apps fabricate what they show, yet the emotional shock, shame, and reputational damage often mirror the impact of actual voyeurism.

For victims, whether the image is “real” is irrelevant.
Being unwillingly sexualized is still a violation.

And that’s precisely why this technology is corrosive. It makes a harmful act effortless. No skill, no risk, no access to private photos—just a single image and a few seconds of processing.

Consent Doesn’t Scale. Technology Does.

Consent is contextual and inherently human. It doesn’t scale. But AI does. Frictionlessly.

A single everyday photo—your LinkedIn picture, a selfie, a family snapshot—can be turned into something sexualized and permanent. What used to be ordinary digital presence is now ammunition.

And as always, the groups most targeted offline—women, minors, LGBTQ individuals, people of color, and anyone marginalized—face the greatest risk online.

The Social Fallout We Aren’t Ready For

Policymakers are busy debating the boundaries of AI innovation, but these apps expose an older fracture in our culture:

1. Non-consensual behavior becomes normalized.
When creating sexualized images becomes trivial, expectations of privacy erode with it.

2. Visual truth becomes unreliable.
If fabrication is cheap, weaponizing it becomes easy. Blackmail, defamation, and “proof” lose meaning.

3. The psychological toll is real.
Even knowing an image is fake doesn’t erase the humiliation or fear.

4. Public complacency grows.
Frequent exposure—headlines, memes, viral demos—makes us treat violations as spectacle rather than harm.

The Tech Isn’t the Problem—We Are

It’s tempting to call this an AI ethics issue, but that softens the responsibility. AI didn’t invent exploitation; it lowered the bar for it. The real issue is the willingness of people to cross boundaries they would never cross face-to-face.

Technology doesn’t reshape our values so much as it reveals them.

The popularity of these tools shows that a significant number of people are comfortable violating someone’s digital autonomy—and once those boundaries crumble online, the physical world isn’t far behind.

What Needs to Change

No single solution will fix this, but several shifts can make a difference:

Clear laws that treat synthetic sexual content of real individuals as a violation—no matter how “fake” it is.
Cultural norms that regard using someone’s image without consent as abuse, not entertainment.
Better education on consent as an ongoing, specific agreement—not a permission slip for image manipulation.
Platforms with real accountability and fast, decisive takedown processes.

But most crucially, we need a collective understanding that digital boundaries matter just as much as physical ones.

The Bigger Question

AI didn’t create the impulse to sexualize someone without their consent; it simply removed the difficulty. What we’re confronting isn’t a technological leap but an ethical one.

The real question isn’t how these tools work.
It’s what their popularity reveals about us—and whether we’re willing to push back against a culture that treats a person’s image as public property rather than part of their identity.

The Tool I Finally Built to Escape My Terminal Chaos

Christoffer Madsen — Wed, 19 Nov 2025 23:05:20 +0000

There was a stretch of days where my terminal tabs felt like they were slowly multiplying behind my back.

I’d open a new project “just to try something,” hop into a client repo to fix a bug, jump into another folder because I remembered I needed to update something “real quick,” then spin up yet another experimental idea at 1 a.m. before bed. Suddenly I had four different terminals open, each running something important, each shouting logs at me, and absolutely no memory of which script belonged to which project.

And honestly?
I love creating projects.
That’s half the reason my workflow got so chaotic in the first place.

But eventually I realized a pattern:
I wasn’t spending time coding — I was spending time managing coding.

I wanted one place, a calm little command center, where I could see all my projects, what scripts they had, what was running, what wasn’t, and what was broken. No more guessing. No more hunting. No more “oh cool, I’m on the wrong branch again.”

So I built the tool I always wished I had — one place to manage all my local projects without drowning in terminals.

Why I Built Localhost Hub

At first it started with a simple frustration:
I was tired of typing npm run dev in the wrong directory.

Then it was the constant flipping between terminals.
Then it was forgetting which ports were in use.
Then it was accidentally installing dependencies in the wrong folder.
Then it was juggling frontend and backend manually every morning like some weird ritual.

And eventually I hit that moment every developer recognizes:

“Okay… this is dumb. I should automate this.”

That’s where Localhost Hub began — not as a product idea, but as the tool I needed to stay sane.

What I Wanted From It (and Why)

Here’s how the app works, but explained in the way it grew out of my own annoyances:

1. “Just scan my projects, please.”

My Projects folder is basically a nesting doll of ideas, experiments, client work, half-built things, and “I’ll come back to this someday” repos.

So I built directory scanning — point the app at a folder and it finds every package.json inside it.

No more babysitting directories.

2. “Let me run scripts without thinking about them.”

If a project has scripts, Localhost Hub lists them with start/stop buttons.

That’s it. No remembering names. No mistyping. No wondering if something is still running in a ghost terminal.

3. “If I’m starting the frontend, I probably want the backend too.”

My daily routine used to be:

cd frontend
npm run dev
cd ../backend
npm run dev
oh wait, wrong backend, cd ../backend-api
npm run dev

You get the idea.

So I added Workspaces — a way to bundle scripts across multiple projects and launch them together in one click.

4. “Please just tell me what’s broken.”

Sometimes I’d run a project and it would explode immediately because I forgot to:

install dependencies
pull changes
switch branches
or clean up something messy

So Localhost Hub shows small, quiet cues:
git status, package checks, expected ports, detected URLs.

Nothing fancy — just enough so I don’t get blindsided.

5. “Let me stay in the same mental space.”

Flipping between terminals, editors, and logs adds friction.
So inside Localhost Hub each project gets a simple dashboard:

scripts
real-time logs
packages
ports/processes
git cleanliness

All in one view, all in one place.

Not groundbreaking.
Just less mental context-switching.

What Surprised Me

The first time I used the app on my own messy setup, I didn’t expect the feeling of… calm.

It wasn’t about speed.
It wasn’t about convenience.
It was about clarity — not having dev environments scattered across terminal tabs and nested folders.

I had built something that let me focus again.

And that’s when I realized:
Sometimes the best tools aren’t the ones with the most features — they’re the ones that remove friction you’ve been carrying around for years.

Closing Thoughts

If you’re the kind of developer who loves starting new projects, or bounces between multiple repos daily, or constantly loses track of what’s running where… you might know exactly the pain that led me to build this.

Localhost Hub wasn’t meant to be “the next big dev tool.”
It was meant to be a tool that makes my own messy, creative workflow feel more manageable — and maybe it’ll resonate with someone else too.

If you’ve built something similar, or have your own hacks for taming local development chaos, I’d genuinely love to hear them. These little personal tools are often the most honest things we create.

UPDATE: If anyone is interested in trying this tool then it's available on GitHub. I have releases for .Deb and .AppImage. If you code on Mac or Windows then building on them is supported if you clone. I just don't use any of them and can't vouch for if it works well.

What’s a project you’re genuinely proud of?

Christoffer Madsen — Thu, 13 Nov 2025 12:43:14 +0000

I’ve been thinking a lot lately about how we, as developers and creators, show up online.

In my earlier posts, I talked about how hard it can be to share our work — not because we don’t build things, but because showing them to the world feels like stepping into a spotlight we’re not always ready for.

But something happened recently that made me want to flip the perspective a bit.

I want to give you the mic this time.

Before I do that, I’ll go first — because I know how much easier it feels when someone else breaks the ice.

My proudest project (right now)

Out of everything I’ve built, big or small, the thing I’m most proud of right now is Get Out There — a tiny little web app meant to help introverted or anxious creators become more comfortable posting online.

It’s simple on purpose:

One gentle daily challenge
No social pressure
Anonymous by default
No likes, no followers, no scoreboard

Just small, steady steps toward visibility.

It’s not the most complex thing I’ve ever built technically — but it’s the one that feels the most human. And that’s what makes me proud of it.

Not because it’s perfect.
Not because it’s popular.
But because it’s something I built from a place of honesty… and people told me it made them feel seen.

That means more to me than any clever code ever could.

Now I want to hear from you

Seriously.

What’s a project — big or small — that you feel proud of?

It doesn’t have to be polished.
It doesn’t have to be a portfolio piece.
It doesn’t even have to be “finished.”

It can be:

The first thing you ever shipped
A weird tool only you use
Something you built to solve your own problem
A small design that made you smile
A repo you keep tinkering with when no one is watching
A failed experiment that taught you something important

Or just a moment where you surprised yourself.

Whatever it is — I’d love to hear about it.

Not to judge.
Not to rank.
Not to compare.

Just to celebrate the fact that you made something.
And that’s worth something.

Why this matters

We’re surrounded by polished launches, big announcements, and “success stories.”
But most creativity doesn’t look like that.

Most of it happens in quiet rooms.
Late at night.
In small bursts.
On half-finished ideas.
In notebooks.
In VS Code tabs we never close.

And we rarely get to hear about those.

So today, I’d love to see the things that don’t always get shared — the ones people build because they care, because they’re curious, or because it just felt good.

Your turn

What’s a project you’re proud of?

Leave it in the comments.
Share a link if you want.
Or just describe it.
Or keep it vague.

Whatever feels comfortable — I’m here for it.

Let’s make a small space where showing up feels… a little bit easier.

I’ll be here reading every one.

I use AI when I code. And sometimes it makes me feel like I’m cheating.

Christoffer Madsen — Mon, 10 Nov 2025 19:53:15 +0000

I’ve been building things for a long time.
Websites, apps, experiments.
Some finished, most quietly left in folders with names like “v3-final-final”.

But the funny thing is:
I actually feel more capable than I used to.

I can make things faster now.
I can try ideas without worrying whether I’ll “get stuck.”
I can build things I would have been too overwhelmed to even attempt before.

And the reason is simple:

I use AI when I code.

I don’t hide that.
But I also don’t really talk about it.

Because sometimes it feels like cheating.

The quiet voice that shows up after the code runs

I’ll write something with the help of AI — something I understand, something that works — and for a few seconds I feel good about it.

And then the voice arrives:

“You didn’t really build this.”
“A real developer would have typed it themselves.”
“You’re just stitching together other people’s ideas.”
“If someone saw your process, they’d think you’re faking it.”

It’s strange how quickly pride can turn into doubt.

The code runs.
The feature works.
The idea became real.

And still, I feel like I’ve done something wrong.

I thought the struggle was the work

That’s the part I didn’t notice until recently.

I used to believe that the value of programming was in how hard it was.

That the more I struggled, the more it “counted.”

That if something came easily, it didn’t mean anything.

So when AI made parts of the work lighter, easier, gentler —
I didn’t feel smarter or faster.

I felt less real.

But the real point was never the keystrokes

It wasn’t about typing every line.
It wasn’t about remembering every syntax detail.
It wasn’t about wrestling with the same error for six hours to prove I deserved to make things.

The value was always in the thing I wanted to make.

The idea.
The intention.
The story.
The usefulness.
The feeling it gives someone else.

AI didn’t replace that.
It just removed some of the friction between imagination and reality.

And maybe that’s okay.

Maybe the creativity was mine the whole time

Maybe:

The idea was mine.
The direction was mine.
The decision-making was mine.
The understanding was mine.
The taste — the part that says “Yes, this feels right” — was mine.

Maybe AI didn’t make me less of a developer.

Maybe it made me more able to express the developer I already was.

If you feel this too

If you’ve ever looked at working code you wrote with help
and felt proud and ashamed at the same time,

you’re not alone.

A lot of us are quietly carrying that feeling.

And maybe the gentlest thing we can tell ourselves is:

The work was never about proving your worth.
It was about bringing something into the world that didn’t exist before.

And you did that.

That counts.

What I Learned After Building Dozens of Side Projects (Mostly By Accident)

Christoffer Madsen — Fri, 07 Nov 2025 16:44:14 +0000

Over the past few years, I’ve built a surprising amount of projects. Not all of them shipped. Some turned into real tools people use. Some became prototypes. Some died halfway through because I lost interest. But I noticed certain patterns — lessons that kept repeating no matter what I was building.

These are the things I wish someone had told me much earlier.

1. Clarity beats cleverness

Almost every time I got stuck, the solution wasn't a new library or pattern. It was something much simpler:

Rename a confusing variable.
Write the UI state in one place instead of six.
Remove a layer of abstraction that didn’t help.
Make the flow explicit instead of “smart.”

Code that is easy to understand is code you actually want to work on.
If I avoid my own code, I know I tried too hard to be clever.

2. The right stack is the one you can keep momentum in

I’ve built projects in:

Next.js
Vite + React
Electron
Supabase
MySQL
Node APIs
Rust experiments

The takeaway wasn’t “use Stack X.”

It was:

Pick the stack that makes the next step easy.

If the framework gets in the way, it’s the wrong framework for this project, even if it’s technically “better.”

Momentum > purity.

3. A project only becomes clear when it has a real audience

Whenever I tried to build something “for everyone,” everything was foggy:

What features?
What UI?
What workflow?

But the moment I defined a real user — like a coworker, a partner, or a local business — the design decisions made themselves.

“Real person, real problem” is the fastest way to clarity.

4. Reusability is a quiet superpower

Over time, I realized I was slowly building a toolkit:

UI components I keep reusing
Tailwind + React project structure I always return to
A few motion patterns that feel like “my style”
A mental model of how I like routing and data flow

Each new project is now faster to start than the last.

That’s the long game.

5. When motivation drops, the scope is wrong

Every time I stalled, one of these was true:

The next task was too big
I didn’t know what exactly to do next
I wasn’t seeing progress visually
I was building something abstract instead of tangible

Once I sliced the work smaller, motivation came back.

Motivation isn’t magic. It’s feedback.

6. Shipping something imperfect is better than polishing something imaginary

This one took time to accept.

It’s better to release something small and real than to keep perfecting something that doesn’t exist yet.

Real things create momentum.
Unreleased things create stress.

Done is a feature.

7. The best workflow I’ve found is iterative conversation

My best projects followed a simple loop:

Outline idea (imperfect is fine)
Build a small working version
See it on screen
Adjust based on how it feels
Repeat

Planning is useful, but only if you actually build in between.

Thinking and building need to happen in cycles, not phases.

Final Thought

If I had to sum all of this up:

Progress comes from clarity, constraints, reusability, real users, and shipping in small steps — not from chasing the perfect architecture.

Side projects aren’t just about building products.

They’re how you train your taste.

If you’re working on something now: make the next step small, visible, and real. Then take that step.

If you got something from this, I’d love to hear what you’re currently building.
Drop it in the comments — I’ll actually read it. 🙌

We’re Now in the AI vs AI Resume War

Christoffer Madsen — Thu, 06 Nov 2025 19:11:35 +0000

Everyone knows companies are using AI to scan resumes now.
But we’re also at the point where applicants are using AI to write those resumes.

So we get this situation:

The applicant uses AI to make their resume stronger.
The recruiter uses AI to filter resumes faster.
HR uses another AI to detect whether the resume was written by AI.

And all of this still ends with:
“We’ll get back to you.”

It’s weird.

And kind of funny.
And also kind of depressing.

Because for applicants, job searching is emotional:

Hope
Stress
Trying to prove that you’re worth something
Taking rejection personally

For recruiters, it’s logistical:

Way too many candidates
Not enough time to review everyone
Pressure to reduce the stack quickly

So both sides start using AI.
Not to cheat — just to survive the process.

But then you get the contradiction:

“We can use AI to evaluate your resume, but if you used AI to write it, we might penalize you.”

Feels… uneven.

We’ve reached a point where the hiring pipeline is basically:

AI writes → AI evaluates → AI judges authenticity → humans maybe talk later

The process still pretends to be human.
But most of the interaction is now just AI negotiating with AI about humans.

I don’t think this is “bad” or “good.”
But it’s definitely something we should acknowledge instead of pretending nothing has changed.

What do you think? Is this just the natural evolution of hiring, or does it feel like something important is being lost?

I struggle to post online. So I built a tiny app to practice showing up.

Christoffer Madsen — Wed, 05 Nov 2025 11:52:58 +0000

I’ve been a web developer for years, but I’ve always had trouble sharing anything online.

It’s not that I don’t want to.
It’s that every time I try to post something, I get this wave of:

“Who cares?”
“This isn’t good enough.”
“People will think I’m faking it.”
“Someone smarter is going to call me out.”

So instead of posting, I’d just close the window.
Or save a draft.
Or promise myself I’d come back later.

And later never came.

The odd twist: I can build things — I just felt weird showing them

AI has actually made this stronger.
I use AI to assist with a lot of my code now.
I understand and modify everything, but I’m not typing everything by hand.

So the imposter syndrome whispers even louder:

“You didn’t really build this.”

Which is silly — because the point of building is to create, not to impress.

But brains do what brains do.

So I built something for myself

I made a tiny web app called Get Out There:
https://out.madsens.dev

The idea is very small:

You get one daily challenge.
The challenge is something gentle. Not content creation. Not exposure therapy.
Just showing up in a tiny way.

Examples:

Write a post you’ll never publish.

Leave one kind comment today.

Share something small you’re quietly proud of.

You can mark it complete, optionally reflect in private, and your comfort score and streak grow a little.

No followers.

No likes.

No performance.

Just gentle practice.

Why this works for me

Because posting isn’t actually about the post.

It’s about being okay existing publicly.

It’s like the gym.
You don’t start by deadlifting 180kg.
You start by touching the bar.

Small steps count.

And most days, the hardest part is simply showing up at all.

It's live if you want to try it

No signup.

Anonymous by default.

No pressure to share anything publicly.

Just quiet growth:

👉 https://out.madsens.dev

If this resonates with you

Then you’re likely the kind of person who makes cool things quietly — but the world never sees them.

And honestly?

The internet needs more people like you.

Not louder ones.

Just present ones.

So if you try it, let me know how it feels — privately, publicly, anonymously, whatever works.

I’ll be right there doing my own Day 1 again, too.