The decisions that don't iterate
Most software people we admire ship fast. We do too. Every tool we have shipped moved from idea to released product in roughly the time you'd expect. The "ship fast and iterate" instinct is correct for the bulk of what a team builds.
But the same instinct, applied to the wrong decisions, is what most software regret turns out to be.
Some decisions iterate cleanly. You ship a version, watch how people use it, and adjust. The cost of being wrong is roughly the cost of one bad release.
Other decisions do not iterate cleanly at all. You ship them, they propagate through the system, and three years later you are still living inside the consequences with no good way out. The cost of being wrong there is the cost of every decision that came after, all stacked on top of the original mistake.
We have learned to identify three of these the hard way.
The first is schemas. The data model you ship in week one is the same data model your migration scripts will fight five years later. Every feature you build sits on top of it. Every report queries it. Every integration assumes it. You can rename columns, you can add tables, but the underlying shape of what you store and how is one of the hardest things in software to actually change. We sweat schema decisions in a way we do not sweat almost any other decision.
The second is interaction patterns. The first version of how a user does something becomes the version they remember. If your sign-up flow asks for a phone number before the user has seen anything useful, that is forever the way new users meet you, even after you change it. Power users will keep doing things the way they learned. Even your support docs will reflect the old shape, because that is what people are still confused about.
The third is early hires. The taste of the people you bring on in the first year is the taste that defines the product. They review every PR. They sit in every product review. They train the next set of hires. By the time you notice a hiring choice was wrong, the choice has already shaped the inside of the product in ways that take years to unwind.
These three share a property. They are not features. They are not decisions you ship and then learn from. They are conditions you set up, that everything else then operates inside of. Iteration is still happening. It is just happening inside a frame you have already drawn.
The trick is not to be slow. The trick is to know which decisions are inside the frame and which decisions are the frame.
We ship the inside-the-frame stuff fast. We are uncomfortable with the framing decisions. We make them once, we make them carefully, and we accept that we are going to live with whichever version we picked.
Ship fast. But know what you are shipping fast on.
Other notes
We measured our own em dashes, then banned them anyway
The data says density is the tell, not presence, and our prose was already under the human baseline. We adopted the stricter rule regardless. Here is the argument that beat the evidence.
Admissions stopped trying to detect, and started changing the format
Universities are switching off their AI detectors, not upgrading them. The interesting part is what they are replacing them with, and what it asks of a seventeen-year-old.
Who supplied the judgment
The provenance conversation has moved from whether a machine wrote something to who decided. We have been shipping an answer to that question, per product, in public, for a while now. Here is what it cost us to keep it honest.
We do not know how many people use it
Privacy-first is the most crowded claim in mobile right now. Ours cost us the ability to answer the first question anyone asks about a product, and we would rather describe that cost than the feature.
The gate that passed by never running
We spent a week building checks that guard our writing and our code. Four of them reported clean while checking nothing at all. Every one was found by running something, and none by reading the code.
Why we built Tennis Tutor
A junior player gets an hour of correction a week and then practises for six. The scarce thing is not court time. It is someone watching closely enough to tell you what you actually did.
Why we built Myeiyo
Chore apps either turn kids into tiny investors or turn chores into a video game. Neither matches what actually happens in a house. We built the one that does.
What 'honest software' means in practice
We use the phrase a lot. It is easy to say. It is harder to specify.
Why we built Vyzrly
College admissions has always been a black box. We wanted to make it a little more honest.
When AI is the wrong tool
The reflex to reach for AI on every problem is a symptom of taste failure, not technical sophistication.
Why we built Glossem
Product copy lives inside code. That is a problem for everyone who is not an engineer.
Why we built USACO Tutor
Competitive programming builds a kind of thinking that matters. We wanted to make that more accessible.
Why we built ChessWarp
Every chess app asks you to find the best move. In real games, nobody tells you there is one. That gap is where most club players are stuck, and it is what we set out to fix.
Why we built Break the Test
The SAT has seven versions in circulation. Serious students burn through them in a month. The bigger problem is that even unlimited practice would not fix the thing that actually costs them points.