Coder Legion - Recent posts tagged dev

The Truck Driver Building His Own Programming Language- Meet Bryan MacLee

Thu, 15 Oct 2026 22:44:46 +0000

Developer Spotlight: Meet Bryan MacLee — The Truck Driver Building His Own Programming Language

🚀 What if you worked long shifts in the oil and gas industry and spent your spare time building your own programming language?

Meet Bryan MacLee, the creator of Scriml, a programming language designed to rethink how web applications are built.

In this CoderLegion Developer Spotlight, host Tom Smith talks with Bryan about his programming journey, the ideas behind Scriml, and the challenges of building a compiler independently.

💡 What You'll Discover

The beginning: How Bryan discovered programming as a teenager.
Life beyond coding: Balancing oilfield truck-driving work with software development.
Building Scriml: Why he decided to create his own programming language.
Simplifying web development: His approach to frontend-backend communication, validation and compilation.
The compiler challenge: What it's like to build a programming language largely on your own.
What's next: Bryan's hopes for Scriml and getting other developers to try it.

🎥 Watch the Interview

[Insert your YouTube video link here]

👨💻 Meet the People Behind the Interview

Guest: Bryan MacLee
Host: Tom Smith

🌟 Building Something of Your Own?

CoderLegion Developer Spotlight celebrates developers, independent builders and people exploring new ideas.

If you're working on an interesting project, experimenting with a new technology or learning something challenging, we'd love to hear your story. Get involved in the community and you could be featured in a future Developer Spotlight.

🌐 Join the CoderLegion community

💬 Let's Discuss

If you could redesign one part of modern web development, what would you change and why?

Share your thoughts in the comments!

DeveloperSpotlight #Programming #WebDevelopment

Per-Tenant LLM Budgets: Stop One Customer From Spending Your Whole Model Bill

Fri, 02 Oct 2026 11:41:58 +0000

Picture a hypothetical B2B app with an AI assistant in every customer workspace. One customer wires it into a nightly job that loops over tens of thousands of documents, each sent with a long context and a generous max_tokens. Every request is valid and under the per-user rate limit. By morning that customer has spent more on model calls than they pay you in a year, and possibly everyone else's share too: on the Claude API, an organization that reaches its monthly spend cap gets HTTP 429 on every request until 00:00 UTC on the first day of the next month, unless it gets a higher limit sooner.

The fix is a per-tenant budget: the money each customer, and each user inside it, may spend on model calls in a window, checked before every call, settled from real usage after it, and reconciled against the provider's bill. It's the authorize-and-capture bookkeeping of card payments applied to tokens, and a standard piece of the multi-tenant AI products built in the production SaaS course at Cursuri-AI.ro.

The code uses the official anthropic Python SDK and Redis, with Postgres as the alternative. Retries, circuit breakers, agent stop conditions and tracing are separate layers and aren't repeated here. This is only about money: who spent it, how much is left, and what happens when it runs out.

Rate limits are not budgets

Most stacks already have a few kinds of limits. None of them is a budget.

The provider's rate limits protect the provider's capacity. On the Claude API they are measured in requests, input tokens and output tokens per minute, per model, for your whole organization, with a token bucket that refills continuously. They don't know which customer used the capacity, and they don't measure money: for most Claude models, cache reads don't count toward the input-tokens-per-minute limit, yet every one of them is billed.

The provider's spend limits measure money at the wrong granularity: the organization cap, or a lower one you set yourself, switches AI off for your whole product at once. Workspaces can carry their own spend and rate limits, which helps to isolate one very large customer, but prompt caches are isolated per workspace on the Claude API, so splitting traffic across workspaces also splits your cache hits.

Your own per-request rate limits bound how often someone calls, not what a call costs. Long context is billed at a flat per-token rate ("A 900k-token request is billed at the same per-token rate as a 9k-token request"), so cost scales with size. On Claude Opus 5.5, 2,000 input tokens and 500 output tokens cost just under 2 cents; about 870,000 input tokens plus the full 128K-token output cost about $6. Same endpoint, same rate-limit slot, a few hundred times the price.

A budget is an amount of money per tenant per window, reduced by what each call actually cost and checked before the next one starts.

Budget in money, not tokens

Tokens are the wrong unit because they don't have one price. A single Claude response reports up to five differently priced quantities:

Usage field	What it counts	Claude Opus 5.5, per million tokens
`input_tokens`	input after the last cache breakpoint	$4
`cache_creation_input_tokens`	input written to the prompt cache (5-minute / 1-hour TTL)	$5 / $8
`cache_read_input_tokens`	input read from the cache	$0.20
`output_tokens`	everything generated, thinking included	$20
`server_tool_use.web_search_requests`	web searches, if you enable the tool	$10 per 1,000

That's a 100× spread inside one model, and cache discounts differ by model: a cache hit costs 10% of the input price on most models, 5% on Claude Opus 5.5 and 2.5% on Claude Fable 5.1. Token quotas also drift. Per the pricing page, the tokenizer used by Claude 4.7 and later models "produces approximately 30% more tokens for the same text", so a per-token quota written for an older model shrinks after a migration.

Thinking is the part that catches people out. It is billed as output "even when the thinking text isn't returned to you", and with summarized thinking "the billed output token count does not match the count of tokens you see in the response" (thinking docs). Adaptive thinking is always on for Claude Opus 5.5, so never estimate cost from visible text. The Messages API reference calls usage.output_tokens "the inclusive, authoritative total used for billing", and output_tokens_details.thinking_tokens says how much of it was reasoning.

Keep budgets in integer micro-dollars. $4 per million tokens is exactly 4 micro-dollars per token, so pricing a response takes a few multiplications and one rounding step:

from decimal import Decimal, ROUND_CEILING

# USD per million tokens, from platform.claude.com/docs/en/about-claude/pricing
# (checked 2026-10-02). This is configuration, not code: reload it whenever prices or
# models change. $X per million tokens is exactly X micro-dollars per token.
_RAW_PRICES = {
    "claude-fable-5-1":  {"input": "10", "write_5m": "12.50", "write_1h": "20", "read": "0.25", "output": "50"},
    "claude-opus-5-5":   {"input": "4",  "write_5m": "5",     "write_1h": "8",  "read": "0.20", "output": "20"},
    "claude-sonnet-5-5": {"input": "2",  "write_5m": "2.50",  "write_1h": "4",  "read": "0.20", "output": "10"},
    "claude-haiku-4-5-20251001": {"input": "1", "write_5m": "1.25", "write_1h": "2", "read": "0.10", "output": "5"},
}
PRICES = {m: {k: Decimal(v) for k, v in row.items()} for m, row in _RAW_PRICES.items()}
WEB_SEARCH_MICROS = Decimal(10_000)   # $10 per 1,000 searches
US_ONLY = Decimal("1.1")              # inference_geo="us": 1.1x on every token category

def _ceil(x: Decimal) -> int:
    return int(x.to_integral_value(rounding=ROUND_CEILING))

def cost_micros(model: str, usage) -> int:
    """What one response cost, in micro-dollars, from its usage block."""
    p = PRICES[model]
    cc = getattr(usage, "cache_creation", None)
    if cc is not None:
        w5, w1h = cc.ephemeral_5m_input_tokens, cc.ephemeral_1h_input_tokens
    else:
        w5, w1h = usage.cache_creation_input_tokens or 0, 0
    tokens = (
        (usage.input_tokens or 0) * p["input"]
        + w5 * p["write_5m"]
        + w1h * p["write_1h"]
        + (usage.cache_read_input_tokens or 0) * p["read"]
        + usage.output_tokens * p["output"]          # thinking is in here
    )
    if getattr(usage, "inference_geo", None) == "us":
        tokens *= US_ONLY
    searches = usage.server_tool_use.web_search_requests if usage.server_tool_use else 0
    return _ceil(tokens + searches * WEB_SEARCH_MICROS)

The cache_creation object splits cache writes by TTL, and its values add up to cache_creation_input_tokens; without it, the function assumes 5-minute writes. The Batch API (50% off) and fast mode (its own rates) need rows of their own if you use them.

Reserve, call, settle

You can't know what a call costs until it's done, and you can't let it start unless the budget can absorb it. Card payments solved this long ago with authorization and capture:

Estimate the most the call can cost.
Reserve that amount atomically against the tenant's budget and the user's budget. If either can't absorb it, refuse now, before a single token is generated.
Call the model.
Settle: replace the reservation with the real cost from usage, which returns the unused part to the budget.

The estimate has two halves. Input comes from the token counting endpoint, which takes the same input as a Messages request, isn't billed, and has its own requests-per-minute limit. Its result is an estimate that "might differ by a small amount" and ignores caching, so price counted input at the highest rate the request can incur: the cache-write rate if it uses cache_control. Output is bounded by max_tokens, which includes all thinking in the current turn and is enforced as a strict limit. In the docs' words: "Effort is soft guidance. max_tokens is a strict limit."

import anthropic

client = anthropic.Anthropic()

COUNTABLE = {"model", "system", "messages", "tools", "tool_choice",
             "thinking", "output_config", "cache_control"}
COUNT_MARGIN = Decimal("1.02")   # the count is an estimate; the margin is your choice

def hold_micros(request: dict, cache_ttl: str | None = None, likely_cached: int = 0) -> int:
    """What to reserve for one call. With likely_cached=0 it is a true upper bound:
    every input token at the highest rate it can be billed at, plus max_tokens of output."""
    p = PRICES[request["model"]]
    counted = client.messages.count_tokens(
        **{k: v for k, v in request.items() if k in COUNTABLE}
    ).input_tokens
    in_rate = {None: p["input"], "5m": p["write_5m"], "1h": p["write_1h"]}[cache_ttl]
    fresh = max(counted - likely_cached, 0)
    return _ceil(
        fresh * COUNT_MARGIN * in_rate
        + likely_cached * p["read"]
        + request["max_tokens"] * p["output"]
    )

The counting endpoint rejects requests that use server tools (other than the advisor tool), the MCP connector, or images and documents passed by url or file; for those features, reserve from a configured ceiling. And count with the model you're about to call, since tokenizers differ between generations.

The guarded call is short; reserve and settle come next.

def call_with_budget(c: "Caller", request: dict, request_id: str, hold: int | None = None):
    keys = budget_keys(c, request_id)
    hold = hold if hold is not None else hold_micros(request)
    reserve(c, keys, hold)                    # raises BudgetExceeded or DuplicateRequest
    try:
        response = client.messages.create(**request)
    except anthropic.APIStatusError:
        settle(keys, 0)        # an error response: no message, no usage to settle
        raise
    except anthropic.APIConnectionError:
        settle(keys, hold)     # outcome unknown (timeout, dropped connection): charge the hold
        raise
    settle(keys, cost_micros(request["model"], response.usage))
    record_in_ledger(c, request_id, request["model"], response.usage)
    return response

The request_id is the idempotency key, so it must stay stable across retries of one logical request: take it from the client's idempotency header or your job ID, never from a fresh UUID per attempt. Getting usage right across caching, tools and streaming is much of the day-to-day work of running LLM integrations in production, and it's the only reliable input a budget has.

The reservation: one atomic step

The check and the decrement must be one operation. Two concurrent requests that both read "enough left" and both proceed is the classic overspend, and parallel agent calls make it common. In Redis, a Lua script does it: "Redis guarantees the script's atomic execution", and a script "can perform conditional updates across multiple keys" (Redis docs), here the tenant's budget and the user's budget in one step.

Each budget is a hash with three fields: limit, committed (settled spend) and held (open reservations). Each reservation is a small hash of its own, indexed by deadline in a per-tenant sorted set so abandoned ones can be found.

-- reserve.lua
-- KEYS[1] tenant budget   KEYS[2] user budget   KEYS[3] hold   KEYS[4] holds index
-- ARGV[1] amount in micro-USD   ARGV[2] hold deadline (unix ms)
if redis.call('EXISTS', KEYS[3]) == 1 then
  return 'duplicate'                      -- this request ID already reserved
end

local amount = tonumber(ARGV[1])
for i, key in ipairs({KEYS[1], KEYS[2]}) do
  local b = redis.call('HMGET', key, 'limit', 'committed', 'held')
  if not b[1] then
    return 'no_budget'                    -- fail closed: no limit configured
  end
  local left = tonumber(b[1]) - (tonumber(b[2]) or 0) - (tonumber(b[3]) or 0)
  if amount > left then
    if i == 1 then return 'tenant' end
    return 'user'
  end
end

redis.call('HINCRBY', KEYS[1], 'held', ARGV[1])
redis.call('HINCRBY', KEYS[2], 'held', ARGV[1])
redis.call('HSET', KEYS[3], 'amount', ARGV[1], 'state', 'held',
           'tenant_key', KEYS[1], 'user_key', KEYS[2])
redis.call('ZADD', KEYS[4], ARGV[2], KEYS[3])
return 'ok'

Three details matter. The script fails closed: a budget without a limit refuses. Every key it touches arrives through KEYS, since Redis requires that "all names of keys that a script accesses must be explicitly provided as input key arguments". And every key name carries the tenant ID as a hash tag, {tenant}, which puts all of a tenant's keys in one Redis Cluster hash slot, so the multi-key script survives sharding.

The Python side builds the keys, opens the month's budgets lazily, and turns verdicts into exceptions:

import time
from dataclasses import dataclass
from datetime import datetime
from zoneinfo import ZoneInfo

import redis

r = redis.Redis(decode_responses=True)
reserve_script = r.register_script(open("reserve.lua").read())
settle_script = r.register_script(open("settle.lua").read())

HOLD_TTL_MS = 15 * 60 * 1000    # longer than your slowest call, retries included
TOMBSTONE_S = 7 * 24 * 3600     # how long a finished request ID stays deduplicated

@dataclass
class Caller:
    tenant_id: str
    user_id: str
    tz: str               # the tenant's billing time zone, e.g. "Europe/Bucharest"
    tenant_limit: int     # micro-USD per month, from the tenant's plan
    user_limit: int       # micro-USD per month for this user; equal to tenant_limit = no user cap

class BudgetExceeded(Exception):
    def __init__(self, scope: str, resets_at: datetime | None = None):
        super().__init__(scope)
        self.scope, self.resets_at = scope, resets_at

class DuplicateRequest(Exception):
    pass

def budget_keys(c: Caller, request_id: str) -> list[str]:
    period = datetime.now(ZoneInfo(c.tz)).strftime("%Y-%m")
    t = "{" + c.tenant_id + "}"   # hash tag: one cluster slot per tenant
    return [f"budget:{t}:{period}", f"budget:{t}:user:{c.user_id}:{period}",
            f"hold:{t}:{request_id}", f"holds:{t}"]

def next_reset(tz: str) -> datetime:
    now = datetime.now(ZoneInfo(tz))
    year, month = (now.year + 1, 1) if now.month == 12 else (now.year, now.month + 1)
    return datetime(year, month, 1, tzinfo=ZoneInfo(tz))

def reserve(c: Caller, keys: list[str], amount: int) -> None:
    r.hsetnx(keys[0], "limit", c.tenant_limit)   # open this month's budgets on first use
    r.hsetnx(keys[1], "limit", c.user_limit)
    deadline = int(time.time() * 1000) + HOLD_TTL_MS
    verdict = reserve_script(keys=keys, args=[amount, deadline])
    if verdict == "duplicate":
        raise DuplicateRequest(keys[2])
    if verdict != "ok":
        raise BudgetExceeded(verdict, next_reset(c.tz))

def settle(keys: list[str], cost: int, mode: str = "settle") -> str:
    return settle_script(keys=keys, args=[cost, mode, TOMBSTONE_S])

A new month opens the first time someone spends in it, at the limit the tenant's plan has at that moment. A plan change mid-month is a plain HSET of limit.

Settlement: idempotent, and never refused

Settlement follows two rules. It must be idempotent, because whatever calls it will be retried: your queue, your web framework, a user clicking twice. And it must never refuse: by the time you settle, the money is spent, and the budget's job is to record it. If the real cost exceeds the hold (the input count was an estimate), the budget goes slightly over; the overshoot is bounded by your margin and visible in the metrics.

-- settle.lua
-- KEYS: the same four as reserve.lua
-- ARGV[1] real cost in micro-USD   ARGV[2] 'settle' or 'expire'   ARGV[3] tombstone TTL (s)
local h = redis.call('HMGET', KEYS[3], 'amount', 'state')
local held, state = tonumber(h[1]), h[2]
if not state then return 'unknown' end            -- never reserved, or tombstone gone
if state == 'settled' then return 'duplicate' end
if ARGV[2] == 'expire' and state ~= 'held' then return 'noop' end

local cost = tonumber(ARGV[1])
if ARGV[2] == 'expire' then cost = held end       -- the worker vanished: assume the worst

local delta = cost
if state == 'held' then
  redis.call('HINCRBY', KEYS[1], 'held', -held)
  redis.call('HINCRBY', KEYS[2], 'held', -held)
else                                              -- 'expired': the full hold was charged
  delta = cost - held
end
redis.call('HINCRBY', KEYS[1], 'committed', delta)
redis.call('HINCRBY', KEYS[2], 'committed', delta)
local final_state = 'settled'
if ARGV[2] == 'expire' then final_state = 'expired' end
redis.call('HSET', KEYS[3], 'state', final_state, 'cost', cost)
redis.call('ZREM', KEYS[4], KEYS[3])
redis.call('EXPIRE', KEYS[3], ARGV[3])
return 'ok'

Finished holds stay behind as tombstones with a TTL, so a duplicate settle does nothing. A settle that arrives after its hold was expired (next section) corrects the charge from the full hold down to the real cost. And because the budget keys live in the hold, a call reserved at 23:59 on the last day of the month settles against the month it was reserved in.

Keep a durable record next to the gate. The Redis Cluster specification says "usually there are small windows where acknowledged writes can be lost", which is acceptable for a gate and not for a ledger. Write every settled call to an append-only table, and rebuild committed from it if Redis is ever lost or wrong:

CREATE TABLE llm_ledger (
    request_id   TEXT        PRIMARY KEY,   -- the same ID as the Redis hold
    tenant_id    TEXT        NOT NULL,
    user_id      TEXT        NOT NULL,
    model        TEXT        NOT NULL,
    usage        JSONB       NOT NULL,      -- the raw usage block, so history can be re-priced
    cost_micros  BIGINT      NOT NULL,
    created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);
-- record_in_ledger() is INSERT ... ON CONFLICT (request_id) DO NOTHING

Storing the raw usage, not only the cost, turns a mistake in the price table into a re-computation instead of a loss.

Holds that never come back

A worker that reserves and then dies (OOM-killed, deployed over, cut off by the network) leaves a hold nobody will settle, and those holds eat the budget until a tenant is refused with money left on paper. Give each hold a deadline longer than your slowest legitimate call, retries included, and sweep:

def sweep_expired_holds(tenant_id: str, batch: int = 100) -> int:
    """Run every minute or so, for each tenant with a holds index (SCAN for holds:*)."""
    index = "holds:{" + tenant_id + "}"
    now_ms = int(time.time() * 1000)
    expired = 0
    for hold_key in r.zrangebyscore(index, "-inf", now_ms, start=0, num=batch):
        h = r.hgetall(hold_key)
        if not h:
            r.zrem(index, hold_key)
            continue
        keys = [h["tenant_key"], h["user_key"], hold_key, index]
        if settle_script(keys=keys, args=[0, "expire", TOMBSTONE_S]) == "ok":
            expired += 1
    return expired

Charging the full hold is the conservative default: the worker may have finished the call before it died, and there's no usage to prove otherwise. If you'd rather absorb that cost, release the hold at zero instead. Either way, count expired holds; a rising number means something crashes between reserve and settle.

If Postgres is your gate. The same design works without Redis. A conditional UPDATE is the check, the row lock makes it atomic, and a missing row in RETURNING means refused:

-- One row per budget: (tenant, period) and (tenant, user, period).
-- In one transaction: commit if both rows come back, roll back otherwise.
UPDATE llm_budget
   SET held = held + %(amount)s
 WHERE budget_key IN (%(tenant_key)s, %(user_key)s)
   AND committed + held + %(amount)s <= limit_micros
RETURNING budget_key;

You get durability, and the ledger insert can share the transaction. The price is that every request from one tenant serializes on that tenant's budget row, so measure before you pick a side.

Streaming: the bill arrives at the end

Streaming changes when you learn the cost, not what it is. The documented event flow is message_start, the content blocks, one or more message_delta events, then message_stop. Input usage, cache reads and writes included, sits in the Message inside message_start. The output count comes in message_delta, and "the token counts shown in the usage field of the message_delta event are cumulative." Two consequences follow.

Settle from the final usage, not the first. The SDK's accumulator overwrites its snapshot with each cumulative count, so settle on the usage of stream.get_final_message(). Input can change too: the docs' server-tool example shows a larger input_tokens in the final message_delta than in message_start.

There is no running output meter. Content deltas carry text, not token counts, and when thinking is omitted or summarized the visible text undercounts what you pay for. So you can't stop a stream "when it hits the budget" by counting what you've seen. The hard stop for one call is max_tokens, set before it starts: when a tenant is low, size max_tokens from what's left (shown below) and let the API enforce it.

def stream_with_budget(c: Caller, request: dict, request_id: str, hold: int | None = None):
    keys = budget_keys(c, request_id)
    hold = hold if hold is not None else hold_micros(request)
    reserve(c, keys, hold)
    settled = False
    try:
        with client.messages.stream(**request) as stream:
            for text in stream.text_stream:
                yield text            # a client disconnect arrives here as GeneratorExit
            final = stream.get_final_message()
        settle(keys, cost_micros(request["model"], final.usage))
        settled = True
        record_in_ledger(c, request_id, request["model"], final.usage)
    finally:
        if not settled:
            # Aborted or failed mid-stream: the final message_delta never arrived, and
            # thinking you never saw was still generated. Charge the hold; reconcile later.
            settle(keys, hold)

When the user closes the tab, you have two honest options: charge the hold (conservative) or estimate from what you streamed (generous, and blind to thinking). Choose deliberately, and let reconciliation show what the choice costs.

Agent loops: budget the step, not the session

An agent run is a series of model calls with tools in between, and its context grows at every step. Reserving for the whole session up front looks tidy and behaves badly: the pessimistic total is locked away from the tenant's other users for the whole run, and a crash leaks all of it. Reserve per step instead, each step with its own reserve, call, settle and idempotency key, and give the run a ceiling of its own on top.

STEP_MAX_TOKENS = 8_000      # per-step output cap, whatever the feature's default is

def agent_step(c: Caller, run: dict, request: dict, cache_ttl: str | None = "5m"):
    request = {**request, "max_tokens": min(request["max_tokens"], STEP_MAX_TOKENS)}
    hold = hold_micros(request, cache_ttl, likely_cached=run["cached_prefix"])
    if run["spent"] + hold > run["ceiling"]:
        raise BudgetExceeded("run")           # the run's own cap, separate from the month
    response = call_with_budget(c, request, f"{run['id']}:{run['step']}", hold=hold)
    u = response.usage
    run["spent"] += cost_micros(request["model"], u)
    run["cached_prefix"] = (u.cache_read_input_tokens or 0) + (u.cache_creation_input_tokens or 0)
    run["step"] += 1
    return response

The per-step max_tokens cap stops one runaway step from eating the run's allowance. likely_cached fixes a quieter problem: after the first step, most of an agent's input is the conversation so far, already in the cache. On Claude Opus 5.5 that prefix costs $0.20 per million tokens as a cache read and $5 as a 5-minute cache write. Reserve it at the write rate and late-run reservations come out many times too large, refusing tenants who still have budget; price it as a read and accept a small overshoot when the cache misses. The run's other stop conditions belong to the loop, which is the territory of designing agents that stay inside their limits.

Soft limits degrade, hard limits refuse

Give every budget two thresholds. Past the soft one, keep serving but spend less:

Route new conversations to a cheaper model. Claude Sonnet 5.5 costs $2/$10 per million input/output tokens against $4/$20 for Opus 5.5, but its cache reads cost the same $0.20, so cache-heavy workloads save less than the headline suggests. Don't switch in the middle of a conversation: Sonnet 5.5 can't read Opus 5.5's thinking blocks, so the earlier turns' reasoning is dropped.
Lower the effort. On Claude Opus 5.5 the effort docs call effort "the primary control for how much the model reasons and what a request costs". Changing it invalidates the cached message blocks, so this too is a decision for the start of a conversation.
Shrink max_tokens to what the budget can still pay for.

A cheaper model isn't automatically a cheaper answer. Sonnet 5.5 defaults to high effort where Opus 5.5 defaults to medium, so compare cost per finished task on your own traffic, not price per token.

SOFT_LIMIT = Decimal("0.80")   # a starting point; tune it per product
CHEAPER = {"claude-fable-5-1": "claude-opus-5-5", "claude-opus-5-5": "claude-sonnet-5-5"}
MIN_USEFUL_OUTPUT = 1_024      # below this, refuse instead of returning a stub

def headroom(c: Caller, keys: list[str]) -> tuple[int, Decimal]:
    """(micro-USD left, share used) for the tighter of the two budgets. For routing only:
    the reservation script remains the only check that counts."""
    left, used = None, Decimal(0)
    for key, default in ((keys[0], c.tenant_limit), (keys[1], c.user_limit)):
        limit, committed, held = r.hmget(key, "limit", "committed", "held")
        limit = int(limit or default)
        spent = int(committed or 0) + int(held or 0)
        left = limit - spent if left is None else min(left, limit - spent)
        used = max(used, Decimal(spent) / limit if limit > 0 else Decimal(1))
    return left, used

def plan_call(c: Caller, keys: list[str], request: dict, new_conversation: bool) -> tuple[dict, int]:
    left, used = headroom(c, keys)
    if used >= SOFT_LIMIT and new_conversation and request["model"] in CHEAPER:
        request = {**request, "model": CHEAPER[request["model"]]}
    p = PRICES[request["model"]]
    input_hold = hold_micros({**request, "max_tokens": 0})
    affordable = int(Decimal(left - input_hold) / p["output"])
    # Never go below the floor: if even that doesn't fit, the reservation refuses,
    # and it knows which budget (tenant or user) ran out.
    max_tokens = max(MIN_USEFUL_OUTPUT, min(request["max_tokens"], affordable))
    return {**request, "max_tokens": max_tokens}, input_hold + _ceil(max_tokens * p["output"])

The floor matters on models with thinking always on: a call squeezed to a few hundred output tokens can spend them all reasoning and stop with stop_reason: "max_tokens" before saying anything useful. The tenant pays and gets nothing.

Past the hard threshold, refuse, clearly and honestly. Not a generic 500, not an endless spinner, not a silent switch to worse answers. A good refusal says what happened, whose budget it was, when it resets and who can change it, with an error code that tells clients not to retry:

REFUSALS = {
    "tenant": "Your organization has used this month's AI budget.",
    "user": "You've used your share of your organization's AI budget for this month.",
    "run": "This task reached its spending cap before it finished.",
}

def refusal_body(e: BudgetExceeded) -> dict:
    reason = REFUSALS.get(e.scope, REFUSALS["tenant"])
    resets = e.resets_at
    return {
        "error": "ai_budget_exhausted",     # distinct code: clients must not auto-retry
        "scope": e.scope,
        "resets_at": resets.isoformat() if resets else None,
        "message": reason + (f" It resets on {resets.day} {resets:%B %Y}." if resets else "")
                   + " An administrator can raise the limit in billing settings.",
    }

The message never implies the allowance was open-ended. The plan had an AI budget, and this is it.

Two levels, because the tenant pays and users spend. The tenant budget protects your margin; the per-user budget inside it protects the tenant's other employees from one colleague's batch job. Let the tenant's administrator set the per-user share, and check both in one atomic step, as the Lua script does, so a reservation that fits the user but not the tenant never half-commits.

Windows need a time zone. "Resets on the 1st" should mean midnight where the customer is, so the window key uses the tenant's billing time zone. Keep ledger timestamps in UTC anyway: the provider's cost buckets are UTC days.

Reconcile against the provider's numbers

Your ledger is a model of the bill, so check it against the bill. Anthropic's Usage and Cost Admin API has two endpoints. /v1/organizations/usage_report/messages reports tokens in 1-minute, 1-hour or 1-day buckets, groupable by API key, workspace, model, service tier and a few more dimensions. /v1/organizations/cost_report reports USD costs in daily buckets, groupable by workspace or by description, which carries the model. Both need Admin API credentials such as an Admin API key (sk-ant-admin01-...), they aren't available to individual accounts, and data "typically appears within 5 minutes of API request completion".

from collections import defaultdict

import httpx

def provider_cost_by_model(starting_at: str, ending_at: str, admin_key: str) -> dict[str, Decimal]:
    """Micro-dollars per model (or per non-token cost type) for whole UTC days."""
    totals: dict[str, Decimal] = defaultdict(Decimal)
    params = {"starting_at": starting_at, "ending_at": ending_at, "group_by[]": "description"}
    while True:
        resp = httpx.get(
            "https://api.anthropic.com/v1/organizations/cost_report",
            params=params,
            headers={"x-api-key": admin_key, "anthropic-version": "2023-06-01"},
        )
        resp.raise_for_status()
        body = resp.json()
        for bucket in body["data"]:
            for item in bucket["results"]:
                # "amount" is a decimal string in cents: "123.45" means $1.23
                totals[item["model"] or item["cost_type"]] += Decimal(item["amount"]) * 10_000
        if not body["has_more"]:
            return totals
        params["page"] = body["next_page"]

Compare the totals per model and UTC day with the sum of cost_micros in your ledger. None of the provider's dimensions is your customer, so reconciliation checks totals and your ledger does the attribution. When they disagree, the usual suspects are a stale price table, a code path that calls the model around the guard (background jobs and new features are the classics), aborted streams and expired holds, or a pricing modifier you didn't model. Priority Tier costs aren't in the cost endpoint; track them through the usage endpoint. Pick a drift threshold and alert on it.

Four numbers to watch

Settled cost per tenant, against time elapsed in the window. A tenant at 60% of the month's budget on day 5 is a conversation for this week, not day 12. That's burn rate, the idea SRE teams apply to error budgets, and operating AI workloads with SRE discipline takes it well beyond cost.
Refusal and degrade rates, split by scope (tenant, user, run). A rising user-scope rate inside one tenant usually means the per-user shares are wrong, not that anyone is misbehaving.
Reserved versus settled, per feature. Reserving ten times what you spend means refusing tenants who still have budget; tighten that feature's max_tokens rather than raising the limit.
Expired holds and reconciliation drift. Both should sit near zero and stay flat. Either one climbing means something crashes between reserve and settle, or calls the model around the guard.

Keep per-tenant cost in the ledger rather than as a label on a high-cardinality time series. If you trace model calls already, put the tenant ID and settled cost on the call's span, so an expensive request leads straight to its customer.

FAQ

Why not count tokens per tenant instead of money?
Because tokens don't have one price: inside one model an output token costs 100 times a cache read, and newer tokenizers change the count for the same text. Money is the only unit that matches the bill you pay.

Redis or Postgres for the budget?
Redis for the gate when request rates are high and latency matters, Postgres for the ledger in every case. Postgres alone is a fine gate while no single tenant's traffic makes its budget row a hot spot.

The short version

Provider rate limits and spend caps protect the provider and your organization as a whole. Neither knows your customers.
Budget in micro-dollars, priced from every usage field, with thinking counted as output.
Reserve the worst case atomically against tenant and user, call, then settle idempotently from real usage. Settlement never refuses.
Expire abandoned holds and keep a durable ledger behind the Redis gate.
In streams, usage arrives at the end, so the hard stop is max_tokens sized from what's left.
Reserve per agent step, cap each step, and price the cached prefix as a cache read.
Degrade at the soft limit, refuse honestly at the hard one, and reconcile daily against the Cost API.

None of this makes a call cheaper. It makes every call's cost belong to someone, which you need before you can price the feature, sell it to larger customers, or sleep through a customer's nightly batch job.

Metering, tenancy and billing are the unglamorous half of every AI product. For the full path from prototype to paying customers, see the hands-on course on shipping a production AI SaaS on Cursuri-AI.ro, Eastern Europe's AI education platform.

Claude Fable 5.1 Made Your Conversation History Append-Only

Wed, 02 Sep 2026 13:45:11 +0000

There is a 400 error in Claude Fable 5.1 that you will probably not see in development, will not see in staging, and will see in production — from users whose API accounts are newer than yours.

messages.5.content.0: Invalid `signature` in `thinking` block. The block is
bound to a different conversation. Remove the block, or set
`thinking.block_binding.prefix_mismatch_behavior` to "drop_block".

It fires when your code does something that has been completely normal for two years: modifying the conversation history you send back to the model. Trimming an old turn. Swapping in a summary. Rebuilding the tools array between requests. Editing a previous assistant message before replaying it.

On claude-fable-5-1, released 1 September 2026, conversation history is effectively append-only. This piece is about what that means in code, which patterns just became illegal, what replaced them, and why the person who maintains an agent framework is the last to find out.

What a thinking block is actually bound to

Fable 5.1 runs adaptive thinking always on — it cannot be disabled, and thinking: {type: "disabled"} returns a 400 at any effort level. Every response therefore carries thinking blocks, and you pass them back on subsequent turns.

Those blocks are not inert payload. Each one carries a signature, and the documentation is precise about what it covers:

Each thinking block from Claude Fable 5.1 is valid only against the system prompt, tools, and conversation history that preceded it.

Three things, then, are frozen for the life of a thinking block:

The system prompt as it was when the block was produced.
The tools array as it was when the block was produced.
Every message that came before it, byte for byte.

Change any one and send the block back, and the request is rejected. Not degraded — rejected, with a permanent error for that request body. As the docs put it: an automatic retry loop won't clear it.

There is a second binding on top of the first: blocks record which model produced them. Fable 5.1 reads its own blocks and those from Mythos 5.1, Opus 5, Fable 5, Mythos 5, and earlier models — so a conversation moving up to Fable 5.1 keeps its reasoning. The relationship is one-way. Apart from Mythos 5.1, none of those models can read Fable 5.1's blocks, so a conversation moving down to Opus 5 drops them.

Why you will find out last

This is the part worth reading twice, because it inverts the usual order of discovery.

The API enforces the check for new accounts created on or after August 31, 2026. For accounts created earlier, the API records the mismatch but doesn't act on it unless the request sets thinking.block_binding.prefix_mismatch_behavior, which opts into enforcement.

Your account is almost certainly older than 31 August 2026. Your CI account is older. Your team's accounts are older. On all of them, the API quietly notes the mismatch and serves the request anyway.

Your users' accounts are not older. Anyone who signed up this week is enforced by default.

Anthropic states the trap plainly: if you ship a tool or framework that people run with their own API key, test with the field set before launch, because your key is probably on an older account and your users on new ones hit the check before you do. And the reprieve is temporary — enforcement is planned for every account on future models.

So the practical reading is: this is a deadline, not an outage. You have one model generation to make your history handling append-only, and a free way to test against the future today.

To find out where your own account stands, send a request that edits history without the beta header. A 400 that names the header means you're enforced.

The patterns that are now illegal

If Claude Code, claude.ai, Claude Managed Agents, or the Claude Agent SDK owns your conversation history, they already keep the prefix intact and none of this applies. If your code builds the messages array itself, all of it applies. Here is the list, roughly in order of how common it is in real codebases.

1. Client-side truncation and summarization

The classic loop: when the conversation exceeds N tokens, drop or summarize the oldest turns and send the shortened array. Every thinking block after the edit point is now bound to a prefix that no longer exists.

2. Snipping a turn out of the middle

The worst case, and the one with no client-side workaround at all. The docs are blunt: don't do it — that invalidates every later thinking block and no client-side shape avoids it.

3. Rebuilding `system` or `tools` per request

Easy to do by accident. A system prompt that interpolates the current date, a tools array assembled from a dict in non-deterministic order, a feature flag that adds a tool mid-session — each one changes the bound prefix. This is also, not coincidentally, the same class of bug that destroys your prompt cache hit rate; the two failures have exactly one root cause.

4. Keep-tail compaction

Summarize the old turns, keep the last few verbatim behind the summary. Those recent turns carry thinking produced against the full history, and they now sit behind a summary that replaced it. They fail.

5. Background compaction

Build the summary off the critical path, swap it in when ready. Every turn produced between the snapshot and the swap carries thinking that predates the new prefix.

6. Editing assistant turns for control

Rewriting a previous assistant message to steer the model, injecting synthetic assistant turns as few-shot examples mid-conversation, replaying a "corrected" version of what the model said. This family of techniques is what the change is aimed at — Anthropic frames it as an anti-distillation measure, describing it as no longer being possible for new API accounts to manually edit Claude's prior context in a multi-turn conversation while preserving the transcript of Claude's prior thinking.

Note that assistant prefill was already removed across the 4.6+ family, returning a 400. If you were reaching for prefill as the workaround here, that door closed first.

The three legal shapes for client-side compaction

You do not have to give up compaction. You have to pick a shape that carries no stale thinking. The documentation names three:

Simple compaction — the recommended one. Replace the entire history with one summary message plus the new user turn, and replay nothing else. No thinking blocks carry over, so nothing can mismatch. The docs note that Claude models are trained on long-horizon tasks with exactly this scheme and that it performs comparably to more elaborate approaches for most workloads. If you are choosing today, choose this.

Keep-tail compaction. If you insist on keeping recent turns verbatim behind a summary, strip the thinking and redacted_thinking blocks from those turns — text and tool calls can stay — or opt into drop_block.

Background compaction. If the summary is built asynchronously and swapped in later, send drop_block on every request that still carries thinking produced before the swap, strip those blocks yourself, or compact synchronously and accept the latency.

The better answer: stop editing on the client

All three shapes above are ways to keep doing the work in the wrong place. The cleaner fix is to move context management to the server, where it doesn't count as an edit at all:

Server-side compaction (beta header compact-2026-01-12) summarizes earlier context when the conversation approaches a threshold, and its instructions parameter accepts your own summarization prompt — so you keep editorial control over what survives.
Context editing (beta context-management-2025-06-27) clears old tool results or thinking blocks with strategies like clear_tool_uses_20250919 and clear_thinking_20251015.

The reason these are safe is precise and worth internalizing: the history check compares the conversation as you sent it. Anything the server removes after that point cannot invalidate a later thinking block.

One caveat if you adopt server-side compaction: append response.content back to your messages on every turn, not just the extracted text. Compaction blocks in the response are how the API replaces the compacted history on the next request. Pull out the string and append that, and you silently lose the compaction state.

For the mid-session changes you used to make by rewriting the prefix, there are now first-class channels. A role: "system" message appended to messages[] changes instructions without touching the cached prefix. Tool changes go through tool_addition / tool_removal blocks (beta mid-conversation-tool-changes-2026-07-01, with the full tool set declared at session start). Per-turn reminders go in turn-scoped system messages that you leave in the history — they stop rendering after the next user message and cost no tokens once cleared.

That is the mental shift the whole release is asking for: you no longer edit the conversation, you append instructions to it. If your agent architecture treats messages as a mutable buffer you rewrite each turn, that assumption is what needs to change — a design question we spend real time on in the agent architecture course.

The escape hatch, and why it isn't a fix

Send the beta header thinking-binding-controls-2026-08-01 and set prefix_mismatch_behavior to "drop_block" (the default is "error"):

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "block_binding": {"prefix_mismatch_behavior": "drop_block"},
    },
    messages=messages,
)

for t in getattr(response, "input_transformations", []) or []:
    if t.reason == "prefix_binding_mismatch":
        log.warning("dropped thinking block: %s", t)

Instead of a 400, the API drops the mismatched block and every thinking block after it, reporting each one in the response's input_transformations array with reason: "prefix_binding_mismatch".

Understand the trade. You are not fixing the mismatch, you are discarding the model's preserved reasoning from that point forward and paying for it in quality on exactly the long-horizon tasks you bought Fable 5.1 for. Use drop_block as a shock absorber and a diagnostic — not as your architecture.

The other breaking change in the same release

While you're in the migration, there is a second one that hits a completely different code path. Forced tool choice is gone. Fable 5 accepted tool_choice values auto, none, any, and tool. On claude-fable-5-1, {type: "any"} and {type: "tool", name: "..."} return a 400:

tool_choice: type "tool" and "any" are not supported for this model.

The check applies on the Messages API, the Message Batches API, and the token counting endpoint — so a token-counting call in your cost estimator will fail too, which is a fun way to discover it.

If you used forced tool choice to guarantee structured output, the replacement is {type: "auto"} plus an explicit instruction and strict: true on the tool, or structured outputs via output_config.format. If your application genuinely requires a specific call on the current turn, put the instruction in the user turn or in a mid-conversation role: "system" message. Structured extraction pipelines built on forced tool choice are the most likely thing in your codebase to break on the model ID swap alone — the structured outputs approach is the durable replacement.

A 20-minute audit

Run this before you switch traffic, not after.

Decide whether you're exposed at all. Does your code construct the messages array? If a managed harness owns it, you're done.
Grep for the mutation. Look for anything that slices, pops, filters, or rewrites a messages list; anything that rebuilds system or tools per request; anything that sorts or serializes tool schemas non-deterministically.
Turn on enforcement deliberately. Run a representative multi-turn session with thinking-binding-controls-2026-08-01 and prefix_mismatch_behavior: "drop_block", and log every entry in input_transformations. Each prefix_binding_mismatch is a real bug in your history handling. model_binding_mismatch entries after a deliberate model switch are expected and fine.
Fix the shape, not the symptom. Move trimming server-side, or adopt simple compaction.
Freeze the prefix. System prompt and tools set once at session start; every mid-session change goes through a role: "system" message.
Replace forced tool_choice. Including in token-counting calls.
Pick a production prefix_mismatch_behavior and monitor it. "error" fails loudly; "drop_block" degrades quietly. Both are defensible — an unmonitored default is not.
If you ship a framework, test with the field set. Your users' accounts are newer than yours.

Steps 2 and 3 are the ones that find real bugs. Everything else is bookkeeping.

Why this is happening

It is worth understanding the motivation, because it tells you which direction the next release moves.

The ability to hand a model an edited transcript of its own prior reasoning is the core primitive in distillation attacks — you reconstruct a frontier model's reasoning by feeding it modified versions of what it previously produced and observing how it continues. Binding each thinking block to the exact prefix that produced it closes that off without removing the block from the API surface.

It sits alongside the other provenance measure shipped in the same release: models released after 2 August 2026 carry a watermark in their text output — described as a numerical way of determining the likelihood that Claude was involved in writing a piece of text — invisible to anyone without the detection API.

Both point the same way. The frontier vendors are hardening the boundary around model outputs, and the API surface is getting less malleable with each release. Building on the assumption that you can freely rewrite what the model produced is now building against the direction of travel. That is a security and architecture judgement as much as an API one — the kind of reasoning we work through in the AI security course, and in the Claude Code and agentic coding course for teams building harnesses of their own.

The short version

On Fable 5.1, each thinking block is bound to the system, tools, and history that preceded it. Edit any of them and the request is a 400.
Enforced by default for accounts created on or after 31 August 2026. Older accounts are unaffected for now — Anthropic plans to enforce it for everyone on future models.
If you ship a framework, your users are enforced before you are. Test with thinking-binding-controls-2026-08-01 and prefix_mismatch_behavior: "drop_block".
Client-side trimming, keep-tail summaries, background compaction swaps and mid-transcript snipping all break. Simple compaction, server-side compaction, and context editing don't.
Forced tool_choice (any / tool) is also gone — a 400, including on token counting.
Freeze the prefix; append instructions instead of editing history.

If you're planning a context strategy change off the back of this, there's a money-side companion to it: Fable 5.1 also cut cache reads to $0.25/MTok, which makes summarizing-to-save-money a losing trade in most cases. I wrote that up on dev.to as "Fable 5.1 Cache Reads Cost $0.25/MTok." The two decisions interact — the cheap path and the legal path happen to be the same one, which is unusually convenient.

Every behavior, error string, header and date in this article was checked against Anthropic's official documentation on 2 September 2026 — principally the Fable 5.1 migration guide and the preserved thinking guide. Beta headers and enforcement dates change; verify against current docs before shipping.

I released oteldoctor v0.1.0 — an open-source Go CLI for checking OpenTelemetry Collector config

Fri, 22 May 2026 14:34:21 +0000

OpenTelemetry Collector configs are easy to grow and hard to reason about.

A config can be valid and still have production risks:

exporters:
  otlphttp:
    endpoint: http://backend.example.com
    headers:
      X-API-KEY: "hardcoded-secret"

or:

service:
  pipelines:
    traces:
      processors: [batch, memory_limiter]

These are the kinds of things oteldoctor is designed to catch.

What it does

oteldoctor checks:

undefined receivers/processors/exporters
missing memory_limiter
wrong processor order
missing retry/queue config
hardcoded secrets
plain HTTP exporters
debug exporters in production
high-cardinality attributes
missing sampling/filtering hints
semantic convention issues
Kubernetes readiness gaps

Commands

oteldoctor analyze ./deploy --profile production
oteldoctor analyze ./deploy --format json
oteldoctor analyze ./deploy --format sarif > oteldoctor.sarif
oteldoctor graph collector.yaml --format mermaid
oteldoctor explain OTEL-SEC-202
oteldoctor fix collector.yaml --dry-run

Install

go install github.com/firfircelik/oteldoctor/cmd/oteldoctor@v0.1.0

Why it exists

This is not a replacement for Collector validation.

It is more like a production-readiness layer for Collector configs.

The goal is to catch reliability, security, cost, semantic, and Kubernetes deployment risks earlier — ideally in CI, before the config is deployed.

GitHub: https://github.com/firfircelik/oteldoctor

If you work with OpenTelemetry Collector, I’d really appreciate feedback, issue reports, and real-world config edge cases.

Nowadays, LLM is based and major for me

Mon, 11 May 2026 04:56:55 +0000

https://github.com/topstar-ai/OpenLLM
https://bentoml.com

Run any open-source LLMs, such as DeepSeek and Llama, as OpenAI compatible API endpoint in the cloud.

Why Users Don’t Trust Your Product (Even When It Works Perfectly)

Sat, 02 May 2026 14:16:11 +0000

A product can work perfectly…

And still feel unreliable.

I’ve seen this happen more times than people realize.

No bugs.
No crashes.
No major issues.

But users hesitate.

They second-guess.
They get stuck.
They don’t move forward with confidence.

The Problem Isn’t Always Technical

Most teams assume:

“If users don’t trust the product, something must be broken.”

But often, nothing is broken.

It just doesn’t feel clear.

Where Trust Actually Comes From

Users don’t trust your product because it works.

They trust it because they understand what’s happening.

That means:

• They know what to do next
• They understand what just happened
• They can predict what will happen after

Without that…

Even a working system feels confusing.

What Breaks Trust

Here are a few subtle things that quietly reduce user confidence:

Unclear next steps
After completing an action, users don’t know what to do next.
Silent systems
The product does something… but doesn’t explain it.
Overloaded explanations
Too much information at once makes users unsure what matters.
Assumed knowledge
Users are expected to understand things that were never explained.

What I’ve Learned Working on Documentation

When users feel lost, they don’t say:

“This system lacks clarity.”

They say:

“This feels confusing.”
“I’m not sure if I’m doing this right.”

And that’s where trust starts breaking.

The Fix Is Simpler Than You Think

You don’t always need more features.

You don’t even need more content.

You need:

Clear guidance at the right moment

That means:

• Showing users what to do next
• Confirming when they’ve done something right
• Reducing unnecessary decisions

A Simple Test

Open your product or documentation and ask:

“Would a first-time user feel confident here?”

If the answer isn’t a clear yes…

That’s where the work is.

Final Thought

Trust isn’t built by functionality alone.

It’s built by clarity.

If your product works but users still hesitate or get stuck…

That’s usually where I come in.

I help turn working systems into clear, trusted experiences.

I Built a Pneumonia Detection AI on My MacBook — Here's Exactly How It Works

Sat, 25 Apr 2026 14:15:21 +0000

I just finished building a deep learning system that identifies pneumonia from chest X-rays with 96% accuracy and an AUC-ROC of 0.99. I ran the entire training process on my MacBook Pro M5 using the GPU acceleration provided by Apple's Metal Performance Shaders (MPS). This project wasn't about complex math; it was about using transfer learning to turn a consumer laptop into a medical diagnostic tool. Understanding how to handle messy data and verify what an AI is actually "seeing" is more important than having a massive server room.

WHAT I ACTUALLY BUILT

At its core, I built a computer program that acts like a specialized set of eyes for doctors. You feed it a digital chest X-ray image, and in less than a second, it tells you whether it sees signs of pneumonia or a normal, healthy lung. It doesn't just guess; it provides a confidence percentage for its decision. The system is designed to catch cases that might be subtle to the human eye, acting as a second pair of eyes to reduce diagnostic errors.

THE DATASET PROBLEM NOBODY MENTIONS

When I first looked at the data, I found a massive problem: class imbalance. The training set had 1,341 "Normal" images but a whopping 3,875 "Pneumonia" images. If I had trained the model as-is, it would have quickly learned that "guessing pneumonia every time" results in 74% accuracy without actually learning a single thing about lungs. This is a common trap in AI where a high accuracy score hides a completely useless model.

To fix this, I used two specific techniques to level the playing field. First, I implemented a WeightedRandomSampler, which you can think of as "photocopying rare examples." It ensures that during training, the model sees the "Normal" images more frequently so it doesn't forget what a healthy lung looks like. Second, I added class weights to the loss function—essentially a "bigger penalty for missing rare cases." If the model misclassifies a "Normal" lung as pneumonia, the error signal it receives is mathematically amplified, forcing it to pay closer attention to those specific patterns.

WHY I DIDN'T TRAIN FROM SCRATCH

I didn't start with a blank slate. Instead, I used a technique called transfer learning with an architecture known as ResNet-18. Think of it like this: a radiologist who already knows what edges, textures, and shapes look like doesn't need to relearn basic vision from scratch. They already have the "visual foundation" from years of looking at the world; they just need to learn what sick lungs look like specifically. ResNet-18 comes pre-trained on millions of everyday images (like dogs, cars, and trees), so it already understands how to detect lines and textures.

I used a two-phase training strategy to refine this pre-existing knowledge. In Phase 1 (Epochs 1-5), I froze most of the model and only trained the very last layer. This allowed the model to get a "feel" for the new medical data without overwriting its basic visual skills. In Phase 2 (Epochs 6-20), I unfroze everything and used a tiny learning rate to fine-tune the entire network. At the start of Phase 2, I saw a temporary spike in the loss curve. This is normal and expected—it's the mathematical equivalent of the model being slightly "confused" as it starts adjusting its deep-seated visual patterns to the nuances of X-ray tissue.

CAN YOU TRUST IT? GRAD-CAM EXPLAINABILITY

A 96% accurate AI is useless if it's a "black box" that you can't verify. In medical AI, you have to know why a decision was made. I implemented Grad-CAM (Gradient-weighted Class Activation Mapping), which is a tool that "shows you which pixels the model was looking at when it made its decision." Without this, a model might achieve 99% accuracy just by learning that images with a certain hospital's patient ID label in the corner are usually the pneumonia cases.

When I ran Grad-CAM on my results, the heatmaps were revealing. For pneumonia cases, the "heat" (red and yellow zones) was concentrated directly on the lung tissue where opacities usually appear. For normal cases, the focus was much more diffuse across the entire chest cavity. This gave me the confidence that the model was actually learning medical features, not just memorizing background noise or image artifacts.

THE RESULTS

After 20 epochs and about 45 minutes of training on my MacBook, here is how the system performed on the 624 images in the test set:

Metric	Score
Test Accuracy	96%
AUC-ROC	0.99
NORMAL F1	0.94
PNEUMONIA F1	0.96
False Negatives	15/390
False Positives	13/234

Let's break these down into plain English. Test Accuracy means the model was right 96 times out of 100 overall. AUC-ROC measures how well the model can distinguish between the two classes across different confidence levels; 0.99 is nearly perfect separation. F1 Score is a balanced average of precision (not flagging healthy people as sick) and recall (not missing sick people).

Most importantly, we have to look at the 15 missed pneumonia cases (False Negatives). In a clinical context, missing a sick patient is far worse than accidentally flagging a healthy one. This is why "Recall" matters more than "Accuracy" in medical AI. While 15 misses out of 390 is low, it highlights that this system is a diagnostic assistant, not a replacement for a human doctor who would catch those edge cases.

WHAT I LEARNED

This project taught me a few genuine technical lessons that go beyond the usual tutorials:

The Validation Set Trap: The original dataset only had 16 images in the validation folder. This made the validation accuracy bounce around wildly and become meaningless during training. You need a representative validation set to know if your model is actually improving.
Watch the Loss, Not the Accuracy: Accuracy is a "lagging indicator." The loss curve tells you the "quality" of the model's learning. If the loss is still going down but accuracy is flat, you're still making progress.
Grad-CAM is Mandatory: For medical AI, explainability isn't a "nice to have." It's the difference between a useful tool and a legal liability. If you can't see the heatmaps, you shouldn't trust the predictions.
Apple Silicon is Ready: Training this on MPS (Metal Performance Shaders) was surprisingly fast. For this size of workload, you don't need a dedicated Linux server with a massive GPU; a modern MacBook Pro handles it in under an hour.

WHAT'S NEXT

I'm not finished with this system yet. My next steps are specific:

Fix the Validation Set: I'm going to move about 500 images from the training set into the validation set to get more reliable feedback during training.
Try DenseNet-121: This architecture is the current gold standard in chest X-ray research papers because of how it handles feature reuse.
Build a Web UI: I want to use Streamlit to create a simple drag-and-drop interface so anyone can test the model without looking at code.
Kaggle Notebook: I've already published a self-contained version of this project as a Kaggle notebook for the community to play with.

CLOSING

This project demonstrated that you don't need a supercomputer to build high-performing medical AI. By using transfer learning and being smart about how you handle imbalanced data, you can achieve professional-grade results on consumer hardware. It's a testament to how accessible deep learning has become, provided you focus on the data and the "why" behind the predictions.

Disclaimer: This model is for educational purposes only and is not intended for clinical use.

View the full notebook on Kaggle
View the code on GitHub

The New Employment Market Reality – It’s Much Worse Than You Think!

Sat, 21 Feb 2026 04:01:17 +0000

I truly don't know where to begin. This is the one of the worst employment markets I have ever seen!

Recruiters and companies are being bombarded with qualified candidates from all over the world. The mass layoffs left 100s of thousands people stranded!

The once was considered golden job with real stability and security had been obliterated by AI!

This doesn't mean that tech doesn't need humans, it simply shifted or transformed to different needs. Corporations no longer need coders, they want designers, architects and AI oriented professionals.

The problem is that, what corporations missed, is that they no longer understand why Devs wanted to be Devs.

People regardless of their background, are always looking for good jobs where they feel respected and valued. The problem with the current market dynamics, employers no longer feel the need to care about their employees or care about having a healthy workplace environment.

There is a very huge rise in serious problems such as workplace bullying, mobbing and harassment! What happened?

The truth is that unfortunately, when there is 1000 person ready to take your job, those in leadership lose the incentive to put effort in retention of employees. At the same time, employers realized that a lot of roles specially white collar jobs are no longer needed, so they want to get rid of as many people as possible and remain small. This is why, statistically speaking, the layoff stats far exceeded new job creation. You will hear a lot that employers are being "Cautious".

Do you share my sentiment, do you feel the employment market has become unsustainable? Is it time for Devs to be self employed first?

Share your thoughts in the comments!

Why Developers Should Build Homelabs

Mon, 26 Jan 2026 07:42:18 +0000

In an era dominated by cloud platforms, managed services, and abstracted infrastructure, it’s easy for developers to forget what actually happens beneath the surface. Yet, some of the most capable engineers today share a common trait: they run homelabs.

A homelab isn’t about expensive servers or enterprise-grade hardware. It’s about creating a personal playground where you can experiment, break things safely, and truly understand how systems work. Whether you’re a backend developer, DevOps engineer, or full-stack builder, a homelab can quietly become one of the most valuable tools in your growth journey.

What Is a Homelab?

A homelab is a self-hosted environment usually running on spare hardware, a mini PC, a Raspberry Pi, or even an old laptop where you experiment with real world systems. Think Linux servers, Docker containers, CI pipelines, monitoring tools, reverse proxies, and networking setups, all under your control.

Unlike tutorials or sandbox environments, a homelab forces you to deal with real constraints: limited resources, outages, misconfigurations, and upgrades. That’s where the real learning happens.

1. You Learn How Things Actually Work

Cloud platforms make deployment easy, but they also hide complexity. In a homelab, you don’t get that luxury.

You’ll learn:

How Linux services start and fail
What systemd actually does
How networking, ports, firewalls, and DNS interact
Why disk space suddenly disappears at 2 a.m.

This foundational knowledge makes you a stronger developer even if you never plan to become a full-time DevOps engineer.

2. Safe Space to Break (and Fix) Things

Production systems punish mistakes. Homelabs reward them.

You can:

Crash a server and rebuild it
Misconfigure Nginx and debug it
Experiment with security hardening
Practice backups and disaster recovery

Breaking things in a homelab builds confidence. When something goes wrong at work, it’s no longer panic, it’s déjà vu.

3. Real-World DevOps Skills Without the Pressure

Many developers struggle to get hands-on DevOps experience because production access is limited (for good reason). A homelab fills that gap.

With it, you can:

Run Docker and Docker Compose
Set up CI/CD pipelines
Monitor systems with Prometheus or Netdata
Practice zero-downtime deployments
Experiment with systemd, cron, and logging

These are highly marketable skills and a homelab lets you learn them at your own pace.

4. Better Understanding of Performance and Scaling

When you run everything yourself, inefficiencies become obvious.

You start asking:

Why is this container using so much memory?
Do I really need this service running?
How can I optimize startup times?
What happens when traffic spikes?

This mindset translates directly into writing more efficient applications and designing better architectures.

5. A Portfolio That Speaks Louder Than Certificates

A homelab isn’t just for learning it’s proof.

You can:

Document your setup in blog posts
Share architecture diagrams
Open Source configs and scripts
Talk confidently about real infrastructure challenges

When you say “I’ve run my own services,” it carries weight especially in interviews.

6. It Encourages Curiosity and Long Term Growth

Homelabs naturally evolve. What starts as “just a Linux server” turns into:

A personal VPN
A monitoring stack
A self-hosted dashboard
Automated alerts and backups

You stop chasing trends and start understanding systems. That curiosity compounds over time.

You Don’t Need Much to Start

This is the best part.

You can start with:

An old laptop
A mini PC
A Raspberry Pi
Even a small VPS

Install Linux, pick one tool (Docker, Nginx, or systemd), and build from there. The value isn’t in how powerful the hardware is, it’s in what you learn along the way.

Final Thoughts

Building a homelab isn’t about replacing the cloud or rejecting modern tooling. It’s about understanding the foundations that everything else is built on.

In 2026, developers who stand out aren’t just those who can write code, they’re the ones who understand the systems running it.

If you’ve ever wanted to go deeper, gain confidence, and sharpen your engineering instincts, a homelab is one of the best investments you can make.

If this post resonated with you, share it with another developer and if you’re already running a homelab, you’re ahead of the curve.

Why Building Projects Beats Just Watching Tutorials

Sun, 14 Dec 2025 16:37:38 +0000

When I started learning AI and Machine Learning, I thought watching tutorials was enough. Models, algorithms, code examples — everything looked clear while watching. But the moment I tried to build something on my own, reality hit.

❌ The Tutorial Comfort Zone

Tutorials made everything feel easy:

Clean datasets

Pre-written logic

Perfect outputs

But once the video ended, I realized I didn’t truly understand how things worked.

What Changed: Building Real Projects

Things changed when I started building my own AI & ML projects — even small ones.

I faced:

Dataset issues

Model giving wrong predictions

Errors I had never seen before

Performance problems

At first, it was frustrating. But slowly, I learned:

How to debug ML code

Why preprocessing matters

How model choice affects results

How AI systems behave in real-world scenarios

That struggle taught me more than any tutorial ever could.

Learning by Doing (My Approach)

This is the method that worked best for me:

Learn the basic concept

Build a simple AI/ML project

Break it by experimenting

Improve accuracy or features

Repeat with a new idea

Each project improved my confidence and understanding.

Final Thought

AI and ML are not learned by just watching — they are learned by building, failing, and fixing.

If you’re learning AI or ML, don’t wait to be perfect.
Start small, build projects, and let mistakes teach you.

Build → Fail → Learn → Improve

Happy Coding

Why I Couldn’t Launch My EdTech MVP Without a Real Developer: My Accelerator Heartbreak in Lagos

Tue, 18 Nov 2025 19:47:24 +0000

Ever had this wild, messy dream you couldn’t shake? That was me, 2021. The world was upside-down, and I had an idea for an EdTech platform buzzing in my head. Not just any idea… the kind that keeps you up at night, sketching screens on scraps of paper while the rain hammers the windows.

The Spark: From Idea to Accelerator
So I ran with it. I pitched my heart out. Somehow, the stars lined up—I got accepted into an accelerator program in the USA right from here in Lagos. There were other smart founders in the cohort, but I was sure my EdTech angle had legs. I could already see the impact: students leveling up, teachers connecting, a real shift in how we learn.

But let’s pause for a second. Ya know that rush when someone says “Congratulations!” and you realize, oh man, now the real work starts? That’s when I hit my first speed bump.

Playing Matchmaker in the Tech Scene
If you’ve ever tried to launch a tech product in Lagos, you know developers are kings and queens. They’ve got options. I started asking around—friends from uni, that guy my cousin knows who codes in Python, a few folks recommended through the accelerator’s Slack group. Everyone was busy, everyone wanted equity, and everyone needed convincing.

Believe it or not, I actually managed to get a developer to sign an agreement. The thrill! The relief! I thought, “Finally, a pro on my side. We’re gonna build this MVP and crush it.” But weeks turned into months. DMs went unanswered. Zoom calls got rescheduled, then ghosted. It was like trying to herd cats—but the cats were also lead singers in seven different bands.

The No-Code Mirage
Here’s where my DIY optimism took a nosedive. People online kept saying “No-code tools are the way forward! You don’t need to be a developer.” Great advice, if you know what those words mean. I’d open Bubble, stare at all those workflows. Tried Adalo, too. Still, nothing “clicked.” No tutorial really felt made for raw beginners, especially in Nigeria where so many tools were blocked or cost a fortune to access.

I was stuck. There was money on the table—real funding from the accelerator! But every deadline felt more like a tsunami crashing over me. I’d read stories about founders building MVPs in a weekend. Meanwhile, my idea was stuck on Post-it notes and half-baked Google Docs.

Losing The Shot
After six months (and a thousand heated WhatsApp chats), it was gone. The accelerator moved on. My shot at funding vanished. I felt like I’d wasted not just an opportunity but all the trust people placed in me. Nothing stings more than being close enough to touch your dream, only to watch it slip away because the one thing you couldn’t get—real dev muscle—just wouldn’t show up.

Lessons I Wish I’d Known
So… why couldn’t I build my MVP alone, even with help lined up?

Developers are swamped, and sometimes equity isn’t enough to get them onboard—especially if you’re a first-time founder with only big ideas and no code chops.

No-code tools sound life-changing. In practice? If you can’t pick them up fast enough, they might just create more headaches for non-tech founders.

Signed agreements don’t mean squat if there’s no trust, shared vision, or urgency. Papers look nice, but momentum gets things shipped.

If You’re Dreaming Big in Lagos…
I’d say: learn just enough tech to ask the smart questions. Start ridiculously small. Build a landing page. Sketch a user flow. Don’t wait for the “perfect” dev—or, at least, don’t bet everything on someone else’s bandwidth.

Opportunities don’t always circle back. Take your shot (even the ugly, unfinished ones). Because the only thing worse than regret is never getting in the ring at all.

Let’s commiserate below—have you struggled to build a tech MVP in Nigeria? Got tips or stories? Drop them in the comments.

That’s the journey. Messy, real, and full of stuff nobody puts in the official how-to guides.

Why You Should Build Projects Before You Feel “Ready”

Sun, 16 Nov 2025 02:57:09 +0000

When I first started learning tech, I had this habit:
I kept waiting.

Waiting to fully understand a language…
Waiting to finish a course…
Waiting to feel “confident enough.”

But here’s what I learned along the way:

You will never feel 100% ready — and that’s exactly why you should start building early.

Building Is the Fastest Way to Learn

Courses give you theory.
Tutorials guide your steps.
But projects?

Projects push you into real problem-solving.

Every time I built something — even tiny things that looked “meh” — I grew faster than any tutorial could ever teach me.

You learn by doing, by breaking things, and by fixing them.

Projects Reveal What You Don’t Know

It’s funny how gaps show up the moment you start building:

“Wait… how do I fetch an API again?”
“Why is this bug refusing to vanish?”
“How do people structure these files neatly?”

And honestly?
That’s good.

Because now you know exactly what you need to learn next.

Small Projects Build Big Confidence

Your first project won’t be perfect.
It doesn’t have to be.

What matters is that it’s yours.

That little spark of “I made this” pushes you into your next project.

And soon:

Button → Page
Page → App
App → Portfolio
Portfolio → Opportunities

That’s how developers grow.

Projects Make You Visible

Posting your work — GitHub, CodePen, LinkedIn — changes everything.

People don’t just want to hear about your learning.
They want to see your progress.

Your projects become proof.
Receipts.
Your growth timeline.

And that is how opportunities find you.

How To Start (Even If You Don’t Feel Ready)

Pick something tiny:

A calculator
A to-do app
A card UI
A simple landing page
A fun animation

Start small.
Start messy.
Just start.

You’ll figure out the rest along the journey — we all did.

Final Words

Don’t wait for confidence.
Don’t wait for perfection.
Don’t wait for the “right time.”

Start now.

Because readiness doesn’t come before action — it comes from action.

Every developer you admire started the same way:
messy, confused, curious… but brave enough to begin.

Keep building.
Keep growing.

You’re not just building projects —
you’re building yourself.

Signature:

The Duchess of Hackers

Full-Stack Developer | Digital Marketer| Community Builder

What is Web3?

Wed, 18 Jun 2025 12:53:37 +0000

Web1 (1980’s - early 2000’s)

The first phase of the Internet, Web1, was mainly about providing the everyday consumer with online content and information.

As consumers could only read information or content online, and not yet interact with it, Web1 was incredibly static.

When you think about Web1, think Internet Explorer, Yahoo, or Netscape. While web1 was read-only, the companies we associate with web1 were built on open protocols (meaning pretty much any person or organization could build on the internet and know they were subject to the same rules as the next person or organization).

What is Web2?

Web2 is the version of the internet most of us know and use today. Where Web1 was static and “read-only,” Web2 is “read-write,” and interactive. Under Web2, the internet became more usable: Web2 was dynamic and users could consume, interact with, and create content on the internet themselves.

Along the way, the internet became largely dominated by the four behemoths we know today as Apple, Amazon, Facebook, and Google. Web2 also saw an explosion in the use of smartphones, and most of internet use was through mobile apps and hardware built by these companies. While this meant more people could participate in the internet, it also meant the internet was becoming increasingly controlled by the leading digital platforms.

Why is this a problem? In the centralized internet we know today, Apple can take a 30% cut on all paid-app downloads and in-app purchases, Twitter and Facebook can de-platform the President of the United States, and the everyday consumer has less privacy, security, and control over their online information than ever before.

We also see a lot of data breaches happening all across Web2 leading to reduced security and privacy for one's personal data. When a user's data gets breached it's easy for them to become a victim of identity theft, personal attacks etc.

What is Web3?

Web3, the future internet we’re moving towards, is a decentralized internet. Under Web3, the internet is shared online and governed by the collective “we,” rather than owned by centralized entities. The Web3 world is one that has open-source protocols at its foundation. Web3 is about rearchitecting internet services and products so that they benefit people rather than entities.

Web3 enhances the web we know today by making it decentralized, distributed, open, trustless and permissionless.

It is getting built such that everything would happen in a decentralized distributed way giving no central authority access to control the system.
‘Open’ as it would be open sourced software built by an open and accessible community of developers and executed in full view of the world.
‘Trustless’ in that the network itself allows participants to interact publicly or privately without a trusted third party.
‘Permissionless’ in that anyone, both users and suppliers, can participate without authorization from a governing body.

Summary

Web1: Read

Web2: Read-Write ️

Web3: Read-Write-Own ️

Wait! Don’t Start Your Server Before MongoDB Connects

Tue, 17 Jun 2025 22:54:46 +0000

Hey everyone!
In the previous article, I explained how to connect MongoDB to your Node.js app using Mongoose.
But if you noticed — we didn’t talk about starting the server yet!

We’ll see how to start the Express server only after your database connection is successful — a small but important step to avoid future errors and follow best practices.

Current Project Structure Recap
So far, here’s how your folder structure looks:

your-project/
├── index.js            // Main entry point (will start the server)
├── db/server.js        // MongoDB connection
├── constants/idbname.js  // DB name or other constants
├── .env

❓ Before We Start Coding the Server...
There’s one important question that needs to be answered first:

Should we start the server before connecting to the database, or after the connection is successful?

Answer: Always Start the Server After the Database Connection
Why?

The server starts immediately — it assumes everything is ready.
Meanwhile, the MongoDB connection is still being established (and it's an asynchronous operation).
If a user hits an API route that depends on the database — for example, /users, /posts, or /login —
Your server will try to access the database that hasn’t connected yet.
This leads to errors Or even app crashes in worst cases.
Basically: Your server is accepting requests it isn’t ready to handle yet. That’s like

First connect to MongoDB, and then only if that’s successful, start the Express server.

Now that we know why the server should start only after a successful DB connection, let’s set up the Express server step-by-step.

1. Install Express
First, let’s install Express using npm:

npm install express

This will add Express to your project dependencies so you can create and run your server.

2. Create an app.js File
Inside your root folder, create a new file named app.js. This file will handle creating the Express app instance

Set "type": "module" in package.json
This tells Node.js to treat .js files as ES modules, enabling import and export.

⚠️ Without This?
If you don’t set "type": "module", then writing this:

import express from "express";

will throw an error like:

SyntaxError: Cannot use import statement outside a module

3 Simple Steps to Initialize Express in app.js

Step 1: Import Express

import express from "express";

Step 2: Create the App Instance

const app = express();

This app variable is now your entire Express application. You’ll use it to define routes, middlewares, etc.

Step 3: Export the App

export default app;

Exporting the app allows you to import and use it in your index.js file (where you'll start the server after connecting to MongoDB).

import express from "express"
const app = express();
export default app;

for now, this minimal setup is perfect.

Quick Reminder from the Previous Article

In our previous article, we created an async function called connectionDB() that handles the MongoDB connection logic.
We then called this function in index.js to actually initiate the connection.

But here’s something important you should understand

When you create an async function like this:

async function connectionDB() {
  // your logic here
}

...it always returns a Promise by default, whether you explicitly return something or not.

This means — when we call this function:

connectionDB()

We can attach .then() and .catch() to it, just like any other Promise:

connectionDB()
  .then(() => {
    // Code to run after DB is connected
  })
  .catch((err) => {
    // Handle DB connection error
  });

Why We Use .then() and .catch() for Database Connection

.then() — If DB Connection is Successful

 connectionDB()
  .then(() => {
    // If connection is successful, start the server
    app.listen(3000, () => {
      console.log(` Server started successfully`);
    });
  })

This means:

If MongoDB connects successfully
Then we start our Express server using app.listen().
This ensures the server starts only when the DB is ready.

.catch() — If DB Connection Fails
But what if the connection fails? For example:

Wrong MongoDB URI,
Incorrect username or password,
Or internet issues?

In that case, the .catch() block runs:

.catch((err) => {
  console.log(" Server failed to start due to DB connection error:", err);
});

This stops the server from running without a working database, which could lead to serious bugs or crashes in your app.

// index.js

import dotenv from "dotenv";
import app from "./app.js";
import connectionDB from "./db/server.js";

// Load environment variables from .env file
dotenv.config();
 
// Connect to the database first
connectionDB()
  .then(() => {
    // If connection is successful, start the server
    app.listen(3000, () => {
      console.log(` Server started successfully`);
    });
  })
  .catch((err) => {
    // If connection fails, do NOT start the server
    console.log(" Server failed to start due to DB connection error:", err);
  });

Wrapping Up
And that’s how you start your server only after your database connection is successful — the clean, professional way.

Remember:
Make sure to import your app.js file into index.js like this:

import app from "./app.js";
This ensures your Express server is ready to run once everything else (like DB connection) is set.

This setup is not too lengthy — it's actually a very compact and organized way to structure your backend.

With this approach, your project is:

Modular
Error-resilient
Production-ready

Bonus Tip: Special Characters in Your MongoDB Password
Let me share a quick issue I faced (and many beginners do too):

❓ What if your MongoDB password contains special characters like @, #, or $?

If your password has characters like @, the MongoDB connection will fail unless you encode them properly in the URI.

The Fix:
Let’s say your password is:

myPass@123

Your MongoDB URI will break at @, because @ has a special meaning in URLs.

Instead, you must URL-encode the special characters.
For example, @ becomes %40.

So your password becomes:

myPass%40123

And your connection string should look like this:

mongodb+srv://username:myPass%*Emails are not allowed*/

Pro Tip: If you don’t want to mess with encoding, just avoid using special characters in your DB password — or change them to something simpler.

If this article helped you even a little, drop a like ❤️ — it really motivates me to share more practical content like this!*

FIRST STEPS, BIG LEAPS

Sun, 23 Feb 2025 20:37:35 +0000

FIRST STEPS, BIG LEAPS

Taking the leap is one thing—stopping others in the air and not making them to reach for the stars cause

"how can the sky be the limit when they are people on the moon" - Paul Brandt.

After making the decision to build my startup, I quickly realised that dreaming big was easy, but turning those dreams into reality? That was the real challenge.

This was where things got real.

The first steps were messy, exciting, and terrifying all at once. One minute, I was pumped with motivation (David Goggins Type shii ), ready to change the world . The next, I was staring at my screen, wondering where to even begin.

I wasn’t just a teenager with a dream anymore—I was a teenager with a mission. But how do you turn a mission into something real?

FROM VISION TO ACTION

A dream is nothing without action. I knew that if I wanted to be one of the youngest tech startup founders, I couldn’t just sit around and hope for things to happen.

But let’s be real… where do you even start when you’re 15? Balancing school which I am already managing with the 65% pass mark, and have limited resources, which was just me my Laptop, phone and a Dream so what should I do?

At first, my mind was all over the place. One second, I wanted to build an app, then a website, then an AI-powered platform —my ideas were running wild. But I knew I had to simplify.

So, I took my first real step: writing things down.

I grabbed a notebook (yes, a real one, not an app this time ) and started listing out what I needed to do:

✅ Understand the problem I wanted to solve – A startup isn’t just about an idea; it’s about solving a real problem that people have in there every-day life that I could Also Relate to.
✅ Research similar products – What’s already out there? How can I make something better?
✅ Figure out what I needed to learn – Coding? Business? Marketing? Time to hit the books (Actual Books ).
✅ Sketch my first wireframes – Even though my designs looked like a five-year-old drew them, I had to start somewhere . (Personally, I think they looked good but back to what I was saying)

Lesson learned: The key wasn’t knowing everything from the start—it was just getting started.

REALITY CHECK: FACING THE FIRST HURDLES

Taking the first step felt like an achievement… but reality hit FAST.

I had to face some uncomfortable truths:

I didn’t know everything. Shocking, right? I thought I knew how to code, but the more I dived into real-world projects, the more I realised there was so much I didn’t know.

Self-doubt creeped in. Was I even capable of this? Would anyone take me seriously? Would this idea even work?

⏳ Time became my biggest enemy. Balancing school, homework, and my startup felt impossible. Some days, I barely had time to breathe.

At this point, I had two choices:

1️⃣ Let the doubts and challenges stop me.
2️⃣ Keep pushing forward, no matter what.

You already know which one I chose. (And no It's not No:1 )

LEARNING BY DOING

I stopped overthinking and started learning through action.

I dived deep into research—watching hours of YouTube tutorials, reading startup blogs, and joining online coding communities (I basically Just started Tutorial Hell, till I got to this [https://roadmap.sh][1] )

I started small projects—not for money, not for recognition, but just to test my skills (It was hard ). Every line of code I wrote, every feature I built, was a step forward.

I made mistakes. A lot of them (I can't even give an estimate) . But every error taught me something new.

And that’s when I discovered a secret:

The best way to learn isn’t by reading or planning—it’s by doing

Saw it in a motivational Video.

SMALL WINS, BIG MOTIVATION

Then, it happened—my first real win.

I built a working prototype of my idea.

Was it perfect? No.
Did it crash a few times? Absolutely.
Did I feel like a genius anyway? HECK YES.

That moment was everything. Seeing my idea come to life, even in its simplest form, was the proof I needed that I was on the right path.

It didn’t matter if it wasn’t 'perfect'. What mattered was that it was real.

Every small win gave me a massive confidence boost. Every piece of progress reminded me why I started.

THE BIGGER PICTURE: WHY THIS MATTERS

The hardest part of any journey is starting.

We all have big dreams, but most people never take that first step because they’re scared of failing, scared of looking stupid, or waiting for the “perfect” time.

Let me tell you something: There is NO perfect time.

If you wait until you have everything figured out, you’ll never start.

I realised that momentum is everything. Once you start taking action—no matter how small—you build confidence, experience, and resilience.

And before you know it…

You’re no longer just a dreamer.
You’re a doer.

⏭️ THE ROAD AHEAD…

I won’t lie—this is just the beginning.

I still have so much to learn.
I still face challenges every single day.
I still have moments of doubt.

But I’ve made it this far—and that means I’m capable of going even further.

Each small step forward is another big leap toward my dream.

The journey continues… and I can’t wait to share what’s next.

Stay tuned for Episode 5!

To anyone reading this: Your dream is waiting. The only question is—will you take the first step?

Your Turn!
What’s a dream you’ve been putting off?
What’s stopping you from taking 'The first step'?

-

Drop a comment—I’d love to hear your thoughts!

I also wanna Thank those who commented On my Last Post It was really Inspiring

Coder Legion - Recent posts tagged dev

The Truck Driver Building His Own Programming Language- Meet Bryan MacLee

Developer Spotlight: Meet Bryan MacLee — The Truck Driver Building His Own Programming Language

💡 What You'll Discover

🎥 Watch the Interview

👨💻 Meet the People Behind the Interview

🌟 Building Something of Your Own?

💬 Let's Discuss

DeveloperSpotlight #Programming #WebDevelopment

Per-Tenant LLM Budgets: Stop One Customer From Spending Your Whole Model Bill

Rate limits are not budgets

Budget in money, not tokens

Reserve, call, settle

The reservation: one atomic step

Settlement: idempotent, and never refused

Holds that never come back

Streaming: the bill arrives at the end

Agent loops: budget the step, not the session

Soft limits degrade, hard limits refuse

Reconcile against the provider's numbers

Four numbers to watch

FAQ

The short version

Claude Fable 5.1 Made Your Conversation History Append-Only

What a thinking block is actually bound to

Why you will find out last

The patterns that are now illegal

1. Client-side truncation and summarization

2. Snipping a turn out of the middle

3. Rebuilding system or tools per request

4. Keep-tail compaction

5. Background compaction

6. Editing assistant turns for control

The three legal shapes for client-side compaction

The better answer: stop editing on the client

The escape hatch, and why it isn't a fix

The other breaking change in the same release

A 20-minute audit

Why this is happening

The short version

I released **oteldoctor v0.1.0** — an open-source Go CLI for checking OpenTelemetry Collector config

What it does

Commands

Install

Why it exists

Nowadays, LLM is based and major for me

Why Users Don’t Trust Your Product (Even When It Works Perfectly)

I Built a Pneumonia Detection AI on My MacBook — Here's Exactly How It Works

WHAT I ACTUALLY BUILT

THE DATASET PROBLEM NOBODY MENTIONS

WHY I DIDN'T TRAIN FROM SCRATCH

CAN YOU TRUST IT? GRAD-CAM EXPLAINABILITY

THE RESULTS

WHAT I LEARNED

WHAT'S NEXT

CLOSING

The New Employment Market Reality – It’s Much Worse Than You Think!

Why Developers Should Build Homelabs

What Is a Homelab?

1. You Learn How Things Actually Work

2. Safe Space to Break (and Fix) Things

3. Real-World DevOps Skills Without the Pressure

4. Better Understanding of Performance and Scaling

5. A Portfolio That Speaks Louder Than Certificates

6. It Encourages Curiosity and Long Term Growth

You Don’t Need Much to Start

Final Thoughts

Why Building Projects Beats Just Watching Tutorials

Why I Couldn’t Launch My EdTech MVP Without a Real Developer: My Accelerator Heartbreak in Lagos

Why You Should Build Projects Before You Feel “Ready”

Building Is the Fastest Way to Learn

Projects Reveal What You Don’t Know

Small Projects Build Big Confidence

Projects Make You Visible

How To Start (Even If You Don’t Feel Ready)

Final Words

What is Web3?

Wait! Don’t Start Your Server Before MongoDB Connects

FIRST STEPS, BIG LEAPS

FIRST STEPS, BIG LEAPS

3. Rebuilding `system` or `tools` per request

I released oteldoctor v0.1.0 — an open-source Go CLI for checking OpenTelemetry Collector config