The long build
Nearly three years to get one app ready.
I kept paying for another round of work because the reason for building Circle still made sense. By my account, the development costs approached half a million dollars.
The app was becoming real. So was the cost of every decision still left to make.
Chapter three
There was always another detail.
Getting the app right took nearly three years. That number is easy to read past. Living through it meant repeated decisions, corrections, and another attempt to make complicated work feel clear to the people doing it.
A screen could look finished while an important case remained unanswered. A role could behave correctly until someone changed responsibility halfway through a deal. The dependable version was the one that could handle the ordinary complications people would bring to it.
The difficulty was that the exceptions were ordinary life. People change their minds. A document arrives late. The person responsible for something is suddenly unavailable. We could not make the work dependable by assuming all of those things away. The app had to make sense to people who were already busy, sometimes worried, and trying to keep the transaction moving.
I kept going because those people were still the reason for the app. But believing in the work did not make the time free, or the next correction any less expensive. Progress and pressure arrived together.
The long build
We had to understand the same problem.
Knowing what I wanted people to experience was not the same as explaining every detail needed to build it. The idea had to survive the journey from a real situation to a screen, a rule, and a result.
Corrections were part of that conversation. A feature could meet its description while still feeling wrong in use. Another pass might be needed to explain what a person was trying to do and what should happen next.
An ordinary example could often reveal more than a long description. What does this person need to see? What are they allowed to change? What will the next person understand from the record? Working through those questions made the desired result more concrete. It also reminded me that a technical answer was only useful if it served the situation that prompted it.
I learned to look for the human task underneath the technical discussion. That lesson stayed with me. It would eventually help me question the work surrounding the product as carefully as the work inside it.
The long build
The money bought another chance to get it right.
Close to half a million dollars is a difficult figure to put beside a little icon on a phone. It did not buy a guaranteed audience. It paid for the work needed to make the app useful and dependable.
Each change needed an explanation, an implementation, and a check. Sometimes making one part clearer exposed a problem somewhere else. There was no single purchase that made the remaining work disappear.
There is a difference between paying to add something and paying to make what is already there work properly. Much of the value in a dependable product is hard to show in a picture. A person may never notice the cases that were handled correctly. They would certainly notice the one that failed when they needed the record most.
When I looked ahead, I pictured people finally using the thing we were making. That picture gave the effort a purpose. I had not yet understood how much work could sit between a finished product and the person waiting to use it.