Harvey | Tech Builder

Tech builder.

Systems over motivation.
Defaults over discipline.

Automation.
Structure.
Execution.

[Harvey | Tech Builder @lxy71]

Before changing an AI workflow, save a small set of real tasks.

Define success. Run each more than once. Check the actual result, not just “done.”

My take: a repeatable test beats a convincing demo.

Useful agent-eval guide:
https://t.co/2r3W1f2Bpa

[Harvey | Tech Builder @lxy71]

Meta's new WhatsApp Business Tools MCP lets AI coding agents help set up accounts, add numbers and build templates.

My take: start with test workflows. Check each change before using it with customers.

Which setup step would you delegate?
https://t.co/fU30F4HdvR

[Harvey | Tech Builder @lxy71]

Gmail AI search is expanding beyond the US (Sept 15).

English + eligible paid plans; regional exclusions apply.

My take: faster retrieval helps, but verify dates and commitments in the original email.

Would you use it?
https://t.co/JmxLdUjXQx

[Harvey | Tech Builder @lxy71]

As a solo ops freelancer,
I don’t automate everything.

My rule:

If I don’t understand it,
I don’t automate it.

Automation amplifies mistakes.

First:
•understand the failure pattern
•document the manual process
•confirm the root cause

Then automate.

[Harvey | Tech Builder @lxy71]

As a solo ops freelancer,
if I do something twice,

I automate it.

Manual restart once? Fine.
Manual restart twice? Script it.

Same alert every week?
Fix the trigger or automate the response.

Repetition is a signal.

Ops isn’t about working harder.

It’s about removing frictio

[Harvey | Tech Builder @lxy71]

As a solo ops freelancer,
every incident ends with a review.

My default post-incident template:
•What failed?
•Why did it fail?
•Why wasn’t it detected earlier?
•What will prevent it next time?
•Is the fix documented?

No blame.
No drama.
Just system improvement.

[Harvey | Tech Builder @lxy71]

As a solo ops freelancer,
every incident follows the same flow.
1.Identify scope
2.Stabilize first
3.Communicate status
4.Document actions
5.Fix root cause later

Panic fixes nothing.

Structure contains chaos.

Ops is controlled response.

[Harvey | Tech Builder @lxy71]

As a solo ops freelancer,
my week has structure.

Monday → client priorities
Tuesday–Thursday → delivery blocks
Friday → maintenance + billing
Weekend → learning + system improvements

If I don’t design the week,
clients will.

Ops isn’t only server uptime.
It’s calendar cl

[Harvey | Tech Builder @lxy71]

As a solo ops freelancer,
I don’t respond to everything immediately.

Default rule:

Incidents → respond now.
Client delivery → scheduled block.
Messages → batch twice a day.
Improvements → weekend planning.

Not everything urgent
is important.

Ops isn’t reacting.

[Harvey | Tech Builder @lxy71]

Ops isn’t just infrastructure.

It’s time design.

[Harvey | Tech Builder @lxy71]

As a solo ops freelancer,
my biggest risk isn’t downtime.

It’s distraction.

If I context-switch all day,
nothing ships.

So I use fixed blocks:
•Incident window
•Client delivery window
•Maintenance window
•Learning window

Revenue follows focus.

[Harvey | Tech Builder @lxy71]

Now I don’t touch production
without:
•backup of last working config
•documented rollback steps
•timestamped change log

Solo ops taught me this:

Discipline fades.

Structure protects.

[Harvey | Tech Builder @lxy71]

Last month, I almost caused my own outage.

A small config tweak.
“No big deal.”

Five minutes later:
Service down.

The fix wasn’t technical.

It was structural.

[Harvey | Tech Builder @lxy71]

It’s about designing less chaos.

That’s the system.

[Harvey | Tech Builder @lxy71]

Solo Ops Reliability Series (7/7)

Reliability is not a tool.

It’s a mindset.

Structure before features.
Private before public.
Rollback before change.
Restore before backup.
Visibility before scaling.
Redundancy before trust.

Solo ops isn’t about doing more.

[Harvey | Tech Builder @lxy71]

Redundancy isn’t expensive.

Downtime is.

Ops designs for failure,
not perfection.

[Harvey | Tech Builder @lxy71]

Solo Ops Reliability Series (6/7)

Every outage has a root cause.

Many have a single point of failure.

Before I rely on any service, I ask:
•What happens if this node dies?
•Is there a fallback?
•Is failover automatic or manual?
•Have I tested the switch?

[Harvey | Tech Builder @lxy71]

Solo Ops Reliability Series (5/7)

If I can’t see it,
I don’t trust it.

Before I scale anything, I check:
•Do I have CPU, memory, disk metrics?
•Do I know normal vs abnormal?
•Are alerts actionable?
•Who gets notified?

Scaling without monitoring
just scales uncertainty.

Ops is visibility first.

[Harvey | Tech Builder @lxy71]

Solo Ops Reliability Series (4/7)

Backups are not ops.

Restore tests are.

I don’t ask:
“Do I have backups?”

I ask:
•Have I restored from them?
•How long did it take?
•What broke during recovery?
•Is the process documented?

A backup you’ve never restored
is just hope.

Ops is verified recovery.

[Harvey | Tech Builder @lxy71]

Before I open port 443 on any server, I ask:
•Do I really need it public?
•Is access restricted by IP?
•Is there rate limiting?
•Do I have logs enabled?

Most self-hosted setups fail at exposure control.

Public is default.

Security is an afterthought.

Ops flips that.

Private by default. Public by design.