Software Engineers Know How to Build. Few Know How a Business Runs

By Nasly Duarte

The best technical people I meet can build almost anything. The gap is never the code.

The code was never the hard part. The business was.

Paul Graham wrote a line that should sit on every engineer's desk. Enterprise software companies are not technology companies. They are sales companies, and sales depends mostly on effort.

Read that again if you build for a living. The thing that wins is not the cleanest architecture. It is understanding the business the software serves.

Most builders never get that understanding. They receive a requirements document. They build against a description of the work, not the work itself. The gap between the two is where good software quietly fails.

The skill most software engineers are missing

Technical skill has a ceiling. The ceiling is business understanding.

You can write the system. The harder question is whether you know how the business actually runs. Where the money moves. Where the work breaks down. What the owner fears at two in the morning.

That knowledge does not come from a stack. It comes from being inside an operation and watching it work.

Cross-training is the highest-leverage move

The most valuable builder in business in the coming years is not the one with the deepest technical stack. It is the one who understands how a real business runs and can build for it.

That person does not discover the pain through customer interviews. They have lived it. They build the fix that removes the cause, because they watched the cause happen.

Cross-training on business operations is the highest-leverage skill a technical person can add right now. It is the skill that moves you out of the sales-company category Graham described. It puts you in the category of someone who builds what a business actually needs.

This is the work I do at Mindful Dollar. I help business owners design their own financial architecture through autonomous agents that work alongside their employees, not instead of them, to increase profit and productivity.

The Bottom Line

Building skill alone is not enough. The builders who win understand the business first.

I wrote the full thesis for my community. It covers how I treat a small business as a research environment, why full visibility beats documentation, and how an operator builds in a sprint what a corporation gates over years. I call it The Operator's Lab.

Read the full piece on Buy Me a Coffee.

buymeacoffee.com/girlgoneverde/buildingbusinesstoolsasanengineer

Then go find the room where you can see the whole machine.

Mindful Dollar | Nasly Duarte | Doing More With Less | mindfuldollar.blogspot.com

The Skill Nobody Teaches: Learning to Read Code

By Nasly Duarte

Readers of this blog know I am building an AI product in real time.

That product — Soulaccess, a phone-based access tech to enter churches during un — requires me to read, understand, and extend code I did not write. It requires me to direct AI coding agents and evaluate what they produce. And it requires me to teach these skills to a community of people who want to build alongside me.

Which is why this series exists.

Most churches sit empty 90 percent of the week. Meanwhile, the people who fund those churches experience grief, anxiety, and crisis at the hours when those buildings are locked. That's broken. !I'm building a Phone-based access app to sacred space, anytime soulaccessprototype.netlify.app

The Overlooked Skill

Developers spend ten times more time reading code than writing it. That is not a statistic from a research paper. It is the lived reality of every developer working on a team, fixing a bug, reviewing a pull request, or building on an existing codebase.

School teaches writing. The real world demands reading.

The mismatch is significant. By the time you are hired into a technical role, you walk into a codebase you have never seen and are expected to produce output by Friday. The ability to orient yourself inside someone else's system — to find the entry point, trace the flow, understand the structure — separates productive builders from people who ask questions for two weeks before touching anything.

This matters more now, not less, because of AI coding tools. When you prompt an agent to build something, it produces code. That code might be correct. It might have subtle errors. It might follow patterns that conflict with the rest of your project. The only way to evaluate what an agent gives you is to be able to read it.

Reading code in the AI era is not about memorizing syntax. It is about the ability to open a project and understand its structure, trace one feature through an entire system, identify patterns that repeat, and notice what is well-designed versus what is a red flag.

The Six Situations

Reading code happens in six recurring situations, each with a different objective.

The first-day read happens at a new job or when you inherit a project. You are not looking for details yet. You are asking: how is this structured and where do I start?

The bug read happens when you are assigned to fix code someone else wrote. You are asking: what was this supposed to do and where did it break?

The review read happens during a pull request or code review. You are asking: does this work, is it clean, and will it cause problems later?

The learning read happens when you open a well-built project to study it. You are asking: how did they solve this and can I use this pattern?

The library read happens when you want to understand a tool you are already using. You are asking: how does this actually work under the hood?

The inheritance read happens when someone leaves and their code stays. You are asking: what is this doing and why did they do it this way?

Each situation asks a different question but uses the same foundational skill. The ability to read unfamiliar code confidently and orient yourself inside a system you did not build.

The Build-in-Public Context

I am teaching this skill because I am living it.

The Itemizing build — which I am documenting publicly for my community — requires me to read repositories I have never opened, understand patterns I have never implemented, and adapt them for a product I am building as I go. The agent workshop at Agentcamp gave me working code to read. Open-source libraries I am evaluating require me to assess quality before I commit to them. AI agents produce code that I need to understand before I push it to production.

Every principle in this series is one I applied this week, on a real product, in a real codebase.

The Framework: The Bird's Eye View

The next post in this series introduces The Bird's Eye View — a three-step methodology for opening any codebase without panic. It is the first pass developers use before reading a single line of logic code. The file structure. The entry point. The config files that reveal a project's DNA in thirty seconds.

This is the methodology I applied when I opened the Itemizing repository for the first time. It is the methodology I am teaching in the summer curriculum. And it is the methodology that turns a 50,000-line codebase from overwhelming to navigable.

The Bottom Line

Reading code is not a secondary skill. It is the primary skill of anyone building products, reviewing AI output, or working on any codebase that existed before they arrived. The faster you develop it, the faster every other technical skill follows.

Building this in public, one codebase at a time.

Follow the full summer curriculum — including weekly code reading challenges, a live build log, and community events — at the Mindful Dollar BMAC community. The curriculum is live now and designed for people who want to build, not just read about building.

Join the Mindful Dollar BMAC Community →

Mindful Dollar | Nasly Duarte | Doing More With Less

Mindful Dollar

Friday, June 5, 2026