Friday, August 14, 2026

Off the Clock: Make a P.M. Decision



I'm a software engineer who spends work hours thinking about products, users, and how to make things that matter. After hours, I live my life. I stay up to date with the world around me. I work with my hands—wood, leather, garden soil. This is where those worlds meet. Sometimes a hobby teaches me something about my day job. Sometimes my product instincts change how I approach a craft. The lines cross more often than you'd expect. And this series of posts will be about that bi-directional influence.

 

One of my favourite comedians is Kat Williams. And one of my fourth jokes he told tells a story about his son wanting a new Xbox. Instead, Kat convinced him to buy a used Nintendo console with two controllers and like 20 used games. His reasoning stuck with me for quite some time because it fits exactly how I think about product decisions in my engineering role.

He said multiple things in a matter of 2 minutes that changed how I see my work. Let me break down a few of them.

Daddy Can Do This All Day Every Day, No Problem

Kat said this about buying an Xbox for 199.99$. He had the money. He could do it. But he advised his son not to.

This sounded very close for engineers. We get asked to build things all the time. Use new frameworks. Add big fancy features. Complex architectures. My answer is often yes I can if that's the only choice. I can do it every day, all day. But that is not the question.

The real question is whether we should. A Product Manager mindset asks what outcome we are trying to reach. Is this the fastest path? Does this solve the actual problem? Or am I just showing off technical skills while wasting time?

I have said no to tasks I could easily complete. I once (or twice?) harmed my own bi-yearly performance review because I sounded "against the change" when it came to adding a new unnecessary fancy dependency to our stack. Not because I could not do them. Because I had a better idea for that time and effort. The best use of engineering power is not saying yes to everything. It is choosing the right thing to say yes to.

It Only Comes With 2 Demo Games and One Controller

Kat said the Xbox was a trap. Buy the base unit, then pay for every game. It comes with one controller. Daddy can't play with you. Your friends can't play with you. Buy another controller.

This happens in software too. A tool sounds free until you add the plugins. An API seems cheap until usage spikes. A microservice architecture starts simple but needs monitoring, logging, deployment pipelines, and five more services just to talk to each other.

These are hidden costs. Nobody shows them on day one. By the time you see them, you are already locked in. Migration takes months. Rewriting takes longer. Now you cannot go back.

A P.M. decision asks what comes in the box before you sign the contract. What are the real limits? What do I pay later that I ignore now?

20 Games That Other Kids Have Already Opened and Played With To Make Sure It Is Fun

Kat explained why the Nintendo was better. It came with like 20 games other kids had already tested. You knew they worked. You knew they were enjoyable.

Software has the same lesson. Some love shiny new tools. The latest library. The newest cloud service. The framework everyone is talking about. But who has really tested them yet in production? Nobody knows if they hold up under our pressure and our specific uses.

A P.M. decision looks for the games that already came with the system. Use patterns that work. Copy what others have learned. Solve the problem with code that has been proven before.

This does not mean staying old forever. It means being smart about when to risk. I would rather ship a boring feature that works than build something cool that crashes.

We Got Like 300 Dollars Leftover

If Kat's son chose the Nintendo over the Xbox, the saved money stayed in Kat's pocket. They could go across the country and have all the ice cream and nuggets they want! The point was not about saving cash. It was about having resources for other things.

In engineering we call this technical debt or opportunity cost. Every hour spent building unnecessary complexity is an hour taken from solving real user problems. Every server running unused features is budget gone from hiring someone new. Every bug in unfinished code slows down the next sprint.

Making a P.M. decision means looking at what you save when you choose simple over flashy. That saved time becomes freedom. Freedom to try real experiments. Freedom to pay down tech debt. Freedom to have fun building the next thing that actually matters.

Sometimes the smartest engineering move is doing less work.

The Bottom Line

Kat Williams taught his kid something bigger than video games. He taught him to look past the hype and the peer pressure. To value proof over promise. To keep resources for what matters.

Same applies to my work as an engineer. I can say yes to every request. I can build every feature. But a product mindset changes the question from can I to should I.

Make a P.M. decision. Choose the used game. Save the money. Keep the resources. Build what proves valuable over time.


Monday, July 13, 2026

Off the Clock: Prepping the Leather – Small Wins, Onboarding, and Lowering Barriers





I'm a software engineer who spends work hours thinking about products, users, and how to make things that matter. After hours, I work with my hands—wood, leather, garden soil. This is where those worlds meet. Sometimes a hobby teaches me something about my day job. Sometimes my product instincts change how I approach a craft. The lines cross more often than you'd expect. And this series of posts will be about that bi-directional influence.



Some time ago, I had an idea: what if I sold a kit for making a leather wallet—not the full process, but just the final step?

I had already done the hard parts. I had measured, cut, punched holes, installed the push buttons, and glued the zipper. What remained was the stitching. The buyer would receive a nearly-complete wallet, two needles, some thread, and one skill to learn. One weekend, one satisfying project, one personal leather wallet.

The person who bought it told me it was a lovely weekend project. For them, the experience was about creating something without frustration. For me, it was about recognizing where the real barrier was—and removing everything except the one thing that makes the craft feel like craft.

What I didn't expect was how much this little experiment would influence how I think about my day job.

Where the barrier actually lives

When I started learning leathercraft myself, I ruined materials. Not because stitching is hard—it isn't, once you try it—but because getting to the stitching required a wall of tools, precise cuts, and mistakes that were expensive to make. The entry cost wasn't the skill. It was everything around the skill.

The same is true in software engineering. When a new engineer joins a team, the actual coding is rarely the bottleneck. The barrier is the setup, the domain knowledge, the unwritten rules, the context that lives in someone's head. By the time they write their first meaningful line of code, they've often already felt lost, slow, and unsure of themselves.

I've seen what happens when someone's first contribution is a small, successful one—fixing a bug, shipping a minor improvement. And I've seen what happens when their first task is unclear and goes nowhere. The first one builds momentum. The second one builds doubt.

The wallet kit taught me this in a different material: prep the hard parts, hand over the meaningful part, and let the learner feel competent early.

What product scoping and leather prepping have in common

There's a moment in leathercraft where you decide how far to prepare and where to stop. Cut too little and the user struggles. Prepare too much and you've removed the craft entirely—there's nothing left for them to own.

This is the same tension in product scoping.

When I've worked on launching a new product feature, we spent time in early research before writing a line of code. We looked at existing solutions, built small prototypes, and tested our assumptions. The goal wasn't to ship everything at once. It was to ship the minimum thing that would make a user feel: "Yes, this solves a real problem I have."

We cut features. Not because they weren't valuable, but because they weren't the first valuable thing. The wallet kit works because stitching is the first valuable thing—it's the moment where the pieces become a product. Everything before that is preparation. Everything after that is improvement.

In product, I've learned to ask the same question the wallet kit answers: what is the one action, the one moment of value, that this product delivers? Build toward that. Cut the rest for later.

The feedback loop I didn't plan for

Here's what surprised me: the product thinking I use at work started flowing back into my hobbies, and vice versa.

When I scope a product feature now, I think about the wallet kit. Not literally, but structurally: What am I asking the user to do before they reach value? Can I remove some of it? Am I handing them a pile of pieces and tools, or am I handing them a nearly-complete experience with one meaningful step to own?

When I design any other hobby project now, I think about user research. Who is this for? What do they already know? What will frustrate them, and is that frustration necessary—or is it just there because that's how I learned?

Neither side owns the lesson. They feed each other.

Small wins, bigger bets

The person who bought that kit wasn't trying to become a leatherworker. They wanted a weekend project that felt good. A small win.

But I've noticed—in engineering, in product, and in craft—that small wins are where bigger things begin. The new engineer who ships a fix on day three comes back on day five wanting something harder. The user who tries a feature and saves time asks what else it can do. The person who stitches a wallet starts looking at leather and wondering about more.

You don't get people to bigger commitments by making the first step harder. You get there by making the first step possible—and letting the satisfaction do the rest.

That's what the kit was really about. Not leather. Not wallets. Just the idea that lowering the barrier to a first win is one of the most generous things you can do—for a teammate, a user, or a stranger who wants to make something with their hands.

Tuesday, May 19, 2026

FinOps Beyond Cloud: Flagging Which LLM Path Runs

It’s 2026, and I pretend less that coding stops at merge. Plans still matter, but margin (revenue minus cost) matters too: if usage jumps, many users pile onto cheap tiers, or ARPU (average revenue per user) stays low, is your default technical path still affordable?

If you tilt product-minded, you often want costs and revenue to steer behavior—not just quarterly decks—and you ship guardrails (limits and alerts for spend and risk) plus metrics so typo fixes aren’t casually riding flagship AI tiers.

This post is a relaxed tour of one slice of that: treating cloud and model spend as something you design for, not something you discover on the invoice.

1. What a product-minded engineer optimizes beyond “merged”

Shipped is rarely the final step. The sharper test: multiply usage, push traffic through loss-leader tiers—does profitability still behave?

Checklist framing:

  1. Costs and revenue should sway day-to-day decisions.
  2. Use the cheapest good-enough path first; expensive models owe you justification.
  3. Add observability (logs/metrics showing what paths ran in prod) early so invoices don’t become the dashboard.

2. A profitability-aware seam—not just “flip the rollout switch”

Cost-aware feature flagging is more than switching release trains. (Feature flags toggle behavior remotely without reinstalling everywhere.) Core question shifts to:

For this payer plus this job step, does calling the pricey model earn its keep right now?

Two halves:

Inputs (FinOps-style facts): tooling that exposes spend (AWS Pricing CalculatorOpenCost), quotas (vendor-enforced caps), subscription revenue—not only beta_user=true.

Outputs: same outward job, staged execution—offline libraries; lighter Gemini Flash-class SKU; heavier Pro-class SKU when needed; delay/batch—not one greedy lane dialing the richest model every hop. (SKU or "Stock Keeping Unit" is vendor shorthand for a priced product bundle—the name on the invoice.)

Treat it like authentication (auth—checking who acts) guarding expensive work—but margin sits beside permission.


3. Models answer prompts—they don’t run budgets

A reader might ask whether frontier models magically cheap-route some of the simpler work.

Simply said: No. They optimize outputs within the SKU you bought; no accountants live there. You pick SKU tiers—they chase quality inside that sandbox. Toss a heavyweight tier at a petty job and it still replies, while metering charges requests, not vibes.

Operational decisions stay yours: routing (offline versus vendor lane), backoff (pause before retries when throttled), and hard-stop retry budgets. Models themselves won’t politely refund spend.


4. Total cost of ownership (TCO)—dashboards versus sloppy lanes

(TCO = total cost of ownership) includes quiet extras—not only billed tokens—like wrong tier ladders, retry storms, consolation “redo” generations after junk answers.

Log routing branch, approximate tokens (what vendors bill on) before stray heavyweight completions overshadow dashboard cost. Procurement warning ahead: illustrative magnitudes only—junk routing has landed teams roughly two to four orders of magnitude (~100×–10,000×) hotter than guarded paths.

Prefer modest telemetry before invoices swell.


5. From toy splitter to nearer-production routers

Toy setup uses HTTP POST /v1/check with JSON { text, task } and tasks spellcheck or summarize.

Environment COST_OPTIMIZATION_ENABLED when on triggers Typo.js (open-source English spellchecking) plus an extractive summary (reuses existing sentences—invents nothing).

When offGemini 2.5 Flash (Google positions this as its lighter SKU string gemini-2.5-flash) owns both passes.

Closer to prod, swap the simple “if-this-then-that” rules for nuanced routing plus subscription and billing knobs—still feeding FinOps signals.


6. Sampling experiment—methods first; numbers follow

This section lays out (1) what mechanically reran, (2) tables in later subsections, (3) how extrapolation pencils out—lab notebook plus spreadsheet honesty, not magic.

6.1 What reran—and what got skipped deliberately

Bench here means scripted automation issuing the same deterministic requests.

Ran: fabricated multi-section write-up (~290 words) with sequential jobs (spellcheck then summarize). Express route POST /v1/check. Flag COST_OPTIMIZATION_ENABLED jointly toggles offline Typo stack versus Gemini 2.5 Flash via @google/genai. Then a script prints timings plus playful dollar placeholders—not accounting truth.

Skipped: proportional live traffic mixtures, randomized A/B tests (A/B: compare flows across user subsets)—this isolate covers mechanism, not population behavior.

Driving question stays:

Holding document shape steady and accepting cheaper summaries, how many vendor completions vanish?

Extrapolation (spoken plainly):

Rough monthly dollars skipped ≈ (cloud completions you avoided) × (realistic dollars per completion).

Assume each workflow run equals the spell+summarize pair (two HTTP POSTs)—linear scaling versus monthly runs. Lock those two POSTs/run, multiply by how many drafts, audits, or refactors fire monthly.

6.2 Head-to-head results (the sample)

MetricOptimization ONOptimization OFF
Requests22
Offline routes20
Cloud (Gemini)02
Avg latency (ms)~2378~4788
Placeholder session total$0.000000$0.000230

The session total is only the demo knobs COST_CLOUD_SPELLCHECK + COST_CLOUD_SUMMARY in server.js—fine for a workshop, not a bill.

Plain-language takeaway for this slice: optimization on skipped every Gemini invocation that off made for these two tasks (0 vs 2 calls → 100% avoidance for this pair only). Tradeoff: extractive bullets and a full-file dictionary pass are cheap, but the spell step can land around a few seconds on a long draft (~4.7s on the first spellcheck request in my run), while the offline summary stayed single-digit ms.

6.3 Projecting to volume (drafts, edits, audits, refactors)

Illustrative token sketch—same Flash-style guesses baked into the benchmark (~2200 / 2000 in/out for the long corrective pass, ~2200 / 450 for exec summary, $0.15/M in and $0.60/M out; verify Gemini pricing). Think of a run as one time you execute spellcheck + summarize on a body—e.g. a new draft, a heavy edit, an audit pass that re-queues the pair, or a refactor that rewrites a section and re-runs the tooling.

ItemOptimization ON (this demo)Optimization OFF (all Gemini for these two tasks)
Cloud calls / month @ 5k runs (2 POSTs per run)010,000
Order-of-magnitude API $ / month~$0~$10.65
Avoided vs all-cloud at that volume (token model only)~$10.65

Scale the numerator: at 50k runs/month—stacking draft cycles, revision rounds, audit and compliance re-checks, refactors, anything that replays this two-step cloud path—the same all-cloud token math lands near ~$106/month for that slice alone—before you add any new AI feature. The cost-aware pattern is convincing here because the growth lever is obvious: more passes through the pipeline ⇒ more invocations ⇒ the same percentage of avoided calls buys proportionally more dollars as activity grows.

6.4 Where product growth quietly multiplies cost (features, not just users)

Users rarely stop at “spellcheck + summary.” Roadmaps add adjacent model tasks: e.g. AI glossary (“explain this acronym for a non-security exec”), keyword callouts next to the summary, a risk-language nudgeemail-ready rewrite, or second-pass tightening. If each is implemented as another always-on Gemini call, you get multiplication: two cloud tasks become three, four, five—each time someone runs the flow—while routing stays an afterthought.

A cost-aware seam doesn’t mean shipping worse product; it means deciding per task (plan tier, cache, template, small model, batch, human review) instead of defaulting “new AI affordance ⇒ new flagship invocation.” The bench only models two tasks, but the projection mental model extends: every new task is a coefficient on monthly variable spend unless you fold it into the same router.

6.5 Why this is still a convincing case for the approach

  1. The sample isolates mechanism: you can see exactly which HTTP paths hit the model when the flag flips—no mystery meat in “optimization.”
  2. Volume makes small per-call numbers real: ~$0.00107/POST on the all-cloud token estimate at 10k calls/month is easy to shrug off until draft/edit/audit/refactor volume (and features) push you to 100k+ calls.
  3. Feature creep is the hidden multiplier: routing discipline is how you ship more AI-shaped surface area without linear-to-cloud spend on every new button.


Please note: The playground code for server.js is at the bottom of this post. The post treats that run as a sample you can scale with your own monthly pipeline volume—how often teams hit spellcheck + summarize across drafts, edits, audits, refactors, and so on—and your task list. Dollar figures mix placeholder session costs and illustrative token mathabsolute savings scale with users, calls per run, model tier, and how many new AI features stay cloud-default—plug in real metering before treating any number as financial guidance.


require('dotenv').config();
const express = require('express');
const { GoogleGenAI, ApiError } = require('@google/genai');
const Typo = require('typo-js');

const app = express();
app.use(express.json());

const dictionary = new Typo('en_US');

const genai = new GoogleGenAI({
    apiKey: process.env.GEMINI_API_KEY,
});

/** Placeholder $ per cloud call (tune for FinOps demos; real bills use metering). */
const COST_CLOUD_SPELLCHECK = Number(process.env.COST_CLOUD_SPELLCHECK) || 0.00005;
const COST_CLOUD_SUMMARY = Number(process.env.COST_CLOUD_SUMMARY) || 0.00018;

/** Correct spelling per word; preserves whitespace and punctuation (en_US). */
function correctWithTypo(text) {
    return text.replace(/\b[\w']+\b/g, (word) => {
        if (dictionary.check(word)) return word;
        const suggestion = dictionary.suggest(word)[0];
        return suggestion || word;
    });
}

/** Cheap path: lead sentences + pseudo-bullets (no API). */
function extractiveExecutiveSummary(text) {
    const t = text.trim().replace(/\s+/g, ' ');
    const sentences = t.split(/(?<=[.!?])\s+/).filter((s) => s.length > 15);
    const head = sentences.slice(0, 4).join(' ');
    const base =
        head.length >= 200 ? head : t.slice(0, Math.min(1200, t.length)) + (t.length > 1200 ? '…' : '');
    const lines = base
        .split(/(?<=[.!?])\s+/)
        .filter(Boolean)
        .slice(0, 5)
        .map((s) => `- ${s.trim()}`);
    return lines.join('\n');
}

let sessionTotalCost = 0;

function isTruthyEnv(name) {
    const v = process.env[name];
    if (v == null) return false;
    return /^(1|true|yes)$/i.test(String(v).trim());
}

/** Pull a readable message out of SDK errors (often `message` is stringified JSON). */
function geminiErrorDetail(err) {
    const msg = err && typeof err.message === 'string' ? err.message : String(err);
    try {
        const parsed = JSON.parse(msg);
        const inner = parsed && parsed.error ? parsed.error : parsed;
        if (inner && typeof inner.message === 'string') {
            return { summary: inner.message, code: inner.code, status: inner.status };
        }
    } catch (_) {
        /* use raw */
    }
    return { summary: msg };
}

app.post('/v1/check', async (req, res) => {
    const { text, task } = req.body ?? {};
    if (typeof text !== 'string' || !text.trim()) {
        return res.status(400).json({ error: 'Body must include non-empty string `text`.' });
    }
    if (task !== 'spellcheck' && task !== 'summarize') {
        return res.status(400).json({
            error: 'Body must include `task`: "spellcheck" | "summarize".',
        });
    }

    const isOptimizationOn = isTruthyEnv('COST_OPTIMIZATION_ENABLED');
    const words = text.trim().split(/\s+/);

    let output = '';
    let engine = '';
    let cost = 0;

    try {
        if (task === 'spellcheck') {
            if (isOptimizationOn) {
                if (words.length <= 5) {
                    output = correctWithTypo(text);
                    engine = 'Offline (Typo.js)';
                } else {
                    output = correctWithTypo(text);
                    engine = 'Offline (Typo.js full document)';
                }
                cost = 0;
            } else {
                const model = process.env.GEMINI_MODEL || 'gemini-2.5-flash';
                const response = await genai.models.generateContent({
                    model,
                    contents: [
                        'You correct spelling and obvious typos only. Preserve structure, headings, and meaning. Reply with the full corrected text only—no preamble or quotes.',
                        `Document:\n${text}`,
                    ].join('\n\n'),
                });
                const raw = response.text;
                if (raw == null || !String(raw).trim()) {
                    throw new Error('Empty response from model');
                }
                output = String(raw).trim();
                engine = `Cloud spellcheck (${model})`;
                cost = COST_CLOUD_SPELLCHECK;
            }
        } else {
            // summarize → executive summary
            if (isOptimizationOn) {
                output = extractiveExecutiveSummary(text);
                engine = 'Offline (extractive executive summary)';
                cost = 0;
            } else {
                const model = process.env.GEMINI_MODEL || 'gemini-2.5-flash';
                const response = await genai.models.generateContent({
                    model,
                    contents: [
                        'Condense the report into an executive summary for leadership: 3–5 bullet points, plain text, each line starting with "- ". Be factual; do not invent risks or metrics.',
                        `Report:\n${text}`,
                    ].join('\n\n'),
                });
                const raw = response.text;
                if (raw == null || !String(raw).trim()) {
                    throw new Error('Empty response from model');
                }
                output = String(raw).trim();
                engine = `Cloud summary (${model})`;
                cost = COST_CLOUD_SUMMARY;
            }
        }

        sessionTotalCost += cost;
        console.log(`[${new Date().toISOString()}] task=${task} Engine: ${engine} | Cost: $${cost}`);

        res.json({
            task,
            output,
            engine,
            stats: { sessionTotal: sessionTotalCost.toFixed(6) },
        });
    } catch (error) {
        if (error instanceof ApiError) {
            const { summary, code, status: bodyStatus } = geminiErrorDetail(error);
            const httpStatus =
                typeof error.status === 'number' && error.status >= 400 && error.status <= 599
                    ? error.status
                    : 502;
            console.error('[Gemini ApiError]', httpStatus, summary);
            const label =
                httpStatus === 429
                    ? 'Gemini quota or rate limit (check plan / AI Studio quotas)'
                    : 'Gemini API error';
            return res.status(httpStatus).json({
                error: label,
                details: summary,
                geminiCode: code,
                geminiStatus: bodyStatus,
            });
        }
        console.error('[Report pipeline]', error);
        res.status(500).json({ error: 'System Error', details: error.message });
    }
});

const PORT = Number(process.env.PORT) || 3000;

const server = app.listen(PORT);
server.once('listening', () => {
    console.log(`Report spellcheck + executive summary API on port ${PORT}`);
});
server.once('error', (err) => {
    console.error('Server failed to start:', err.code === 'EADDRINUSE' ? `port ${PORT} is already in use` : err.message);
    process.exit(1);
});