Little App, Big Store
By Dan Brooking

I spent nearly three years building the app. Then I discovered what finishing really meant.

This is my account of building the original Circle app. The time and development costs are drawn from that experience.

The app was finished. I wasn’t.

What if you spend years making something useful, and people still cannot find it?

Nearly three years. Development costs approaching half a million dollars. That is what it took, by my account, to get the original Circle app ready. I had kept going through the corrections and the complicated details because I believed the problem was worth solving.

At last, I had something people could use. I thought the next part would be about them. Would it make their work easier? Would they want to come back? Those were the questions I was ready to answer.

Instead, I met a whole new set of demands. Before anyone could judge the app, I had to learn how to sell it, position it, promote it, measure it, and keep paying for the work around it. The finish line had moved. I had no idea how many times it could move again.

Let me take you back to the reason I started.

I wanted to solve a problem I recognized. In a real-estate transaction, a promise could be in a text, a document in an email, and a decision in somebody’s memory. When a question came up later, finding a reliable answer could be harder than doing the work in the first place.

Circle was meant to give that deal a place to keep its information together. The people, tasks, messages, documents, and acknowledgments would stay connected. Someone taking over a task could see what had happened before they arrived.

That was the idea I was trying to protect through everything that followed. This is the story of how a useful app became surrounded by a business I had not set out to build, and how I found my way back to the people it was meant to help.

Chapter 1: The crowded room

A deal should not depend on who remembers best.

Before there was an app, there was a familiar problem. A buyer, a seller, an agent, a lender, and an inspector could all be working on the same transaction while holding different pieces of its story. Each person needed the deal to move forward. Nobody could see everything.

An email might answer one question and leave three people unaware of the answer. A call might settle a detail that never reached the written record. Weeks later, a perfectly ordinary question could turn into a search through phones, inboxes, and recollections.

The people in that transaction were not short of ways to communicate. They could call, text, and email. What they lacked was a dependable way to connect those exchanges to the job they were all trying to finish. I wanted the answer to a question about the deal to stay with the deal, even after everybody had gone home.

I kept coming back to a simple thought: people should be able to find out what happened without having to win an argument about it. That was enough of a reason to begin.

I thought someone else was handling it.

That sentence explains a lot of what I wanted Circle to prevent. A task can look settled when everyone assumes it belongs to someone else. A document can be sent and still fail to reach the person who needs it. Good intentions do not leave much of a record.

I wanted tasks to have owners and dates. Messages could be acknowledged, so sending something and knowing it had been seen would not be treated as the same thing. Documents and notes would remain with the transaction.

Consider a deadline that depends on two people doing different things. Each can finish their own part and still leave a gap between them. A clear owner and a visible acknowledgment make that gap easier to notice. I wanted the app to help before a missing detail became a rushed call, a delayed decision, or a disagreement about responsibility.

None of that sounded especially glamorous. It mattered because people were making decisions about homes, money, and deadlines. An app that helped them keep the details straight could earn its place in their working day.

Chapter 2: One deal, one circle

One deal. One place to keep it together.

The circle was the transaction itself. The people involved could be brought into it with the roles and access they needed. The work belonged to that deal, instead of being scattered across whatever system each person happened to use.

That sounds straightforward until you try to build it. Who can see a particular document? What happens when someone leaves? What should a person see when a task changes hands? Every answer affects the next person who opens the app.

I pictured the person arriving in the middle of the work. They would not have heard the earlier calls or know which version of a document had been replaced. A useful app should help that person catch up. Designing for them meant thinking beyond the first screen and asking what the information would mean later, to someone who was not there.

The more carefully we worked through those questions, the clearer the purpose became. I wanted someone to open Circle and understand what needed attention, what had been done, and where to find the record.

The record needed to outlast the conversation.

A conversation ends. The consequences of it may not. A decision made on Tuesday can matter weeks later, when somebody else asks why a job was handled a certain way. A record is useful only if it is still there when that question arrives.

Circle brought notes, contacts, documents, and transcripts into the same transaction as the work they described. The aim was to keep a decision connected to its context, so a person could follow the story instead of guessing at it.

Keeping a record is also a way of reducing the burden on people’s memories. Someone should be able to take a break, hand over a task, or move to another transaction without becoming the only place an important answer exists. That was part of the care behind Circle. I wanted the information to remain useful without depending on one person always being available.

I could see the value of that. I could also see how much had to work underneath it. The screen might look simple, but the responsibility was not. We were asking people to trust the app with details they could not afford to lose.

A simple screen can hide difficult decisions.

The original app had to recognize the relationship between people and work. A task belonged to a transaction. A message concerned particular people. A record might need to remain available after someone’s role changed.

Making those relationships dependable required choices that a person using the app should rarely need to think about. The complexity did not vanish because we kept it off the screen. Someone still had to work through it.

A task list can be drawn quickly. A task list that behaves sensibly when people and circumstances change takes more thought. That distinction runs through a great deal of software. I was learning it in the details of Circle: the value of a feature was partly in what happened when the straightforward version of the situation stopped being the one in front of us.

That helped explain why the build took so long. We were trying to make complicated work feel manageable. Every shortcut had to be judged against the moment when somebody would depend on it.

Chapter 3: Three years to get it right

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.

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.

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 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.

Chapter 4: The app-store machine

Ready was supposed to mean ready.

I had spent so long trying to finish the app that finishing felt like the obvious turning point. Now, surely, we could find out whether people wanted it. A useful product ought to have a chance to speak for itself.

The store introduced a different set of questions. There were listings, screenshots, categories, privacy answers, payment requirements, and all the details needed to present the app. Then there was the much larger question of whether anyone would see it.

I did not object to explaining the product. I wanted to explain it. The surprise was how quickly that explanation could become one small part of a much larger undertaking. The app had needed to make sense to the people using it. Now I also had to learn what made sense to the systems responsible for deciding where it appeared.

The work had changed its name, but it had not ended. I had crossed one finish line and found another waiting behind it. This time, the app working well was only the starting condition.

A listing became a whole new job.

The product needed words and pictures that would help a stranger understand it. That was reasonable. But choosing a category, preparing screenshots, answering requirements, and maintaining the listing created a separate stream of work.

Then came the problem the listing could not solve by itself: being noticed. Finishing a page in a store does not mean the right person will ever stand in front of it. Discovery had its own demands.

The person looking at a listing has very little reason to be patient with it. They do not know the years behind the icon, and they should not have to. They need a clear reason to care about what the app can do. Learning to respect that brief encounter was useful. Confusing it with the entire business of discovery was not.

I had built a tool to help people keep work together. Now the work of presenting that tool was spreading into more places. The resemblance was hard to miss.

I was ready for the useful part to begin.

After so much preparation, I wanted the important test to happen: someone using the app and finding out whether it helped. That was the reason for all the decisions that came before it.

Yet every added step could delay that meeting. It became possible to spend more time improving the route to a hypothetical customer than learning from a person with the app in front of them.

The first useful feedback could be very ordinary. A person might not understand a label. They might look for a document somewhere unexpected. They might tell us which detail saved them time. Those were things I wanted to learn from actual use. No amount of preparation around selling the app could replace the understanding that comes from seeing where it helps and where it gets in the way.

That is a lonely place for a useful idea to sit. The work is real, the cost is real, and the chance to help still feels farther down the road. I needed to shorten that road.

Chapter 5: The second industry

Then everyone had something to sell me.

Advertising, search, branding, analytics, advice. There was help available for every new problem around the app.

Each offer could sound sensible on its own. Together, they made the road ahead look longer than the one I thought I had finished.

A place in the store was not an audience.

A store can make life easier for customers. Familiar payment, reviews, and a known place to look all have value. I could understand why people used that route. I also had to understand what it meant for a small product trying to be seen.

The store set the conditions for entry and presentation. The attention inside it was something else entirely. I could do the required work and still face the question of how a person would find Circle among everything around it.

I had to separate respect for what a store provides from the assumption that it was the only possible home for the relationship. Familiarity has value. So does being able to explain the product in the way that suits it. The right choice would have to account for the customer’s confidence as well as the work and cost of keeping the product available.

Being ready to sell and having a way to reach people were two different accomplishments. I had paid dearly for the first one. Now I had to work out the second.

Every answer seemed to need another service.

One service could help with visibility. Another could explain what visitors did. Another could follow up with them. Each one brought its own account, settings, cost, and promise of making the rest work better.

I did not believe every person offering help was wrong. That made the decisions harder. Useful advice could still lead to more work than we could sensibly carry. A collection of good ideas could become an unmanageable business.

A recommendation often arrives in isolation: improve this page, connect that service, follow up in a new way. The maker has to carry the consequences together. I was the person who needed to understand the whole collection, including what would happen if a subscription changed, a connection failed, or an added task required attention that the product itself also needed.

The question I needed to answer was getting buried: which of these things actually helped someone reach the app? Without that answer, it was easy to keep paying for motion and mistake it for progress.

Being noticed had its own price.

A product can be priced reasonably and still be expensive to bring to someone’s attention. Promotion and discovery introduce costs that have little to do with the next person actually using the app.

Those costs vary. A service that makes sense at one scale may make much less sense at another. I needed to understand the assumptions behind the numbers instead of treating every recommended expense as unavoidable.

I could not judge a cost only by whether other businesses paid it. I needed to know what Circle could sustain and what the customer would receive in return. A tool that saved time might be worthwhile. A recurring expense with no clear connection to the person’s experience needed a harder look. The point was to choose deliberately, rather than inherit a shopping list.

The more I looked at the route as a whole, the more important a direct relationship became. Someone who understood the app and knew where to return would not need to be introduced to it from the beginning every time.

Chapter 6: The path gets crowded

The way out kept getting farther away.

The list of things to manage grew while the original promise stayed the same. Somewhere beyond the listing, the promotion, the measurements, and the next improvement was a person who might find Circle useful.

That distance became the hardest part of the work. If reaching someone required another service, and keeping that service useful required another process, where did the preparation end? When did the product get its turn?

There was no dramatic announcement that the work had become too complicated. It could happen through reasonable choices, made one at a time. That was what made it difficult to recognize. Each addition had an explanation, while the combined burden was harder to name. Looking at the whole journey was the only way I could see what those choices were adding up to.

I had already put years and a great deal of money into making the app ready. The prospect of an endlessly expanding job around it made the road ahead difficult to recognize. I could keep adding pieces without knowing whether I was getting closer.

I was working on the work around the work.

A setting needed attention. A report needed interpreting. Something changed and another part had to be checked. The tools meant to help could demand time of their own, and that time had to come from somewhere.

The danger was bigger than a single bill. It was losing the attention that made the product worth building. If the whole day went into maintaining the way we sold the app, how much was left to make the app better?

Attention is part of what a maker puts into a product. It is how you notice that an instruction sounds wrong or that a person needs an easier next step. When that attention is consumed elsewhere, something valuable is lost even if every task on the calendar appears productive. I did not want the app to survive while the care behind it slowly ran out.

This was the point where simply doing more stopped looking like an answer. I needed a different way to decide what belonged. Otherwise the original purpose could disappear under perfectly ordinary tasks.

How much could one little app carry?

Every recurring cost had to be paid somehow. That burden could reach the price, the time available for development, or the money left to keep the product running. It did not disappear because it belonged to marketing instead of code.

I had started with a practical need. I did not want the answer to become too expensive or too complicated for the people who had that need. Watching the surrounding work grow made that possibility hard to ignore.

There was a human cost to losing sight of affordability, too. The person who needed help with a practical problem might have little interest in paying for everything that had grown around the answer. I wanted the price to make sense beside the job. That meant taking the surrounding costs seriously before assuming the customer would be willing to carry them.

This was the question that pushed me toward change: could I keep the useful product and build a shorter, more understandable way to bring it to people? I needed an answer I could act on.

Chapter 7: The mall and its rules

I could improve the app. I could not set every rule.

Working inside somebody else’s marketplace meant accepting decisions I did not control. The rules of entry, the ways products were displayed, and the costs of doing business were part of that choice.

It would be easy to turn that into a story with a villain. That would miss the more useful lesson. A route can work for a customer and still be difficult for a particular maker. I had to judge whether it was the right route for Circle.

The useful question was practical, rather than angry. Which responsibilities would we take on ourselves, and which services would still help us do them well? A direct relationship would not remove every dependency. It could give us a clearer reason for choosing the ones we kept. That was enough to make another way of working worth examining seriously.

Once I allowed myself to ask that, a different possibility appeared. Perhaps I did not have to solve every difficulty inside the same arrangement. Perhaps I could build a simpler way to reach people.

The promises had to match what we did.

Explaining privacy made me think about the whole journey, including the services surrounding the app. A short statement on a page could not take the place of understanding where information went and why it was needed.

I wanted Circle to be clear about permissions, access, and the records needed to run a service. That takes more care than making a comforting promise. People deserve information they can use to decide what to share.

People rarely see the full set of decisions behind a simple permission request. The maker has to do that work before asking. I wanted an explanation that matched the reason for the access, and a product that respected the limits it described. This was another place where a smaller, clearer purpose could help us make better choices instead of broader promises.

The same principle applied to the business around the product. If I could not clearly explain why a part was there, it deserved another look.

Chapter 8: Walk through the front door

There could be a front door of our own.

Eventually, I began to question an assumption I had carried through all of this: that the only sensible way to reach people was to keep adding what the existing route demanded. What would a direct route look like?

A person could come to a page, understand the app, see the price, and decide. Circle could handle the purchase and verified access, then guide them to the right installation for their device. The next time, the icon would take them back.

A direct route also meant accepting responsibility for the parts a store might otherwise handle. The page could not merely say something friendly and leave the difficult questions unanswered. We needed a reliable way to verify access, explain the installation, and help a returning customer. The difference was that those responsibilities were close to the relationship I actually wanted.

That still required real engineering and care. But the work now had a clear destination. Each step existed to help someone reach the app, and I could ask whether it actually did.

Every step had to earn its place.

I stopped treating a long list of services as proof that we were doing the right things. A service could be useful and still be wrong for this particular job. I needed to know what it did for the person trying to reach us.

The direct route gave me a way to judge that. Could someone understand the offer? Could they pay securely? Would access reach the right person? Could they install on a supported device and return without starting over?

There was something encouraging about a question with an observable answer. We could follow the same steps a person would follow and see where they became confused. We could find a misleading instruction and change it. We could check whether a returning customer arrived where they expected. That was more useful than assuming that another service would eventually make the experience clearer.

Those questions made the remaining work easier to recognize. There would still be costs and problems. At least I could see whom we were solving them for.

Chapter 9: The question underneath

I could see a way forward again.

The breakthrough was a change in what I was trying to build around the app. A clear explanation, a secure purchase, and a dependable way back were things I could work toward.

For the first time in this part of the story, the next step led toward the person I had wanted to help all along.

Back to the person opening the app.

Circle the People grew from that choice. I wanted each app to begin with a situation somebody already understood: a conversation they could not have, a message they could not quite write, a memory they wanted to keep.

That changed the way the products needed to be explained. A person should be able to tell what an app does before learning anything about the systems behind it. They should be able to see the price and whether it works on their device.

I also wanted room for a person to decide an app was not for them. A clear description can save someone time even when it does not produce a sale. That is part of building a relationship worth returning to. If the first encounter respects their judgment, they may trust what they read when a different app does fit their life.

This was work I could believe in again. The engineering supported an ordinary human decision: would this help me? That question was finally back where it belonged.

Getting there is part of the experience.

A good app can still lose someone on the way in. An unclear button, an email that arrives without an explanation, or installation instructions that seem written for somebody else can turn interest into frustration.

We have to take those moments seriously. New customers need a clear way to begin. Returning customers need a way back. Someone who changes devices needs help restoring access, not another explanation of why the app is wonderful.

Imagine buying an app and then wondering whether the purchase worked because the next page does not explain what to do. The problem is not the customer’s intelligence or patience. Something important has been left unclear. I wanted us to notice those gaps from their side of the screen, rather than assuming that completing the payment meant our work was done.

These details are less dramatic than a launch, but they are where trust is tested. A welcome only counts if the person can get through the door.

I wanted the next app to start differently.

A lesson only helps if it changes what you do next. For Circle, that meant looking at the whole customer experience early: the explanation, the price, the supported device, the installation, and the return visit.

Each part needed an owner and a reason to exist. The people building the app and the people presenting it had to be describing the same product. A beautiful promise was no help if the next screen contradicted it.

The change needed to last beyond one page or one launch. It had to show up when somebody wrote an explanation, added a feature, or changed an installation step. I wanted those decisions to keep returning to the same person and the same promise. That consistency would make the experience easier to trust and the work easier to judge.

That gave the earlier work a future. I could use what it had taught me to make the next useful idea easier to understand and reach. The struggle had become something I could build with.

Would this actually help someone?

That is the question I started with, and it survived the whole journey. The original app had a real job. Years of work went into making it dependable. The trouble began when the business of reaching people threatened to take over the reason for reaching them.

I cannot make every useful idea succeed, and Circle has plenty of work ahead. What I can do is keep the purpose visible. We can explain an app honestly, make it accessible through a clear route, and learn from what happens when people use it.

I now think about the first question and the last screen together. If the app begins by promising help with a particular problem, everything that follows should support that promise. The explanations, permissions, installation, and return visit all belong to the same experience. Keeping them connected is one way to keep the original purpose from disappearing as the product grows.

That gives me a reason to keep building. The next useful thing can start with a person again.

The story gets to keep going.

The ending I wanted was never a larger collection of dashboards. It was somebody finding the app, understanding it, and getting the help they came for. That is the ending Circle gives me a chance to work toward.

The years spent on the original app were not erased by changing direction. They taught me what it takes to keep information together, protect access, and think about the person who comes next. Those lessons belong in the apps we build now.

I can look at the original work without pretending every part went the way I hoped. Some lessons were expensive. Some took too long to recognize. They still gave me something I can use: a better understanding of what deserves attention, what needs to be dependable, and how much simpler a decision becomes when the person using the product is visible again.

So I am still here, making things. There are conversations to have, words to find, photographs to save, and evenings worth stepping outside for. The difficult part of this story brought me back to work that matters to me.

The door is open.

I began with one problem and spent years learning how much could stand around the answer. Today, those lessons are helping me build Circle the People.

There are useful things here to try, and more work ahead. I can see the person I am building for again. That is a hopeful place to begin the next chapter.

Come have a look at circlethepeople.com.