Header image

Why "It Just Works" Meant I Was Underpaid for 15 Years

If you do your job as an architect really well, something funny happens:

Nothing.

No outages.
No screaming calls.
No “all-hands fire drill.”
No dramatic hero story you can point to.

Everything “just works.”

And that’s exactly how you end up underpaid for 10–15 years.

Because the market doesn’t know how to price disaster that never happens.

1. The Invisible Work Paradox

Good architecture is like good plumbing:

When it’s done right, nobody thinks about it.
When it’s done wrong, everyone thinks about it, loudly, at 2am.

The paradox:

The better you are at designing systems that don’t break,
The more it looks, from the outside, like:

“This wasn’t that hard.”

You don’t have:

War stories about rebuilding production in 48 hours.
Blog posts about massive outages you heroically resolved.
Public “we learned from this incident” writeups.

You have… boring graphs:

Stable uptime.
Predictable latency.
Quiet on-call rotations.

And because nothing explodes, people start to think:

“We’re paying for this… for what, exactly?”

They don’t see:

The decisions that prevented fragility.
The complexity you quietly absorbed.
The hundreds of times you said “no” to bad ideas.

They just see:
It works. Isn’t that what software is supposed to do?

2. What They Didn’t See

Here’s some of what clients never saw and never will:

The early morning and late night hours:
- Designing schema changes so migrations wouldn’t corrupt data.
- Spinning up test runs of upgrades to make sure nothing weird happens at scale.
The preventive fixes:
- Killing a risky pattern before it went everywhere.
- Reworking a module you knew would blow up at 10x load, not waiting for the explosion.
The boring operational discipline:
- Setting up backups properly, testing restores.
- Adding timeouts and retries to flaky integrations.
- Instrumenting metrics before you needed them.
The quiet refactors:
- Untangling logic so new features wouldn’t be a nightmare.
- Centralizing business rules that had begun to drift.
The “no” conversations:
- Pushing back on “quick hacks” that would have turned into permanent landmines.
- Saying “we can’t safely do that by Friday” when everyone wanted you to say yes.

Every one of those is invisible in "it just works."

The system that doesn't catch fire is a giant pile of unseen decisions.

Invisible value

3. The Underpaid Reality

So was I actually underpaid?

Yes.

Over 15+ years, I priced myself and the platform like this was:

“Solid dev work”
“Good ops”
“Reliable vendor”

When the reality was:

I was providing architect-level, ecosystem-level value:
- 20-year system stability.
- Zero contract losses.
- No catastrophic outages.
- Minimal rewrites.

What should I have charged vs what I did?

Directionally:

I priced work closer to senior dev / solid consultant rates.
I delivered value at principal/architect/fractional CTO level, consistently, for years.

The gap?

Easily hundreds of thousands to millions over the lifetime of the business.
In:
- lower margins,
- underpriced renewals,
- not charging appropriately for “this cannot go down” responsibility.

I treated:

“It just works”
as the baseline,

instead of:

the premium outcome it actually is.

4. Why I Accepted Being Underpaid

No mystery here. Combination of:

Didn’t know better
- I came up like most devs do:
  - time = money,
  - code = deliverable,
  - reliability = expectation, not value.
Builder mentality
- I was obsessed with:
  - making the thing stable,
  - making the thing right,
  - making the clients happy.
- Pricing was an afterthought.
Imposter syndrome
- When you deeply know what can go wrong, you also know where you’re imperfect.
- That makes it easy to discount your impact:
  
  “Yeah, it’s good, but it could be better, so I shouldn’t charge more.”
Conflict avoidance
- Negotiation is uncomfortable.
- Raising prices risks confrontation.
- Easier to say:
  
  “We’re fine. We’ll make it up on volume / upsell / the next contract.”

The short version:

I valued being the person who made everything run
more than I valued being paid like the person who made everything run.

That’s a nice story until you look at the bank account and the opportunity cost.

5. The 3AM Pages That Never Happened

Here’s how invisible value really works:

No one sends you an email saying:

“Thanks for the outage that never occurred.”
No one schedules a call to say:

“Appreciate the fact we don’t have to think about this platform.”

Instead, you get:

Silence.
Maybe the occasional:

“Everything’s been fine, so let’s talk about reducing costs.”

But underneath that silence are all of the things that DIDN’T happen:

No multi-day outage that put contracts at risk.
No catastrophic data loss that triggered investigations.
No rewrite emergency because the architecture couldn’t handle growth.
No ugly public failure that made leadership look stupid for choosing you.

If those things had happened, you can bet:

Everyone would assign cost to them:
- Lost revenue
- PR damage
- Churn
- Staff burnout

Because they didn’t, the default assumption becomes:

“We probably could have done this cheaper.”

That’s the trap.

6. Client Perception: Did Anyone Care?

Did clients appreciate the reliability?

Some did. In their own way:

You’d get:
- “We’re so glad we don’t have to worry about this system.”
- “You guys are rock solid.”

But it rarely shows up as:

“We want to pay you more because you never blow us up.”

What also shows up:

Procurement pressure:
- “Can we sharpen the pencil on pricing next term?”
Feature pressure:
- “Since everything’s working, can we add X, Y, Z for the same price?”

Rarely:

“Let’s re-evaluate our pricing relationship because you’ve saved us millions in avoided catastrophe.”

Again: not malice. Just human.

People normalize what doesn’t hurt them.

7. The Positioning Mistake

My core screw-up:

I positioned myself and the company as
“the reliable dev/implementation partner”
instead of
“the architect-of-critical-infrastructure that keeps your ass out of the fire.”

Concretely:

I talked about:
- Features
- Integration capability
- Speed and responsiveness
I did not talk enough about:
- Replacement cost
- Risk avoided
- Contract stability
- Compliance protection
- “You don’t have to think about this because we do.”

So when a state or client looked at us, they saw:

Vendor who does a great job,
But still inside the “software provider” pricing box.

I allowed:

My deepest value (architecture + reliability) to stay implicit,
And priced myself like it was commodity dev work.

That’s on me.

8. The Realization: When It Finally Clicked

It really hit me when:

Independent parties started estimating replacement cost.
We looked at:
- What it would cost in dev-years to rebuild.
- What failure would have meant in lost contracts.

And I had to admit:

I’d built something:
- non-trivial,
- durable,
- expensive to replicate.
And I’d priced it like:
- “nice, solid SaaS,”
- not “core infrastructure that quietly protected $X in revenue and contracts.”

That’s when the “underpaid for 15 years” realization landed.

Not in a self-pity way.
In a data-driven “oh, I see the gap now” way.

9. Lessons for Other Architects

If you’re an architect or senior engineer, here’s the lesson:

Make the invisible visible
- Don’t just say “99.9% uptime.”
- Say:
  - “Here’s what that prevented.”
  - “Here’s what downtime would have cost you at your volume.”
Talk replacement cost
- “If you decided to rebuild this, here’s the ballpark effort.”
- Not as a threat. As a lens:
  - “This is the asset you actually own now.”
Document risk avoidance
- When you design around:
  - failover
  - compliance
  - regulatory changes
- Write it down as:
  - “This is what this decision protects you from.”
Price the responsibility, not just the output
- You’re not just writing code.
- You’re owning:
  - uptime
  - integration stability
  - future change costs
- That responsibility has value. Price like it.
Stop hiding behind “I’m just a dev” if you’re not
- If you’re doing architecture, operations design, and risk management:
  - say that.
  - position that.
  - charge for that.

10. If I Could Go Back 15 Years

If I could talk to myself 15 years ago, I’d say:

Stop labeling yourself as “the developer.”
- You’re designing systems that states and contracts depend on.
- Own that in your language.
Build pricing around impact, not effort.
- Don’t just say:
  
  “This feature will take X hours.”
- Say:
  
  “This keeps you in compliance with A, B, C and protects this revenue stream.”
Raise prices earlier and tie them to risk.
- “We own this level of responsibility; here’s what that costs.”
- Be willing to walk away from deals that treat you like a commodity.
Keep a visible ledger of avoided disasters.
- Not fearmongering.
- A sober summary of:
  - “Here’s what we’ve quietly kept from happening over the last 5 years.”

Would people push back? Of course.

But at least they’d be:

Saying no to the right value proposition,
Instead of happily underpaying for value you never articulated.

If you're an architect reading this:

Don't wait 15 years to realize your "it just works" is worth more than you're probably charging for it.

Context → Decision → Outcome → Metric

Context: 15+ years of running systems with 99.9% uptime, zero contract losses, no catastrophic failures—but priced as "reliable dev work" instead of "architecture that prevents million-dollar disasters."
Decision: After realizing the gap, repositioned: lead with replacement cost, risk avoidance, and contract stability. Stop hiding behind "just a developer" when delivering architect-level outcomes.
Outcome: Conversations shifted from "what's your hourly rate?" to "what disasters are you preventing?" Pricing aligned with actual value delivered.
Metric: After repositioning, average engagement size increased 3x. Stopped attracting "cheap dev hours" inquiries. Closed fractional CTO work at premium rates within six months.

Anecdote: The Contract Renewal That Should Have Been a Rate Increase

In 2015, we renewed a state contract. The renewal meeting was short. The state administrator said: "Everything's been great. No issues. Let's keep going."

I walked out feeling good. Stable revenue. Happy customer. Mission accomplished.

What I didn't do: use that moment to reframe the relationship. I could have said: "You're right—it's been great. Zero outages. Zero compliance issues. That stability has a value. Let's talk about what the next three years should cost, given what we've proven."

Instead, we renewed at roughly the same rate. The "it just works" became the expectation, not the premium.

That single contract, renewed three more times at similar rates, probably left $200K-$400K on the table compared to what the risk-reduction was actually worth.

The lesson: "No problems" is the moment to raise prices, not accept the status quo.

Anecdote: The Competitor Who Charged What I Should Have

In 2019, a competitor entered one of our markets. Their platform was less proven. Their uptime was questionable. Their team was smaller.

They charged 40% more than we did.

When I asked a state administrator why they were even considering the competitor, she said: "They present themselves as a strategic partner. You present yourself as a vendor."

Same underlying capability. Different positioning. Different pricing power.

That conversation was a wake-up call. We weren't underpaid because our work was worth less. We were underpaid because we positioned like we were worth less.

Mini Checklist: Escaping the "It Just Works" Trap

[ ] Documented avoided disasters: outages that didn't happen, contracts that stayed because of reliability
[ ] Translated uptime into business terms: "99.9% uptime means X dollars of revenue protected"
[ ] Talked replacement cost with clients: "Here's what rebuilding this would actually cost"
[ ] Priced responsibility, not just output: "You're paying for me to own uptime and risk, not just code"
[ ] Stopped labeling yourself as "developer" when delivering architect-level outcomes
[ ] Used renewal moments to reframe value, not just accept status quo
[ ] Built a visible ledger of quiet wins that would otherwise go unnoticed