When an investor evaluates a company they do not ask how much it spent. They ask what is left. That distinction, elementary in any investment committee, is almost never applied to a company's own technology budget, where subscriptions get approved year after year and leave nothing behind. Here is the uncomfortable part: if you own your business, you are your company's first investor, and you are judging your own portfolio by a looser standard than you would accept from anyone else.
The short answer: apply to your technology budget the same filters an investor applies to your company. What is common to your industry, rent it. What encodes your particular way of operating, build it, because that is where spending turns into an asset that keeps producing once you stop paying.
What are investors demanding today?
Clarity on technology and discipline with capital, in the same breath.
The demand stopped being about whether you invest in technology and became about whether you can explain what it produces. FIG-1 ranks what weighs in an evaluation now.
Data
| What investors demand | Share of investors |
|---|---|
| Rate clarity on AI and technology as highly important | 77% |
| Put geopolitics among their top three concerns | 69% |
| Prioritize return-on-invested-capital discipline | 63% |
| Demand a clear capital allocation framework | 54% |
| Prefer organic reinvestment as the primary use of capital | 52% |
Notice the combination: 77% rate clarity on AI and technology strategy as highly important and only 3% assign it low importance, while 63% prioritize return-on-invested-capital discipline [1]. These are not two separate demands. They are one: invest in technology, and show me what it produces.
Why is the business owner the first investor?
Because the capital you allocate every month is already a portfolio decision, even if you do not call it that.
An outside investor evaluates your company through three filters: whether it withstands adverse scenarios, whether technology is tied to real economics, and whether you allocate capital with discipline. When you choose between another subscription and building something of your own, you are running exactly that exercise on your own balance sheet. The difference is that almost nobody formalizes it.
And the result shows up somewhere concrete. After five years of subscriptions, the company that only rented has the same capability it had on day one and zero technology equity. The one that built what differentiates it has an asset it can improve, sell, license, or put in front of a due diligence team.
Is "software as an asset" a metaphor or something literal?
It is literal, and it is written into the accounting standard.
Under ASC 350-40, the cost of developing internal-use software can be capitalized as an intangible asset once the preliminary stage is complete and the project is authorized and funded, and it is then amortized over its estimated useful life [2]. A SaaS subscription, by contrast, is normally recorded as an expense of the period. The same money, treated differently, with different effects on your balance sheet.
Table 1. The same outlay, two treatments.
| Dimension | Rented software (SaaS) | Software you build |
|---|---|---|
| Typical accounting treatment | Expense of the period | Capitalizable intangible asset, amortized |
| What remains when payment stops | Nothing | The asset and its code |
| Balance sheet effect | None | Increases intangible assets |
| Control over the roadmap | The vendor's | Yours |
| Main risk | Lock-in and price changes | Maintenance cost |
| Competitive advantage | The same as your competitor's | Whatever you encode |
One calendar note for your accountant: update ASU 2025-06 revises the criteria for when capitalization begins, effective for fiscal years beginning after December 15, 2027 [3]. Worth reviewing before planning the accounting treatment of a large build.
What do three expert positions say about investing in software?
There is no consensus here, and the disagreement is exactly what is useful.
Position 1. Technology stopped conferring advantage (Nicholas Carr). In an article that remains uncomfortable, Carr argued that information technology follows the pattern of other infrastructural technologies, such as railroads or electric power: it opens advantage while it is scarce, and stops conferring any once it becomes ubiquitous and cheap. His central thesis is that scarcity, not ubiquity, is what makes a resource strategic, and his recommendation was that managing technology should become boring and focus on reducing risk rather than chasing opportunity [4].
Position 2. Software is eating the world (Marc Andreessen). The opposite position, formulated eight years later, holds that software is absorbing entire industries and that every company ends up being, to some degree, a software company [5]. Under that reading, not building your own software capability means handing the center of your business to whoever does build it.
Position 3. Both are right, but about different layers (Neo Bernal, co-founder of MasterDragon.AI).
There is a scene that repeats in operations that look nothing alike. A committee approves its third subscription of the year. Ask what they bought and they describe a tool. Ask which process improved and there is silence. I offer an opinion here not because I have studied anyone's financial statements, but because that conversation plays out the same way in companies of very different sizes and sectors.
The question a committee usually asks is "why did we buy this?", and that question only produces justifications. The question that moves something is "what did we buy it for, and is that still true today?". The first looks backward and defends a decision. The second looks at purpose and lets you change it.
Through that lens, the disagreement between Carr and Andreessen dissolves, because each is describing a different layer:
- The common layer. Email, accounting, payroll, standard invoicing. Carr is entirely right here: advantage is impossible because everyone buys the same thing, and building is waste.
- The difference layer. How you quote, how you prioritize, how you decide a credit, how you assign a route. Andreessen is entirely right here: buying standard means buying your industry's average.
That said, I do not want to sell you this as a formula. Separating the layers does not tell you how much to invest and does not protect you from building badly, and I have seen in-house builds fail for lack of an owner rather than lack of code. The only thing it solves is the most expensive mistake, which is not choosing wrong between build and rent: it is not knowing which layer you are standing on when you choose. It is an obvious, common-sense distinction; it is not, however, common practice.
How do you decide what to build and what to rent?
With one question, and then with a table.
The question: if your competitor bought exactly the same software you did, would they get the same result? If yes, you are looking at a market capability and renting it is correct. If no, you are looking at an asset and it should be yours.
Table 2. Where each piece lands.
| Type of capability | Examples | Decision |
|---|---|---|
| Common to every industry | Email, accounting, storage, video calls | Always rent |
| Common to your sector | Base ERP, standard CRM, payment gateway | Rent and configure |
| Specific to your operation | Quoting rules, routing, your own scoring, flows with your exceptions | Build |
| Your actual difference | The process a customer chooses you for | Build and protect |
Most budgets fail by overspending on the first two rows and underspending on the last two. They build what could have been bought, and buy what defined the business.
How do you measure the return on software you own?
By the process it touches, not by the project that delivered it.
A build is not measured in features shipped. It is measured in the process that changed: cost per transaction before and after, team hours freed, error rate, cycle time, and revenue attributable to that process. That is exactly the language an investor asks for when demanding technology be tied to economics [1], and it is the same dashboard you should demand of your own budget.
The practical test is uncomfortable and healthy: if you cannot name the process that will improve and the number it will move, you do not yet have an investment case. You have an idea.
Build what differentiates you
The operating conclusion is short: rent the infrastructure, build the difference.
We do that second part. We design and build custom software for the process that carries your business, with the discipline we described in engineered agency: measurable objectives, delivery in verifiable stages, and KPIs from day one, so what stays on your balance sheet is an asset that returns rather than a project that gets explained.
If you want to see what that looks like on a concrete timeline, start with how we build your software, and review our portfolio of shipped AI-native products. Talk to our AI engineers and put numbers on the decision before you sign the next subscription.
References
- McKinsey & Company. (2026). What matters most to investors in 2026 and what it means for companies. https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/what-matters-most-to-investors-in-2026-and-what-it-means-for-companies
- Deloitte. (2025). Software development cost accounting for SaaS, cloud, and on-premise solutions. https://www.deloitte.com/us/en/services/audit-assurance/blogs/accounting-finance/software-accounting.html
- Forvis Mazars. (2025, December 1). FASB's improvements to accounting for internal-use software (ASU 2025-06). https://www.forvismazars.us/forsights/2025/12/fasb-s-improvements-to-accounting-for-internal-use-software
- Carr, N. G. (2003, May). IT doesn't matter. Harvard Business Review. https://hbr.org/2003/05/it-doesnt-matter
- Andreessen, M. (2011, August 20). Why software is eating the world. The Wall Street Journal. https://www.wsj.com/articles/SB10001424053111903480904576512250915629460