← All notes

Status of the Tech Wing

This is a status update on the software side of the company. It is more technical than most of what we publish, because the point is to show the work rather than describe it.

Short version: the tech wing is now the fastest moving part of this company, it operates across eight codebases, and the way we build has changed enough this year that it deserves an explanation rather than an announcement.

What we run

Eight repositories in active development. A password reset and authentication service with its own marketing site. A privacy tool that finds where someone's personal information has been listed and gets it removed. A monitoring and scraping platform. An e-commerce backend. A landscaping business site with an admin. This company's site. And an open source crypto portfolio reader, released under MIT, which is the only one of the eight you can read in full.

They share almost no code and quite deliberately so. What they share is a set of standards.

What shipped this month

Every database moved onto one managed cluster. Six applications, years of separately accumulated decisions, consolidated into a single replicated home with automatic failover. The migration itself was uneventful. What was not uneventful is written up in Two Characters, and the short version is that the hardest bug of the week was punctuation.

A full security review of the authentication service, with the fixes shipped the same night. Server-side request forgery gaps closed, including the cloud metadata endpoint that is the standard target for stealing credentials out of a hosting environment, the whole loopback range rather than just the obvious address, IPv6 loopback, addresses obfuscated in decimal or hexadecimal, and carrier-grade NAT ranges. Rate limiting on magic links. Security headers. That service now runs 195 tests, all passing, with none of them marked as work for later.

The interesting part is not the list. It is that the validator resolves a hostname and checks every address it points at, at the moment of use rather than when the value was first saved. A destination that was safe when a customer entered it can point somewhere else five minutes later. Validation that runs once is validation at the wrong time.

The authentication service now serves through a database outage instead of dying. A dependency being down should degrade a product, not end it.

The crypto reader learned to distrust itself. Contract addresses and chain identifiers had been written into a table by hand, which looks authoritative and is really just a guess. A mistyped address that happens to point at a real token returns a real balance under a confident wrong label. A wrong decimal place is a tenfold error. It now reads each token's identity from the chain itself and treats anything that disagrees as suspect rather than displaying it. Endpoints are probed at runtime from a candidate list rather than hardcoded, so a dead provider gets skipped instead of silently removing an entire chain from a total.

We published a correction. We had stated in an earlier post that a particular cost basis method was what most tax regimes apply. That is not true in the United States. The correction is here, at the top of the original post, and in the code.

The standards

Three things we actually hold to, as opposed to things that sound good in a post.

A check that is not tested is a wish. It is easy to write a validation function, watch it reject the obvious bad input, and move on. The cases that matter are never the obvious ones, and validation quietly stops working when somebody refactors around it. So every property we depend on has a test asserting the bad input is refused, including the awkward variants. The tests are the security control. The code is just what makes them pass this week.

Check at the point of use, not the point of entry. Covered above, and it applies well beyond security. Anything that can change between when you approved it and when you rely on it has to be checked again at the moment you rely on it.

Compare the number against the world. Software that reports a total will happily report a plausible wrong one forever, because nothing about a plausible number asks to be checked. The only defence is the unglamorous discipline of periodically holding your output next to the thing it claims to describe. Every real problem we found in the portfolio reader this month came from doing exactly that, and none of them were visible from inside the application.

What changed in how we build

We use AI agents heavily now. Not as autocomplete. As a fleet.

Work runs in parallel across repositories, with separate agents holding separate contexts, and a coordinating layer keeping the boundaries straight so two of them never edit the same thing at once. Research that would have been a week of reading gets done overnight. Code review happens continuously rather than at the end.

Three honest observations about what that is actually like.

The bottleneck moved from typing to deciding. Less time writing lines, considerably more time judging whether an approach is right, whether the scope is correct, whether it matches what already exists. That part got busier, not easier.

Verification became the primary skill. The single highest-value habit is asking small boring questions constantly. Is it actually pushed. Did that test actually run. Does the live page actually say what we think it says. Not because an agent is dishonest, but because a confident summary and a verified fact are different objects and only one is worth anything. We caught a push this month that reported success and had moved nothing. It was caught because somebody asked.

Tests stopped being homework and became the referee. When you write every line yourself, tests confirm what you already believe. When work arrives faster than you can read it closely, the test suite is the one participant that cannot be talked into agreeing with you.

There is a version of this that produces a large amount of confident garbage very quickly. The difference is entirely in whether anybody is checking.

Where it is going

The software side started as internal tooling to keep our own overhead near zero, and it is now something we do for clients as well. That is the honest arc: we built things for ourselves, they worked, and people asked.

We are expanding what we build and keeping the same rule about what we say. Nothing described as advanced. Nothing claimed that is not tested. Corrections published where the mistake was.

If you want to see how we work before talking to us, the open source reader is all of it in public: the tests, the security policy, the contributing rules, and an explicit promise that it will never be able to move your money. And if you want something built, that is on the services page.

Gunnar

Founder, Tofte Ventures LLC