Old Versus New
By Dan Brooking

How did selling something useful become so complicated? I had to find out the expensive way.

This is my account of building Circle and the lessons I draw from older ways of selling. The scenes of door-to-door selling illustrate the comparison; they are not events from my own life.

I had an app. Why did I need all this?

There seemed to be a business for everything except letting the product prove itself.

After nearly three years of development and costs approaching half a million dollars, by my account, the original Circle app was ready. I wanted people to try it. Instead, I faced a new education in everything that could come between making something useful and getting it into someone’s hands.

There were stores, listings, promotion, tracking, advice, and tools to help manage the other tools. Each part could have a purpose. Taken together, they made a question I thought was simple feel impossibly far away: does this help the person using it?

I began thinking about an older kind of sale. Someone brought a product to a door. The person inside could judge it. The seller would have to come back. What had we gained since then, and what had we made harder than it needed to be?

This is not a wish to turn the clock back.

I build software because of what it makes possible. A small app can reach someone far away, help with a language I do not speak, and give a person a place to keep information they need. I want that reach.

What troubled me was the growing amount of work around the useful part. I could understand each new recommendation and still lose sight of where the whole collection was taking me. The customer was becoming harder to see.

This book follows that problem through the choices I faced after building Circle. The old doorstep is a way of asking a question about the present: can we make something modern and still keep the person using it close?

Chapter 1: The old route

Imagine having to come back to the same door.

Picture a person selling a household product door to door. The customer can see what it is, ask questions, or say no. If they buy it, they will soon have their own opinion. The seller may be standing on that doorstep again next week.

That is the part of the old route that interests me. A promise had to survive use. A persuasive demonstration could start a relationship, but the product had to do something useful if that relationship was going to continue.

The picture works because you can understand both sides without a manual. One person hopes the product is worth buying. The other hopes it is worth selling. Their interests meet in what happens after the sale. When I felt lost in the modern work around Circle, that clear point of contact helped me remember what I had wanted the business to accomplish.

I do not mistake this picture for a perfect past. Selling could be pushy, products could disappoint, and a person could only travel so far. I am interested in the closeness of the test. The person making the promise could not stay very far from the answer.

One product. A person who could say no.

This is an imagined doorstep, not a scene from my life. I use it because the question is easy to understand: will this thing do what the person selling it says?

The answer arrives when somebody uses it. That is the part I wanted to keep in sight.

A sale was not the end of the conversation.

Going door to door took effort. Many people would not buy. The seller had to keep trying, learn what people needed, and decide whether the product was worth carrying around in the first place.

A return visit added another kind of discipline. It gave the customer a chance to ask for more, explain a problem, or close the door. The product had to live with the result of its first impression.

For an app, returning can be a small act. Someone sees its icon because the same problem has come up again. They remember what it did last time and choose to open it. I find that a useful standard to build toward. It asks more of the product than an attractive first impression, while keeping the answer close to the person’s experience.

That made me think about what a useful app should earn. A download can tell you someone was interested. A person coming back because the app helped tells you something more. I wanted to build for that second moment.

Trust could travel to the next doorstep.

In the older route I am describing, a satisfied customer could tell a neighbor. The seller might arrive at the next house with an introduction that mattered because it came from someone whose experience was known.

That kind of trust had to be earned. It could not repair a product that disappointed people, and it did not guarantee that everyone would want the same thing. It helped the useful experience become easier to discover.

Recommendations also carry a responsibility. If someone tells a friend an app helped them, the friend deserves an explanation that matches what they can actually use. A feature that worked in a test is not the same as one available to every customer. Keeping those distinctions clear protects the trust that a useful experience may have earned.

The modern version still begins with someone having a reason to recommend what they used. I wanted to give Circle that chance by making the experience itself worth talking about.

Chapter 2: The modern maze

Now put that product in today’s world.

The person carrying a product can become a maker managing a website, store listing, payment account, advertising, search results, email, and reports. Technology has made it possible to reach far beyond one neighborhood.

That reach is valuable. But the work can also multiply. One service needs an account in another. A recommendation introduces another subscription. Soon the maker is learning a new business alongside the one they thought they were starting.

The modern maker can be surrounded by opportunities and still struggle to choose the next useful action. Each specialist sees a part of the work they can improve. Someone still has to decide how those improvements fit together. I was learning that the ability to buy help for a hundred different tasks did not make the whole undertaking easier to understand.

I recognized that situation because I was in it. Circle had a job to do. Getting it to the people who needed it was becoming a much larger job than I had imagined.

I wanted the reach. I needed to understand the cost.

The internet can give a small maker a chance to reach someone they could never meet in person. Secure payments and software delivery can make that relationship practical. I was not looking for a way to give those things up.

I was looking for a way to tell which parts were necessary. A service could be impressive without being useful to Circle at that stage. A recommendation could be reasonable without being something we could afford to maintain.

A long list of familiar services can feel reassuring because each name comes with an explanation. But recognizing the names is not the same as understanding the arrangement. I needed to know what happened from the visitor’s first question to the app opening on their device. Looking at that sequence made some choices clearer and others much harder to justify.

The distinction mattered. If I accepted every additional layer as the price of being modern, I could spend all my time managing the introduction and leave too little for the product being introduced.

What was worth bringing into the present?

I would not give up the ability to reach someone across a country or an ocean. I would not replace secure online access with a system that only worked when I could be there in person.

What I wanted to recover was the clarity of the relationship. Here is what the product does. Here is what it costs. Here is how you can use it. If it helps, you know where to return.

A direct relationship is not automatically a good one. It has to be made clear and maintained with care. The page has to be honest, the payment has to work, and the customer needs a dependable way to return. Remembering that keeps the idea practical. We are responsible for the experience we choose to own, including the parts that are easy to overlook.

That is an old idea with a modern opportunity. The difficult part is resisting the additions that make it harder to recognize.

Chapter 3: One transaction needed a memory

My app began with missing pieces.

A real-estate transaction involves people who all need the work to go well. Yet the information can end up divided between email, text messages, documents, notebooks, and memory. A question about the deal can become a search through all of them.

That was the problem behind the original Circle app. I wanted the people, tasks, messages, documents, and acknowledgments to stay connected to the transaction. Someone should be able to follow what happened without piecing it together from scratch.

A message can be perfectly clear when it is sent and difficult to interpret later. Who was it about? Which version of the document did it refer to? Was the request acknowledged or simply delivered? The original Circle app was meant to keep those relationships visible. It was the sort of problem whose importance becomes obvious when somebody needs the answer and cannot find it.

It was a practical idea with a practical test. Could the app make the deal easier to keep track of? That is the question I carried into the build, long before I began thinking about everything involved in selling software.

The useful part took nearly three years.

By my account, development costs approached half a million dollars. The time and money went into making the original app dependable: its roles, access, tasks, records, and the way those parts worked together.

I kept going because the underlying need had not gone away. People still needed a reliable way to know what had happened in a transaction. A convincing demonstration was not enough if the app could not handle the real work.

Dependability was made up of details a person might never think to thank us for. Access had to make sense. A record had to remain connected to the right transaction. Handing over work should not require handing over somebody’s entire memory of it. The point of doing the difficult work was to let the person using the app think about their own job.

When it was finally ready, I wanted to hear from the people it could help. That felt like the natural next chapter. I did not expect the business around reaching them to become a story of its own.

I had made something people could use.

Getting Circle ready had taken years of decisions and corrections. I had a reason to be proud of the work, and a strong reason to want the next part to begin.

What I needed now was a way for the right people to find it. That was where the difficulties changed shape.

Chapter 4: The modern stack

The app acquired a second business.

The work around selling it had its own language and demands. Branding, positioning, search, advertising, email, and measurement all wanted attention. It became possible to spend an entire day around the product without changing anything the customer would use.

Each task could be justified. That was what made the problem difficult. There was no single foolish decision to remove and make everything simple. The weight came from the collection.

There was a temptation to treat being busy as evidence that the business was moving forward. Much of the work could produce something visible: another page, another report, another connection. The harder question was whether that output changed the customer’s experience. I needed to be willing to ask it even when the answer made an impressive amount of activity look less useful.

I needed to step back far enough to see the whole cost. What was this growing business actually doing to bring someone closer to the app?

The useful idea was becoming hard to see.

Around a finished product, many other businesses can find work. That does not make the work dishonest. But it can move the maker’s attention toward serving the surrounding businesses instead of the intended customer.

I had to notice that change before I could do anything about it. Circle’s original purpose was easy to explain. The growing collection around selling it was much harder to describe in the same plain terms.

A customer does not usually arrive wondering whether a maker has the latest collection of business tools. They arrive because something in their own life needs attention. I wanted our work to begin there again. That meant describing the situation plainly enough that the right person could recognize it, and leaving enough room for them to decide whether the app fit.

I wanted the product to become visible again. That meant choosing a way of working in which someone reaching the app was the point of the effort, not a distant outcome I kept hoping would follow.

The numbers could keep me busy forever.

Reports can answer useful questions. They can also create a steady supply of new ones. A chart changes, and somebody has to decide what it means. A number improves, and it is tempting to assume the customer’s experience improved with it.

I wanted to know which measurements were connected to the work that mattered. Did people understand the offer? Could they install? Did the product do what they expected? A larger number somewhere else could not answer those questions for me.

A useful measurement should make a decision easier. If it cannot tell us what to improve or whether something worked, it can become another demand on attention. I wanted to keep the questions understandable enough that a result would mean something. A person reaching the right installation page is a clearer event than a general feeling that the numbers ought to look better.

The danger was spending more effort explaining the reports than understanding the person. A product can become easy to measure and difficult to see clearly at the same time.

Another tool for the tools I already had.

The growing collection promised to make the work easier. Keeping that collection useful became work of its own.

The question was no longer simply what another service could do. It was how much of my attention the whole arrangement would leave for Circle.

Chapter 5: More layers arrived

The next answer came with another obligation.

A new service can offer relief from a real difficulty. But taking it on also means learning it, setting it up, paying for it, and keeping it connected to whatever comes next. The promise arrives before the maintenance.

After years spent getting the product ready, that growing list was hard to carry. The next step could look necessary without bringing a clear end any closer. I could imagine doing more and more while still waiting for the useful part to begin.

The expense was not only the amount on an invoice. It was the uncertainty about whether any of the additions would bring an end to the preparation. After spending so long making the product real, I wanted the next effort to lead to use. The possibility of an endlessly growing business around that effort was what made a different approach feel necessary.

I had finished the app and still could not see the end of the work. Every attempt to get closer seemed to add another thing to carry. I began to wonder whether the people I had built it for would ever get a fair chance to use it.

Doing everything was no longer a plan.

There is always something new a business could try. The possibility of missing the thing that finally works can make it difficult to stop adding. A new recommendation arrives before the last one has had a fair test.

I needed a more disciplined question than whether an idea sounded promising. Did it solve a current problem? Could we tell if it worked? Was the result worth the time and cost of keeping it?

There is a kind of confidence in knowing why you are not doing something. It is different from pretending the opportunity has no value. I could recognize that a service helped other businesses and still decide it was not the right next step for Circle. That made it possible to keep learning without treating every new recommendation as an instruction.

That did not make the uncertainty disappear. It gave me a way to act within it. Leaving something out could be a deliberate choice, rather than another reason to feel behind.

My attention had a limit, even if the task list did not.

Time spent evaluating another service was time I could not spend understanding the app. Time spent connecting tools was time I could not spend making the next step easier for a customer.

That was the cost I could feel even when it did not appear neatly on a bill. A small maker cannot give unlimited attention to an unlimited number of obligations. Something important eventually gets less than it needs.

There was relief in having a reason to simplify that was connected to the product. I did not have to prove that every service was unnecessary. I had to choose what helped this app reach and serve its users. That is a smaller question, and one that can be revisited as the real needs of the business change.

I needed to choose what deserved the hours. Bringing the customer back into focus made that choice possible. The work could become smaller, clearer, and closer to why I had started.

Chapter 6: The AI layer

Then AI offered another set of possibilities.

AI can help with real work. It can help shape a message, organize information, or make a conversation possible across languages. I build with it because those uses can matter to people.

It can also become another layer to manage if the purpose is unclear. A tool that produces more material does not necessarily bring someone closer to the answer they need. The amount of output is not the same as the amount of help.

I wanted to judge an AI feature in the same way I would judge another part of the app. Can the person understand it? Does it produce something useful for their task? Can they tell what to do with the result? Those questions make the discussion more practical than treating the presence of AI as a benefit in itself.

I wanted to use AI with a job in mind. What is the person trying to do, and what would a useful result look like? The question was familiar, even though the technology was new.

I wanted help I could explain.

An app needs to be clear about what it can do, what information it uses, and where its limits are. That matters especially when a fluent answer can sound more certain than the evidence behind it.

The useful work includes setting boundaries, checking results, and leaving appropriate decisions with the person. A tool can help someone prepare a message without deciding to send it for them. It can organize information without turning a guess into a fact.

A boundary can make an app easier to use as well as easier to trust. When the job is clear, the person knows what kind of help to ask for and what to do with the answer. A tool that tries to do everything can leave them with another decision to untangle. I wanted our products to make the next useful action more obvious.

Those choices belong in the product, not just the promise on its website. I wanted the same care behind the screen that a reader would expect from the words in front of it.

Chapter 7: The invisible costs

Some costs reach the customer quietly.

When more services surround a product, their costs still have to be covered. They can affect the price, the work left for the maker, or the attention given to the people already using it. Those tradeoffs deserve to be understood.

Information can become part of the cost as well. Measurement and promotion may involve learning more about a visitor than they expect. It matters which service receives that information and what the person has agreed to share.

Price is only one part of that experience. A person also gives a product their time and attention. If the steps are confusing or the information is difficult to find, they pay in effort even when the advertised price is small. Thinking about the whole cost helped me understand why clear writing and a dependable way in deserved real engineering attention.

I wanted to look at those choices from the customer’s side. If I was asking someone to trust Circle, I needed to be able to explain the relationship clearly, including the parts they would not see on the screen.

What would I want to know before I agreed?

A person arriving at a product page usually has a job in mind. They are not there to untangle the business arrangements behind every button. The page needs to make the important choices understandable.

What does the app do? What does it cost? Which device will it work on? What permissions does it need? Those are ordinary questions, and they deserve ordinary answers.

It is easy for a team to become familiar with a process and forget how it feels the first time. A term everyone inside the business understands may mean nothing to the visitor. An obvious next step may be obvious only because we built it. I wanted the work to be checked from the point of view of someone arriving without that knowledge.

A reassuring sentence about privacy cannot do all that work. Clear explanations and appropriate boundaries have to be part of how the service actually operates. That is a responsibility I wanted the direct relationship to make easier to see.

An easy button still needs an honest explanation.

Convenience is valuable when it helps someone do what they intended. It becomes harder to trust when the person cannot tell what happened, what they agreed to, or how to get back to their own work.

I want Circle’s pages and installation steps to explain the choices that matter in language people use. If a permission is needed, the reason should be understandable. If a device is unsupported, a sales page should not hide that.

Installation is a good example. The same words will not help every person on every device. Instructions have to match what the person can actually see and do. Keeping that explanation accurate is part of respecting their time. It is also part of keeping the original promise: that this app will help them, rather than give them another problem to solve.

These are ongoing responsibilities. They are also practical ways to make a distant online relationship feel more like dealing with someone who expects to answer for the experience.

Chapter 8: The idea spreads

Would I still recognize the idea at the other end?

An idea changes as more people work on it. A developer has to make it function. A designer has to make it understandable. A person helping to sell it has to explain why anyone should care. Those contributions can improve it.

They can also pull it in different directions. A promise that works in an advertisement may be broader than the product. A measurement can reward something that does not make the experience better. The maker needs a way to keep the original purpose visible.

It helped to distinguish the useful idea from the way we happened to be presenting it. A page, category, or campaign might need to change without changing the product’s purpose. If the explanation stopped sounding like the situation that caused me to build the app, I needed to notice. The person’s problem was a better point of reference than the presentation around it.

For me, that purpose was still the person trying to get something done. I wanted each decision to make their next step clearer, even when a more impressive-sounding idea was available.

I needed one question everyone could answer.

The more complicated the surrounding work became, the more useful a simple question was: what does this do for the person using the app? It could bring a conversation about features, copy, or installation back to the same place.

That question did not settle everything automatically. People could still disagree about the best answer. But it gave us something concrete to examine. We could look at the screen, the instructions, or the result and judge whether they helped.

Imagine two descriptions of the same feature. One sounds impressive but leaves a person unsure what they would do with it. The other explains the job in words they already use. Choosing the second can feel less grand from inside a business. From the customer’s side, it may be the first time the value becomes clear enough to act on.

It also gave me permission to leave some things out. An idea did not have to be bad to be unnecessary for the product in front of us. That was a relief after so much work had seemed to demand another addition.

Chapter 9: The old honesty, with modern reach

The customer came back into view.

I could keep the useful parts of modern software and build a more direct way to reach people. The page, purchase, installation, and return visit could all serve the same purpose.

The old doorstep had given me a question I could use in a new setting. At last, I could see where to put the work next.

Keep the distance small, even when people are far away.

A direct website can reach someone I will never meet. That does not mean the experience has to feel distant. A clear explanation, a working installation, and a useful result can show care in practical ways.

Circle uses modern software for that work. The apps still need secure access, dependable delivery, and ongoing improvement. What changes is the test each part has to pass: does it help someone understand, choose, use, or return to the app?

The return visit is an especially useful test of care. A person who already chose the app does not need to be sold the same promise again. They need to get back to what they came to do. Remembering that helps separate a welcoming product from a sales process that keeps introducing itself long after the introduction should be over.

That is what I wanted to bring forward from the old route. A person should be able to judge the product by what it does for them, and the maker should keep listening to the answer.

A different kind of conversation became possible.

Circle grew beyond the original real-estate app. A language gap, a difficult message, family photographs, or a sunset worth planning for could each become the starting point for a useful tool.

Those are different jobs. They deserve different explanations. But a person should recognize the same care in the way the apps are presented: a clear purpose, an honest offer, and help getting started.

I like that the needs are ordinary. Someone wants to answer a message without making the situation worse. Someone would like to speak to a person standing in front of them. Someone wants to find a photograph again. These are small occasions to be useful, and they can matter a great deal to the person having them. They give the work a human scale.

That gave the earlier experience a place to go. What I had learned about trust, access, and the way people return could help the next app begin on better terms.

The next product could begin with the lesson.

I did not want each new app to repeat the same confusion. The explanation, purchase, access, and installation needed to be considered alongside the app itself. They were all part of how a person would experience what we made.

That meant keeping the facts consistent. The page should describe the product people can actually use. The button should lead where it says. The instructions should suit the person’s device.

The lesson becomes real in small decisions. Choose a familiar word. Explain the price where someone can see it. Give a returning customer the right button. Check that the next screen follows the promise on the previous one. None of those choices makes a dramatic story by itself. Together, they can make a person feel that somebody thought about them.

There was plenty to build, but now the work had a shape I understood. It was helping a useful thing reach someone. After the long detour, that felt like progress I could believe in.

I want the product to earn the next visit.

A good introduction can make somebody curious. After that, the app has to help. If a person finds the words they needed or has a conversation they could not have before, they have their own reason to remember it.

I cannot promise that every product will succeed or that everyone will need what we make. I can work toward an honest match between the promise on the page and the experience after opening the app.

This approach also leaves room to learn from disappointment. If the app did not help, I need to understand why rather than improve the promise until it sounds more convincing. Sometimes the explanation is wrong; sometimes the product needs work. Keeping those possibilities visible makes an honest response possible, and gives the next change a better chance of helping.

That is a much more hopeful job than keeping an endless collection of sales tools busy. It puts improvement where a person can feel it.

There is someone on the other side of the screen.

That is where this story ends for me, and where the next part begins. I spent years building a product, then found myself learning how much could stand between that product and the people it was for.

Looking back at the old way helped me choose what to carry forward. Keep the reach. Keep the useful technology. Keep the promise close enough to the experience that a person can judge it for themselves.

The ending is hopeful because I have something concrete to do with what I learned. I can ask clearer questions, leave out work that does not help, and make the next person’s experience easier to understand. The years before this point still matter. They are part of why I can recognize the job I want Circle to do now.

Circle the People is how I am putting that lesson to work. The next person who opens one of our apps has a reason for being there. I want what we build to be worth their time.

A new way to keep an old promise.

Make something useful. Explain it honestly. Let someone try it and decide. Modern technology gives that simple relationship room to travel.

Circle the People is where I am putting the lesson to work. I kept the tools that help, and found my way back to the people I wanted to build for.

Come meet the apps at circlethepeople.com.