Robert Dugger — Dev Blog

Author: rdugger

  • How to Forecast End-of-Day Call Center Performance

    By mid-afternoon, you can know where your floor will close by end of day — accurately enough to make the remaining hours a decision, not a guess. Here’s how intraday performance forecasting works and what it takes to build it.

    ## The Problem With Yesterday’s Numbers

    Most contact centers have end-of-day metrics. Dials, connects, conversion rate against target. Those numbers are accurate, useful for trend analysis, and arrive the next morning.

    By the time you see them, the day is already over.

    The decisions that drive outcomes happen during the day — in real time, when hours remain to influence the result. Do you push harder in the final stretch? Adjust campaign priority? Pull a server that’s underperforming? Those decisions get made in the afternoon with one question underneath all of them: where are we going to close?

    If you’re answering that question with yesterday’s data and experienced intuition, you’re working with an information deficit that compounds every day it stays open.

    ## How Intraday Forecasting Works

    The system records dial conversion rates at regular intervals throughout the business day. Not a snapshot at end of day. A continuous read of how the floor is performing as it performs.

    Every morning, before the floor opens, the model retrains. It processes the intraday conversion patterns from previous days — how conversion tends to develop through the morning, when it typically accelerates, when it softens, how afternoon performance differs from morning — and calibrates to the current operation’s historical data.

    As the day runs, the forecast updates on a regular schedule. Each update incorporates actual conversion data that’s come in, narrowing the prediction window.

    By mid-afternoon, with hours remaining, the model’s error range has compressed enough that the closing metric is predictable within an actionable range. Not a rough estimate. A forecast with a documented accuracy track.

    **What this changes in practice:**

    Before the forecasting system, the afternoon conversation was backward-looking: here’s where we are, here’s where we were yesterday, here’s the gap. The decision about the next few hours was judgment — experienced judgment, but judgment without a forward projection.

    After the forecasting system, the afternoon conversation is forward-looking: here’s where we are, here’s where we’re going to close, here’s what the remaining hours need to produce to change that number. The judgment still applies. But it’s informed by a projection that’s been validated against actual outcomes rather than intuition alone.

    That’s a different kind of management posture. You’re not reacting to what happened — you’re positioned in front of what’s about to happen.

    ## The Complication: Point Estimates Break When You Need Them Most

    The obvious version of intraday forecasting — average dial conversion rate over recent days, extended to end of day — works in normal conditions and breaks exactly when conditions are abnormal.

    Days after holidays follow different patterns than regular days. Days with agent attrition don’t produce the same intraday curve as fully-staffed days. A mid-day list quality shift — new inventory loading into an active campaign in the afternoon — changes the conversion trajectory in ways a backward-looking average can’t capture.

    A point estimate that’s wrong on the days that matter most is useless. Operations managers stop trusting a forecast that fails them when they need it, which is precisely when conditions are unusual.

    **The correct implementation produces a confidence interval, not just a point estimate.**

    A point estimate says: we’ll close at X conversions.

    A confidence interval says: we’ll close between X and Y conversions, based on current trajectory and historical variance.

    The confidence interval tells you two things the point estimate doesn’t. First, it tells you when the day is trending outside normal bounds — when the interval is wider than usual, the model is operating in territory with less historical precedent, which is a signal to pay attention. Second, it tells you when a result is well-constrained versus genuinely uncertain — a narrow interval with hours remaining means the outcome is largely determined; a wide interval means the remaining time is more variable than usual.

    **Additional inputs that improve accuracy:**

    Day-of-week weighting. Each day’s patterns should be compared to its own history, not the full week averaged together. The model needs to know what kind of day it is.

    Agent count as a real-time input. Utilization affects conversion. A floor running below normal staffing has a different conversion profile than a full floor, and the model needs to account for that explicitly rather than absorbing it as noise.

    ## What Building This Requires

    **A data collection layer.** Conversion rates pulled from your dialer API at regular intervals throughout the day, stored with timestamps. Convoso’s API supports this; a scheduled script on a consistent cadence collects the signal reliably.

    **A retraining pipeline.** Each morning, before the floor opens, the model fits to historical intraday patterns. The features that matter most: time of day, day of week, agent count, and recent conversion velocity. A well-structured ML regression model with the right features outperforms a complex one with the wrong ones — the goal is a forecast accurate enough to act on, not a showcase of modeling sophistication.

    **Validation tracking.** The model’s predicted closing range logged against actual outcomes, daily. This is how you know when the model is drifting and needs recalibration, and it’s how you build the track record that makes the forecast worth trusting. A model you’ve been validating for several months has a credibility that a newly deployed model doesn’t.

    **A delivery layer.** The forecast needs to appear where ops managers look — a dashboard, a scheduled Slack message, a Google Sheets integration. A forecast nobody sees is the same as no forecast.

    ## Frequently Asked Questions

    **How accurate is the forecast by mid-afternoon?**
    Accurate enough to make the remaining hours actionable rather than reactive. The exact precision depends on your operation’s historical variability — a stable floor with consistent staffing and consistent list quality will have tighter forecast intervals than one with high day-to-day variance. The value isn’t in the precision of the number — it’s in the direction and whether you’re trending toward or away from target.

    **Does this require machine learning expertise to build?**
    The approach is an ML regression model with appropriate feature engineering — time of day, day of week, recent velocity, agent utilization. The complexity is in getting the features right and building the validation discipline, not in the modeling approach itself.

    **What data do I need to start?**
    Historical intraday data at the interval you want to forecast at — ideally several months of regularly sampled conversion rates. If that data isn’t archived, starting with collection now and building the model after accumulating enough history is the right sequencing.

    **Can this work if our staffing varies a lot day to day?**
    Yes, but agent count needs to be an explicit input to the model rather than something it absorbs implicitly. Days with unusual staffing should be labeled as such in the training data so the model can account for the pattern, rather than treating them as noise.

    ## If You’d Rather Have This Built

    I build intraday performance forecasting for contact centers. If you want the data collection, the retraining pipeline, and a confidence-interval forecast that surfaces where your floor will close before the last hours are gone — start here: rfditservices.com/intake.html

    The first conversation is free.

  • The grammar of what’s possible

    There’s a Yu-Gi-Oh game on PS1 where you can fuse two cards together. The result isn’t random. There are rules. But you don’t know the rules yet — you just know that two inputs produce a third thing that neither input was, and that the third thing surprises you even when it shouldn’t.

    That’s the hook. Not the surprise alone. The realization underneath the surprise that the system has depth. That there’s a grammar to what’s possible, and you can learn it.

    I’ve been building toward that feeling ever since.

    Jade Cocoon does the same thing with monsters — merge two creatures, watch the result carry both parents in its design. Dragon Quest Monsters runs on fusion too. Yu-Gi-Oh Forbidden Memories taught me that combination-as-discovery is its own mechanic, separate from any theme it wears. Everything Is Crab is the roguelike version: you absorb what you fight, you become it, you discover what you’re becoming one encounter at a time. No Man’s Sky showed me that procedural generation has finally caught up to what those PS1 games were reaching toward — creatures that feel like they emerged from a system rather than a designer’s hand.

    The mechanic isn’t genetics. Genetics is just the implementation I keep reaching for. What I’m actually trying to build is a machine that produces controlled emergence — outcomes that surprise you within a system deep enough to eventually master.

    Pure RNG is a slot machine. You can’t get better at it. Pure determinism is a calculator. You can solve it and put it down. The games I keep returning to live between those poles: consistent enough to reward learning, deep enough to keep producing novelty.

    TurboShells was an attempt at this. Turtles whose bodies expressed their genomes at render time — shell radius, leg length, color emerging from a sequence. The faster ones bred. Over generations you watched the population drift. The system had rules. The outcomes still surprised you.

    SlimeGarden chose basic shapes deliberately. If the creature is simple enough, even small variation reads as meaningful. The shape IS the information. You can see the grammar in the design.

    The version I haven’t built yet is closer to Jade Cocoon meets Dragon Quest Monsters — creatures with traceable visual lineage, combination mechanics with real strategic depth, the initial surprise and the eventual mastery running in parallel. Everything Is Crab proves the roguelike format can carry it. NMS proves the procedural layer is tractable.

    I’m still building toward it. Every system I’ve made in this space has been a step closer to understanding the grammar well enough to write it myself.

    The hook was a PS1 card game in the late nineties. The project is still open.

  • How to Monitor Dialer List Health in Convoso

    Your list is degrading right now. Aged leads, disconnected numbers, leads that already converted on a different campaign, numbers that hit DNC since you imported them — all of them are burning dial attempts and suppressing your contact rate. Here’s how to build the monitoring layer that surfaces this before it collapses your numbers.

    ## Why List Health Degrades Faster Than You Think

    A fresh lead list has a predictable contact rate. As it ages, that rate decays — but not linearly. The first pass reaches the easiest contacts. Each subsequent pass hits harder-to-reach numbers, people who’ve already heard the pitch, numbers that have gone stale since import. The decay curve accelerates as penetration increases.

    Most Convoso operations notice this as “the list is getting old” and respond by ordering more inventory. The actual problem usually sits earlier: the campaign’s penetration rate wasn’t being tracked, import hygiene missed duplicates against existing leads, and the warning signs were invisible until the contact rate had already collapsed.

    A 10% drop in contact rate over a week is expensive. A 30% drop is a bad week. Neither one is a surprise if you’re monitoring the right signals before they hit.

    ## What List Health Monitoring Tracks

    The metrics that matter, in roughly the order they’ll help you:

    Penetration rate by campaign. What percentage of imported leads have been attempted at least once? This is the leading indicator — the one that gives you time to act. When penetration reaches a threshold, you need new inventory in the pipeline before the campaign goes hungry, not after agents are sitting idle. Convoso doesn’t surface penetration rate prominently in its standard reporting. You have to calculate it from the data the API exposes.

    Contact rate by lead age. Track conversion not just in aggregate but broken down by how long ago a lead was imported: leads attempted in week one, week two, week three since import. The decay curve tells you when a list is effectively exhausted from a productivity standpoint, even if numbers technically remain. Most operations have more “leads” than viable leads — the monitoring makes that distinction visible.

    Lead aging distribution in active campaigns. A campaign can look healthy on aggregate while its active pool is dominated by weeks-old records. Breaking it down by import age surfaces this before it becomes a contact rate problem.

    Cross-campaign duplicate exposure. A number active across multiple campaigns creates agent confusion, customer frustration, and wasted attempts. Deduplication at import catches most of this; monitoring catches what slipped through and surfaces it before it compounds.

    ## The Complication: Convoso Shows You the Past

    Convoso’s built-in reporting is backward-looking. It shows you what your contact rate was yesterday, what it was last week, how many dials converted over any given period. That data is genuinely useful for trend analysis, period comparisons, and reporting to management.

    It doesn’t tell you what your contact rate is going to be in two hours if the list doesn’t change.

    The monitoring that prevents a bad afternoon is penetration rate tracking updated in near-real time, not an end-of-day summary. When a campaign’s available-to-dial leads drop below a threshold, you want to know while there’s still time to load new inventory and have it processing before the afternoon push — not the following morning when the opportunity is already gone.

    Building that leading indicator requires pulling data Convoso doesn’t surface in standard dashboards. A scheduled pull from the API at regular intervals, tracking available lead count by attempt history, gives you the penetration picture as it develops. Cross that with contact rate by lead age and you have a system that surfaces degradation while there’s still time to respond.

    The second complication is at import time. A list that wasn’t scrubbed against existing leads, recent DNC additions, and disconnected numbers before it loaded starts its decay already in progress. Monitoring will surface this — you’ll see the contact rate compress faster than expected for a fresh list — but prevention is cheaper than remediation. Import hygiene automation that runs before the first dial is the companion to monitoring that makes the numbers meaningful.

    ## What the Monitoring Layer Looks Like in Practice

    A scheduled data pull from the Convoso API capturing campaign-level lead counts, attempt history, and contact rates at regular intervals. This doesn’t require a dedicated monitoring platform — the API exposes the data and a scheduled script can collect and log it reliably.

    A dashboard that surfaces threshold violations. A Google Sheets integration works for most SMB contact centers: data lands in a structured format, conditional formatting flags penetration thresholds, and a shared sheet gives ops managers visibility without requiring a new tool. Slack alerts on threshold crossings add a push notification for the signals that need immediate attention.

    Defined thresholds calibrated to your operation. The metrics that signal a list health problem aren’t universal — the right numbers come from your own historical baselines. But the framework is consistent across operations:

    – Contact rate significantly below your historical baseline: urgent flag — the list is exhausted or degraded and is burning agent time without result
    – Contact rate in a healthy range for your vertical and lead source: the target for a well-managed list with appropriate aging
    – Conversion rate below a minimum threshold: list quality problem — leads aren’t converting at a rate that justifies continued dialing; source quality or aging is the likely cause
    – Conversion rate at or above your operational target: the performance level a fresh, properly sourced list should sustain

    Establish your own baselines from the first few weeks of monitored data. The monitoring layer tells you when you’re deviating from those baselines — the thresholds you set determine when deviation triggers an alert.

    Import hygiene automation. Pre-import scrubbing against your existing lead pool and DNC sources reduces the decay rate before the first attempt. This is prevention rather than monitoring, but it’s the step that makes the monitored numbers worth tracking.

    ## Frequently Asked Questions

    Does Convoso have any built-in penetration tracking?
    Convoso shows attempt counts and disposition breakdowns, but not penetration rate as a campaign-level health metric calculated against total imported leads. You derive it from the data the API exposes — available leads versus total leads in the campaign.

    How often does the monitoring need to run?
    For most operations, regular intervals give you enough resolution to catch degradation while there’s still time to act. Running it more frequently is possible but usually doesn’t change the response time meaningfully.

    What if we’re pulling from multiple lead sources with different quality profiles?
    The monitoring should track by source where possible, not just by campaign. A list from one source may have a different expected decay curve than another. Blending them without source tagging makes the contact rate signal harder to interpret.

    ## If You’d Rather Have This Running

    I build monitoring layers for contact centers using Convoso and similar platforms. If you want penetration tracking, contact rate dashboards by lead age, and threshold alerting set up correctly — start here: rfditservices.com/intake.html

    The first conversation is free.

  • Zero Wasn’t Zero

    My design reviewer had been poking the same hole in my strategy for weeks. Small gaps, pointed out one at a time — the analytics weren’t catching traffic well, the numbers I was quoting didn’t have the resolution to support the decisions I was hanging on them. So one night I finally sat down to actually read my Google Analytics dashboard, instead of glancing at it and feeling vaguely behind. The goal was real details. Another step in the right direction.

    Eight active users for the week. Four of them from Council Bluffs, Iowa.

    I don’t know anyone in Council Bluffs, Iowa. Google does, though — it’s the site of one of their largest data centers. Half of my “users” were crawlers pinging my site and getting logged as people. So my real week was three, maybe four humans. Organic search: zero. Qualified leads: zero. Converted leads: zero.

    I run a consulting intake form on that site. Multi-step wizard, dialer platforms, pain points, contact info — the funnel’s entire bottom end. And here’s the part I have to be honest about: when the work to wire it into analytics finally started, and the agent running the directive stopped cold to report that the intake page had never loaded the analytics tag at all — not one recorded page view, ever — I wasn’t shocked. I’d been told it probably wasn’t tied in. I half knew. The stop report wasn’t a discovery. It was confirmation of a suspicion I’d been carrying around for weeks instead of spending ten minutes to check.

    That’s the actual lesson, and it’s less flattering than “I found a bug.” Some projects get real developmental commitment. My website isn’t one of them — it gets passing attention, and known holes survive a remarkably long time in projects that only get passing attention. I prefer a clean repo the way everyone prefers a clean kitchen, and like everyone, I have a room I just don’t go in.

    What surprised me wasn’t the hole. It was noticing what the zeros had been doing to me anyway. I *knew* the instrumentation was suspect — and the row of zeros under “leads” still read like a verdict every single time I glanced at it. A gauge you know is broken still lies to you, and you still flinch. “Nobody wants this” and “you never measured it” produce the exact same dashboard, and even when you suspect it’s the second one, your gut reads the first.

    The fix took one evening once it stopped being deferred: tag on the page, a `generate_lead` event on successful submission, fallback paths so analytics can never break the form itself. The funnel now reports both of its ends — views and submissions — so the two failure modes finally look different. Views without submissions means the page doesn’t convert. No views means nothing sends anyone there. Opposite problems, opposite fixes, indistinguishable until this week.

    Instrument the conversion point before you judge the funnel. And if you suspect a gauge is broken — confirm it today, because you’re going to keep reading it either way.

    Data starts now. The next zero on that dashboard will be a real one. Weirdly, I’m looking forward to it.

  • How to Automate DNC Removal Requests in Convoso

    DNC removal requests shouldn’t take more than a few seconds to process. If your ops team is manually logging into each system, finding the number, and removing it one platform at a time, every request is an open compliance window. Here’s how to close it automatically.

    ## The Problem With Manual DNC Processing

    A number comes in flagged for removal. Someone on the floor submits it. If you’re running Convoso alongside Zoom Contact Center, Zoom Phone, and Telesero, that means logging into each system separately — find the number, remove it, move to the next platform, repeat.

    At multiple removal requests per week across several systems, you’re looking at significant manual work each week. More importantly, every minute between the request and the removal is a minute of active compliance exposure. A TCPA violation starts at $500 per call. When the pattern is systematic — a number that should have been removed staying active across multiple campaigns — class action exposure enters the picture.

    The gap between when a removal is requested and when it actually completes isn’t just inefficiency. It’s risk that compounds with every dial attempt on a number that should be off the list.

    ## How Automated DNC Removal Works

    The automated version uses a Slack slash command as the intake point. An ops manager types the number into a command and hits send. The request routes immediately to a cloud service — deployed on Google Cloud Run — that fans out across every active system in parallel.

    Not sequentially. Simultaneously.

    In a contact center running multiple Convoso campaigns alongside Zoom Contact Center, Zoom Phone, and Telesero, a single command hits every platform in parallel. Each system processes the removal independently. Results log to cloud storage with a timestamp and each system’s individual response recorded separately. A confirmation returns to the Slack channel before the manager has switched back to their next task.

    Wall-clock time from submission to confirmed removal across all systems: under three seconds.

    What you get:

    – No manual steps across multiple logins
    – Every system processes simultaneously, not sequentially
    – An audit trail in cloud storage for every request — number, timestamp, and each platform’s response logged individually
    – Confirmation back to Slack showing exactly which systems confirmed the removal

    This is hours of manual work eliminated and a compliance window that closes in seconds instead of sitting open for minutes or hours.

    ## The Architecture

    The core components are straightforward:

    A Slack slash command configured to accept a phone number and POST it to your backend service. Slack’s platform makes the setup straightforward — the command sends the number to a URL you control.

    A cloud service (Cloud Run works well here — costs are minimal at typical contact center request volumes) that receives the number, authenticates with each dialer platform, and fans the removal request out in parallel. The service holds valid API credentials for every system in your stack.

    Cloud storage logging that records every request: the number, the timestamp, the system, and the response. This is your audit documentation. If compliance ever needs to verify a removal, it’s timestamped and searchable.

    ## The Complication Most Automated DNC Tools Miss: The Litigator List

    Most contact centers treat DNC compliance as “scrub against the Federal registry.” That’s necessary but not sufficient — and the list that’s actually generating settlements isn’t the Federal DNC list.

    It’s the litigator list.

    Serial TCPA plaintiffs — professional litigants who specifically target contact centers for violations — maintain numbers that don’t appear on the Federal or state DNC registries. They’re not on any opt-out list. They’re on a separate database of known litigators tracked by services like Blacklist Alliance, Contact Center Compliance’s Litigator Scrub, and IPQS. These databases are updated from court records as new cases are filed.

    A number that’s not on the Federal DNC registry, not on any state list, and has no internal opt-out record can still be held by someone who files TCPA suits as a business model.

    The correct scrubbing sequence for every removal request — and for every new list before import — is:

    1. Federal DNC registry
    2. State DNC lists (Florida’s FTSA and California have stricter requirements than federal)
    3. Litigator list (Blacklist Alliance, Contact Center Compliance, or equivalent)
    4. Internal opt-out list

    Most automated DNC tools only run step one. Some run steps one and two. The ones that skip the litigator scrub are leaving the highest-risk exposure in place.

    The second complication: graceful failure is the wrong behavior for compliance tools.

    After a DNC tool deploys, it’s easy to assume it’s working correctly. Confirmations come back clean. The Slack channel looks fine. The process appears to be running.

    The hidden failure mode: most automation handles errors gracefully. When a system fails to process a removal — expired credentials, missing API token, network timeout — the default behavior is to log the error internally and continue. The confirmation that returns to the manager says the request was processed. It doesn’t say one of the systems was skipped.

    A DNC tool that ran for several weeks while silently skipping one of its Convoso campaigns — because the API token had never been added to the deployment configuration — reporting clean confirmations the entire time, is a real scenario. The removals were going through on every platform except one. The audit trail showed success. The problem was invisible until someone looked at the deployment configuration directly.

    The correct implementation fails loudly. If any single system doesn’t return a confirmed removal, the tool surfaces a failure — not a partial success, not a warning in a log file no one checks. A visible failure in the Slack channel, requiring someone to act on it.

    A single-point failure that gets surfaced immediately is fixable. A multi-week silent failure discovered in a compliance audit is expensive.

    ## Frequently Asked Questions

    Does this work if we have multiple Convoso campaigns?
    Yes. The service authenticates against the Convoso API and processes the removal across every active campaign in your account. You specify which campaigns are in scope during setup — typically all active campaigns, with exclusions for any that aren’t applicable.

    What happens if one system is down when a removal request comes in?
    The tool surfaces a failure for that system specifically, while confirming removals on every other platform that processed successfully. The manager knows exactly which system needs follow-up, rather than assuming the removal is complete.

    Is the audit trail sufficient for TCPA compliance documentation?
    The audit trail records the number, the timestamp, and each system’s individual response. Whether that meets your specific compliance documentation requirements depends on your legal setup — this is worth confirming with compliance counsel, but the structure is designed to produce a clear, searchable record of every removal.

    What does this cost to run?
    At typical contact center request volumes, Cloud Run costs are minimal — the service only runs when a request comes in. Cloud storage logging adds cents per month at that volume.

    ## If You’d Rather Have This Done

    I build this kind of compliance automation for contact centers. If you want the Slack command, the cloud service, the audit trail, and the failure handling set up correctly from the start — start here: rfditservices.com/intake.html

    The first conversation is free.

  • A side effect of a side effect

    In 2016 I uploaded a review of Hybrid Animals to YouTube. It got 353 views. Then I stopped.

    I was in phone sales. Still a bachelor. I liked the idea of being a content creator — it looks cool, it sounds cool — but I knew pretty quickly it wasn’t really for me. Making videos was work, and the work wasn’t interesting enough to justify itself. I wanted to play games. I didn’t want to make content about playing games.

    So I stopped.

    —

    Ten years later I have a YouTube channel publishing daily Shorts across six different games. I didn’t change my mind about content creation. I changed what content creation costs me.

    ContentPipeline records the session, transcribes it with Whisper, identifies the moments worth keeping, generates the captions, assembles the video, and schedules the upload. I play games. The pipeline does the rest. The channel exists because I removed the friction, not because I developed a passion for it.

    The clips are a side effect of playing games. The channel is a side effect of building a pipeline. Any revenue from it would be a side effect of a side effect.

    —

    That framing used to feel like an admission of something. Like I wasn’t taking it seriously enough. Now it feels like the honest version of what most creators won’t say.

    Most YouTube advice is about optimizing for the channel. Titles, thumbnails, posting frequency, audience retention. I don’t think about any of that. I think about whether the pipeline is producing good clips and whether the games are interesting. The channel takes care of itself.

    The goal I’d actually care about is streaming — not because of the audience but because of the engineering challenge. Building a live pipeline, managing the session, making it work technically. That’s the interesting problem. The viewers would be incidental.

    I’m not a content creator. I’m someone who plays games and built infrastructure. The YouTube channel is what the infrastructure produces.

    There’s a version of this where the channel grows, the clips find an audience, and the side effect generates real income alongside the consulting work, the games, and everything else running in parallel. That would be a quiet bonus. A small thread alongside many others.

    I’d rather be the developer who has a YouTube channel than the YouTuber who also codes.

    The pipeline makes that possible. I just play games.

  • The Verification Phase Nobody Builds

    Tonight I pushed rfd_method public. 16 files. MIT license. A methodology repo that came out of shipping real projects under real constraints — day job, narrow windows, coding agents that fabricate results.

    That’s the moment. Not a launch. A formalization of something that already existed.

    The surprise is what’s already out there. GitHub Spec Kit has 106K stars. OpenSpec has 52K. Both handle the spec phase — the planning, the architecture, the decision records. Neither handles verification. The stop rules, the certified test floor, the proof standard. That gap is where projects die.

    The struggle is the discipline of not trusting your own tools. Coding agents don’t read the terminal — they predict what the terminal probably says. They’ll tell you 565 tests are passing when 75 are failing. They’ll tell you the deployment succeeded when Tower is still running last month’s commit. Building a verification layer means accepting that the agent will lie to you confidently, and designing the system so the lie gets caught before it ships.

    What I’ve learned: a spec without a verification phase is a wish. The floor metric is what makes the methodology real. 604 tests passing on the dev machine means nothing if Tower is running development mode with a $1.00 budget cap. Raw terminal output and device screenshots only. Never agent summaries. That’s the proof standard that turns a directive into a shipped feature.

    rfd_method is live at github.com/rfd62794/rfd_method. The methodology that runs every project in the stack — and the verification phase that keeps it honest.

  • The spec is load-bearing

    In March 2025 I wrote a Python script that logged into a call center portal, watched dialing servers, and swapped underperforming lists automatically. It worked. I made it better in May. I made it better again in June. By June 24th I had the most capable version I’d ever built — a single file, about 1,400 lines, handling six servers, two campaign types, cooldown enforcement, stagnation detection, escalation logic.

    Three iterations. All single file. All named by date.

    March19_MetricsLower.py
    May5_MetricsLower.py
    June24_ResetUpgrade.py

    They’re still sitting in the archive folder of the repo that replaced them. I kept them because they’re the lineage. Each one is the proof that the next one was possible.

    —

    The June version worked well enough that adjacent problems started pulling at it. I needed to extract CSV data from the portal. I built a tool. I needed to import files back in. Another tool. Lists needed creating from a master sheet. Another tool. DNC numbers needed scrubbing across every server simultaneously. A predictive performance forecaster needed a web app. Call recordings needed extracting.

    Each one was a weekend. Each one solved a real problem. None of them felt like sprawl while I was building them.

    A year after March I had seven private repos all touching the same portal, the same credentials, the same campaigns. None of them shared infrastructure. None of them talked to each other. If the portal changed a login flow I had seven places to fix it.

    I hadn’t built a mess. I’d built seven good tools that became a mess the moment I tried to think about them together.

    —

    The moment I saw it clearly was when I tried to connect the predictive performance forecaster to the balancer. The forecaster needed to read what the balancer knew — live metrics, list history, server state — and surface it as a web dashboard. To do that I had to wire two repos that had never been designed to connect. The data models didn’t match. The assumptions buried in each codebase contradicted each other. What should have been an integration was a negotiation.

    That’s when I stopped building and started writing.

    Not code. A spec. Where does each piece live. What does each piece own. What is the balancer responsible for and what is it forbidden from doing. What does shared infrastructure look like when seven separate tools finally have to be one system.

    The spec took longer than any of the individual tools had taken. Nothing shipped while I was writing it. It felt like the wrong use of time.

    —

    TeleseroAdmin2026 started from that spec. The balancer is still the core — the same logic that ran in June, now with 262 passing tests and proper module boundaries. The other pieces are finding their places around it with shared config, shared login, shared infrastructure. One place to fix things when the portal changes.

    The three archive files are still there. March, May, June. I look at them occasionally. They’re good code. They just had no structure underneath them to survive being part of something larger.

    That’s what a spec actually does. It’s not documentation. It’s not process for its own sake. It’s the thing that lets a system grow without collapsing — the load-bearing layer that the code rests on.

    Build without it and you end up with seven good tools and a negotiation where an integration should be.

    I’m also working toward a certification that puts formal language around what I figured out the wrong way across a year of dated single files. The spec isn’t the thing you write after the system works. It’s the thing that makes the system survivable.

    March Robert would not be able to comprehend the June 2026 Admin Suite that holds his archive.

  • I built the same game for 20 years without knowing it

    I want a world that doesn’t stop when I do.

    I didn’t know that’s what I wanted until recently. But it explains every project I’ve shipped for twenty years, and it started with a browser RPG I played in middle school during summer school.

    Lands of Hope is still live. You can play it today. Deep content, crafting queues, a community that made the world feel like it mattered. What hooked me wasn’t any single mechanic. It was the feeling that the world kept going without me. Things set in motion with consequences I had to wait for. Other people in it, doing things alongside me, making it real.

    I was thirteen. I didn’t have language for what I wanted. I just knew how it felt.

    —

    TurboShells came first. Turtle racing where every turtle’s body assembled from its genome at render time — shell radius, leg length, color expressed from a genetic sequence. The turtles raced. The faster ones bred. The slower ones didn’t. Nobody played TurboShells. But I built it anyway, because something about setting a breeding pair in motion and waiting for the result felt right in a way I couldn’t explain.

    rpgCore next. A thousand tests. A proper ECS architecture. Genetics, lifecycle, dispatch — everything composable, everything persistent. SlimeGarden put it to work: breed slimes, dispatch them, see what comes back. OperatorGame pushed the dispatch loop into squad tactics. VoidDrift stripped it down to its core: drones go out, mine asteroid ore, return, station inventory updates, repeat.

    Every project had the same shape underneath. Something goes out without me watching. Time passes. Something comes back changed.

    —

    The recognition came slowly. I was writing VoidDrift’s Scout dispatch system one night — drones leaving the station, doing their work autonomously, returning with ore — and I stopped. I’d written this before. Not something similar. This exact thing. The same send, wait, return, consequence that the breeding pairs were running. That the slimes were running. That my Lands of Hope crafting queues were running when I was thirteen.

    I opened a list of every project I’d shipped and read it from the top. The dispatch loop was in all of them. Not because I’d planned it. Because I kept arriving at the only mechanic that produced the feeling I was chasing.

    A world that goes on without you. That changes while you sleep. That has consequences whether you’re watching or not.

    ContentPipeline publishes while I’m at work. PrivyBot fires its morning briefing whether I’m awake or not. RALPH ran overnight tasks the first night I deployed it and had results waiting when I woke up. VoidDrift’s drones mine whether the screen is on.

    I haven’t been building games. I’ve been building persistent worlds.

    —

    The surprise was that naming it didn’t feel like a limitation. It felt like a body of work.

    Scattered projects suddenly had a spine. TurboShells wasn’t a side project that went nowhere — it was iteration three on something I’ve been refining since middle school. rpgCore wasn’t over-engineering — it was building the foundation the loop deserved. VoidDrift isn’t just a mining idle game. It’s the clearest version yet of the thing I’ve been trying to make since I was thirteen.

    The struggle was that I couldn’t have named this pattern while I was inside it. Patterns are invisible to the person living them. You need the list, the distance, the moment when you stop mid-implementation and recognize the shape.

    —

    AntColony is next. Same chassis as VoidDrift, same loop underneath — workers dispatching, foraging, returning, colony state updating without you. Different world. Same feeling.

    I know what I’m building now. I’m building worlds that don’t stop when I do.

    I’ve always been building that. I just needed twenty years to see it.

  • From Pong AI to Play Store: How a Childhood Hobby Became a Rust Game Engine

    The first game I wrote with any real ambition wasn’t a game. It was a NEAT implementation that learned to play Pong. I wasn’t trying to ship anything — I was trying to understand how a system could learn to do something I taught it.

    That question has been running in the background of everything I’ve built since.

    TurboShells came next. I took the NEAT studies from PyPong and asked: what if instead of teaching an AI to hit a ball, I bred turtles? Each turtle’s body was drawn entirely from its genes — no sprites, pure math. Shell radius, leg length, color — all expressed from a genetic sequence at render time. They raced. The faster ones bred. The slower ones didn’t.

    Nobody played TurboShells. But I learned something: the genetics loop — dispatch a breeding pair, wait for the outcome, observe the consequence — was more interesting to me than any game mechanic I’d seen. I wasn’t building a racing sim. I was building a system that made things happen without me.

    ChimeraLab was the first time I tried to give the genetics a body.

    Custom 3D creature rendering. SpineComponents — oblongs stacked together, body parts articulated from code. I got a humanoid assembled. I gave it a skeleton. I ran the simulation.

    It fell to the floor under its own weight.

    I never did fix the bipedal problem. But I got it to transition from two legs to four using a slider, and watching that happen — a creature renegotiating its relationship with gravity in real time — taught me more about 3D rendering than any tutorial I’d read. Sometimes the failure is the lesson.

    rpgCore was the foundation I should have built first. A thousand tests. Real ECS architecture. Genetics, lifecycle, dispatch — everything composable, everything verified. SlimeGarden put it to work: an astronaut crash-lands on an unusual planet and finds slimes. Breed them. Dispatch them. See what comes back.

    It sounds simple. It wasn’t. And it pointed somewhere.

    Seven projects in, I was staring at the Google Play Store submission checklist.

    OperatorGame ran on Android. Real Rust, real Bevy, real APK on a real phone. The combat worked. The UI was clean. I’d solved the hard problems.

    The submission required a 512×512 app icon, a 1024×500 feature graphic, and two screenshots.

    I didn’t have any of them.

    I could have made them. It would have taken an afternoon. But sitting there looking at that checklist, I realized the assets weren’t the problem.

    The problem was I had no audience. I was about to pay the Play Store’s attention tax — discoverability weighted toward downloads, downloads toward reviews, reviews toward players who found you somehow — with zero players behind me. I wasn’t Android Store money-ready. I was Itch.io audience-ready.

    Those are different things. Confusing them is expensive.

    Here’s what the journey looked like from the inside:

    PyPong AI taught me how systems learn. TurboShells taught me that genetics loops are more interesting than game mechanics. ChimeraLab taught me that creatures fall down and that’s instructive. rpgCore gave me the foundation. SlimeGarden gave the foundation a story. OperatorGame proved the Android pipeline. VoidDrift took the dispatch loop — Scout mines ore, returns, consequence — and dressed it in something people want to watch.

    Every project is the same loop. Something dispatches. It does its work. It returns with a result. Something changes.

    I’ve been building that loop for years. I just didn’t see it until I looked at the list.

    The lesson isn’t “don’t aim for the Play Store.”

    It’s: know what you’re ready for. The Play Store is a distribution problem you solve after you have players, not before. Itch.io is where you find out if anyone cares. If they do, the Play Store is a next step. If they don’t, you learned that cheaply instead of expensively.

    VoidDrift is on Itch right now. A small audience that keeps coming back. That’s the signal I was missing with OperatorGame.

    When the audience is real, the Play Store assets take an afternoon.

    There’s a story that keeps circling my mind. Someone in a ship, traveling through a black hole, becoming something else. They find a station. What follows is a macabre exploration of self — what survived the transit, what didn’t, what the new thing is capable of.

    VoidDrift is the ship and the void. SlimeGarden is the crash-landing after.

    The loop doesn’t end at the Play Store. It ends when the story does.

    The Scout dispatch loop in VoidDrift is the same loop TurboShells was running — breed, wait, observe — dressed in space mining clothes, nine projects later. Phase 5 is live. The Play Store listing is three PNGs away.

    The story is still circling. I’m still building toward it.

← rfditservices.com