This is the introduction to Reckoning with Reality, a seven-part collection of audits on profit, action, technology, and choice.
A few days ago, over dinner with a friend, we began talking about what to do next.
“The essence of entrepreneurship is making money,” he said. “If a business makes a lot of money, that means it creates value. If it keeps losing money, it is wasting everyone’s time and capital.”
The statement made me uncomfortable. Counterexamples came to mind at once. Casinos make money. So do businesses built on information asymmetry, and even deception. Some companies report profits only because employees, society, or the future bear costs that never appear on the income statement. How could profit simply be equated with value?
Yet I did not push the argument too far, because he had also put his finger on something true about me.
I like to talk about enduring value, product philosophy, and system design. Most of these ideas are sincere. But sincerity does not make them harmless. A distant enough vision postpones the question of whether anyone will pay today. A sufficiently elaborate system lets me explain the absence of users by saying that the infrastructure is not ready yet.
We talked for a long time. The subject moved from retail to AI, then to content and supply chains. My friend offered many definite answers, and I accepted only some of them. When I thought back on the conversation a few days later, the specific directions had already blurred. What remained vivid were the moments when I had instinctively resisted what he said.
The Statement That Made Me Uncomfortable
I have carried a certain technologist’s prejudice about value.
Building software, studying new technologies, and solving difficult problems sound like acts of creation. Selling clothes, cups, or household goods sounds like mere commerce—and rather unsophisticated commerce at that.
This is not a hierarchy of value. It is a hierarchy of taste.
A piece of clothing can make someone feel more attractive. A meal can give a person a brief moment of contentment. An inexpensive object can remove a small irritation from daily life. These things have value. A need does not become inferior because it is ordinary, and a product does not become noble because it uses AI.
If people continue to pay, then at least some real exchange is taking place. That fact is enough to puncture a great deal of self-congratulation. A builder can write pages about a vision. A stranger has only one decision to make: pay or do not pay.
But the scope of profit’s testimony is limited. It can test whether an exchange can continue. By itself, it cannot decide whether the exchange is honorable or whether its costs have been pushed onto outsiders. My friend treated profit as the final verdict. I would rather treat it as an indispensable auditor whose authority nonetheless has limits.
I did not accept the claim that making money is identical to creating value. The barb that stayed with me was aimed at a different form of self-deception: speaking endlessly about value while refusing to let value face the test of exchange.
Why I Always Want to Build the System First
Throughout dinner, my friend kept returning to the idea that one must enter the arena first. If you want to build tools for merchants, become a merchant. If you do not know how they spend their days, guessing at their needs from outside will usually produce the wrong answer.
I already knew this in theory. I had also paid for the lesson in my own projects.
Telepace had a long feedback cycle. I invested heavily in a complete system, while any real response from the market arrived much later. DayPage taught me almost the opposite lesson: begin with something I would use every day, let use expose the problems, and only then decide what deserves to remain. The two projects were hardly a controlled experiment, but together they illuminated both sides of the same temperament. I am good at making systems complete. I am not necessarily as good at exposing them early to outside judgment.
When I face an unfamiliar problem, my instinct is still to collect material, map the workflow, and begin constructing a system. Before demand has been tested, I am thinking about architecture. After performing a process manually once or twice, I am already imagining how it will scale.
None of this work is easy, which makes it difficult to call procrastination. I do write code every day. I solve problems. The task list gets shorter. Yet all the progress takes place in territory I know.
Code tells me where it failed. Users do not. A user may never respond, may say there is no need, or may not even care enough to explain the refusal. Building a system allows me to remain in a world with rules: a world I can control, where effort reliably produces feedback.
It took me time to see that infrastructure outrunning users is not always an error of engineering sequence. Sometimes I merely want to postpone the possibility that nobody needs what I am making.
This is what my friend’s injunction to “enter the arena” means for me. It does not guarantee that the direction is right. It only transfers part of the power of judgment to the outside world. In research, I can choose which sources to trust. The other party in a transaction has no duty to protect my conclusions.
Reckoning Is Not the Same as Stopping Thought
Still, I am wary of the advice to “think less and do more.”
Borrowing heavily to enter an unfamiliar business is action. Doubling down repeatedly in the wrong direction is action too. Producing more content because the view count looks good, while refusing to examine refunds or final settlement, can keep a person extremely busy.
Action does not automatically reveal the truth. It can be nothing more than self-justification made more exhausting and expensive.
I now test an action with a simple question: will its outcome change what I decide to do next?
If neither success nor failure would alter the plan, I am merely carrying out something I already believe. If every failure can be explained away as “not enough effort yet,” then reality is never allowed to contradict me.
This is also why short feedback cycles matter so much to me. I have spent months building products in isolation, launched them, and received very little response. It felt like dropping something heavy into a well, waiting a long time, and hearing only the faintest sound.
Fast feedback, however, can also deceive. Views and clicks arrive first; refunds, repeat purchases, and settlement come later. The earliest numbers are the best at encouraging us. The latest numbers are the closest to the outcome of the business. Entering the arena is not a matter of finding a new source of instant reward. It means making sure that fast signals eventually reconcile with the slower ledger.
None of this means engineering judgment should remain silent. Lost data cannot be reconstructed. Security boundaries cannot always be repaired. Migration costs rise over time. Those judgments should preserve options from the beginning. What should be deferred is production-grade automation and complexity prepaid for an imagined scale—not the engineering required to prevent irreversible loss.
I now prefer to give technology a narrow but important role: shortening the distance from action to judgment. Make the first delivery and record what happened. When the same friction appears repeatedly, make the process reliable. If output grows but judgment does not improve, technology is only producing noise faster.
Beyond Direction, There Is Another Account to Settle
By the end of dinner, several plausible paths lay on the table: enter a business myself, learn content and customer acquisition, provide services to existing merchants, or continue building the software I already understand.
I used to rush into comparing which path was larger, faster, or better suited to me. That question easily leads to industry reports, success stories, and an increasingly complicated scorecard. Every path comes with stories that support it and risks that seem to rule it out.
Now I want to look at something else first. Between acquiring a customer, delivering the result, and receiving payment, where is the missing link—and can I close it with my own hands?
When we travel only a small part of the route, we easily fall in love with the part we know best. Programmers see an opportunity for tools. Content creators believe traffic solves everything. People with supply-chain experience insist that the product is what matters. Only after completing the whole journey once do we discover what we underestimated—and whether we are willing to do it again.
The name of the industry can wait. Entering a field for a season does not have to become an identity. There is no contradiction in taking the work seriously, gathering feedback, and retaining the right to leave.
That dinner did not answer the question, “What should I do next?” It merely gave me a different way to ask it.
Every path charges a price. Long-term product work charges the price of slow feedback and the possibility that nobody will buy. Pursuing cash flow charges the price of repetitive operations, relationships, and minutiae. Keeping a stable job means accepting fragmented time. Betting everything can cost the right to try again after failure. Trying a little of everything also carries a fee: nothing is allowed to compound deeply enough.
These costs consume more than time and money. Over time, they reshape a person’s attention, character, and daily life.
So the question I most want to answer is not which path looks best.
It is this: what will this path ask me to keep paying? For what I still believe in, am I willing to pay that price?
Responses