fred@blog:~$
$ cd/home/fred

$ cat /approach

How I work

Every engagement is built around the same question: where is the cost of a unit of work about to drop by an order of magnitude, and how do we deploy that before the competition does. In satellite communications that unit was a byte in transit. In business systems it was an integration. Today it is knowledge work, and the answer is AI.

So the current approach is simple. We work together to get the most out of the latest innovation. I bring a set of agents and a way of running them where your team can see every step. Agents do the volume. Your people do the judgment. Neither works alone.

The work happens in the open, in shared channels, not in private chats with a model. Your team learns the tools by watching. The agents learn your company from the corrections. When I leave, the room keeps working.

What I bring into the room

  • Agents with tool access scoped to your systems, read-only until you say otherwise, every call logged where the team can see it
  • A persistent memory of the engagement so Tuesday's lessons are still true on Thursday
  • A shared channel per problem, where reviews happen in public and become instructions for next time
  • A handover plan from day one. The goal is that the workshop outlives the consultant

inspired by: Tobi Lütke, Learning on the Shop Floor

Claims are cheap. What follows is the work behind them, with a line for clients and a line for investors under each one.

$ cat approach/ai-systems/README.md

AI systems that actually ship

I build agentic systems, retrieval pipelines, and memory layers, and I write about what breaks when they meet production.

The work

--for=clients
Scoping and building an AI feature that has to survive real users: retrieval, agents, tool calling, evaluation, and the guardrails around them.
--for=investors
I have opinions about which AI claims hold up because I have shipped the failure modes. Useful for diligence on AI-native pitches.

more: ai (22) · agents (3) · automation (11)

$ cat approach/architecture/README.md

Architecture and engineering velocity

Systems that deploy in minutes, are observable, and can be changed without fear. I have opinions on how, and a track record of writing them down.

The work

--for=clients
Untangling a system that has become slow to change: migration planning, deployment pipeline, observability, and the team practices that keep it fast.
--for=investors
I can tell within a conversation whether an engineering team is set up to compound or to stall. Technical diligence and fractional CTO-style review.

more: architecture (9) · deployment (3) · best-practices (7)

$ cat approach/business-systems/README.md

ERP and business systems for midsized companies

My day job is the seam where business logic meets execution: ERP, integrations, and the data contracts underneath them.

The work

--for=clients
ERP selection, cleanup, and integration work where the requirement is business outcome, not a feature list. I have been on both the vendor and the operator side.
--for=investors
I understand how midsized companies actually buy and run software. Useful context for B2B and vertical SaaS theses.

more: api (2)

$ cat approach/company-building/README.md

Company building and lean strategy

I have started a handful of companies. Some fizzled, one hit. I apply engineering discipline to the ones I build and advise.

The work

--for=clients
Operator-level advice for founders and owners: what to build, what to buy, when to slow down, and how to keep the team aligned with the outcome.
--for=investors
I have carried a company from zero through the part where technology decisions either compound or kill you. I invest and advise with that scar tissue.

more: lean-strategy (2) · innovation (4)

$ cat approach/investing/README.md

Investing and decision-making

I split my time between engineering and investing. Each sharpens the other, and I write to keep myself honest.

The work

--for=clients
A capital-allocator view of technology spend. I will tell you what not to buy.
--for=investors
Co-investor or technical partner on deals where the engineering claims need a second set of eyes.

$ cat approach/communication/README.md

Writing and explaining hard things

Forty-odd posts, a conference talk, and a habit of pairing every deck with a memo. Clear writing is how I find out whether I actually understand something.

The work

--for=clients
Board-ready memos, architecture decision records, and the kind of documentation a team will actually read.
--for=investors
You can audit how I think. It is all here.

more: documentation (4) · productivity (13)

$ cat approach/stack.txt

Working stack

Only what I would defend in conversation. No logo wall.

Languages
TypeScript, Python, SQL
Web
Next.js, React, Tailwind, MDX
AI
LLM agents and tool calling, retrieval pipelines, vector search, MCP, evaluation
Infra
AWS, SST, serverless, CI/CD, observability
Data
Event sourcing, API-first design, ERP integration
Earlier life
Satellite communications, network economics, cost per byte

currently_learning=Where agent memory and evaluation stop being research and start being infrastructure.

$ ./fred --contact