Case study: the systems behind our own company
Before ikonic303 sold engineering, it ran an on-site installation business in Thornton, Colorado, and that business is where every system we sell was built first. This page reports what runs there today, the numbers measured on October 27, 2026, and what has not worked yet.
The operating company
Our operating company does on-site installation work for property owners across the Denver metro, working from Thornton. One person runs it: Josh Soderblom, who also runs this engineering practice. There is no office staff. Everything an office would normally do — answering, quoting, follow-up, reporting, checking our own work — is either a system or it does not get done.
That constraint is the reason ikonic303.dev exists. We did not start with a methodology and look for a client. We built these systems because our own business needed them, then started offering the same discipline to other operators.
What we built
1. A standing agent fleet, with every run logged
The back office runs on scheduled AI agents. Each one has a single job, a written rule set, and a log line for every run, including the runs that failed.
| Measure | Value |
|---|---|
| Agents defined on the schedule | 74 |
| Runs logged | 4,643 over 63 days (August 26 to October 27, 2026), across 76 agents |
| Completed OK | 3,645 (78.5%) |
| Errored | 47 |
| Skipped by their own rules | 951 |
Our pass rate is 78.5%, not 99%. We publish the real number because it is the honest baseline every improvement gets measured against.
2. A safety check that runs before any price is quoted
Some of the products we install can damage the customer’s property if the product and the surface are a bad match. We turned the manufacturer’s compatibility chart into a lookup table with 972 product-and-surface combinations: 624 safe, 22 use-caution, 326 not safe. No quote is produced until the customer’s surface has been identified and the table clears that exact product on it. If the surface is unknown, the answer is “we don’t know yet”, never “probably fine.”
This is the pattern we bring to client work: when a mistake is expensive, the rule lives in the software, not in a training document.
3. Rules written as code, with their own tests
Rules like “never message a customer overnight,” “never quote a price that is not on the price list” and “never publish a street address” are enforced by code that refuses the action. Each rule set has a self-test that has to pass before we say the rule is enforced. The defect-routing guard currently passes 36 of 36 of its own checks.
4. Every problem found becomes an assigned task
When an agent finds a broken form, a dead link or a bad setting, it has one way to report it: a command that turns the finding into an assigned task with the evidence attached, and refuses findings without evidence. 289 defects have been routed that way so far.
Problems that got past the rules are logged separately as escapes and reviewed weekly. There are 26 on record. Every costly escape we have had ended with a “success” exit code, which is why we do not treat a clean exit as proof that nothing went wrong.
What has not worked yet
- Revenue from the current service line. The operating company narrowed to one service line in 2026. We will publish job counts, average ticket and close rate once there are enough closed jobs for those numbers to mean something. Until then we make no revenue claim for it.
- Being cited by AI assistants. We have not yet measured our own site being named in AI answers since the business split into two domains, so we do not sell it as a proven result.
- Running social publishing for others. Our own publishing connections lapsed and have not been restored. Until our own channels run reliably, we do not offer it.
- Email authentication on every domain we own. Not all of our own domains pass our own check yet. We do not offer this check as a service until they do.
- Lead response time. We have not measured it end to end, so we do not quote a number for it.
What this means if you hire us
You get the same method we apply to ourselves: measure the workflow first, put the expensive rules into code, log every run, and report failures next to successes. You also get the same rule about claims — if we have not measured it on our own business, we will not promise it on yours.
How an engagement runs · What it costs · Start a conversation
How to check these numbers
The fleet, rule and defect numbers come from one command that reads our run log, our schedule, our defect log and our rule self-tests, and prints each claim as proven or unproven. The safety-check counts come from the lookup table itself. We re-run both before this page changes.
Josh Soderblom · About ikonic303 · How an engagement runs · The guides
Get in touch
Email solutions@ikonic303.dev to start with the measurement. ikonic303 is based in Colorado and works with clients nationwide.