5 Things Everyone Should Understand About Technology in 2026

As the Founder and CEO at Acquaint Softtech, I have spent thirteen years watching companies make technology decisions, and what separates the good outcomes from the painful ones is rarely technical skill. It is whether somebody in the room understood what they were actually agreeing to. A team can choose a perfectly sound framework and still end up trapped, because the trap was never in the framework. It was in the assumptions nobody examined. Most of what we do in software product development is build things. A surprising amount of it is helping people see the assumptions.

The version of this article was written in 2018 as a set of general observations. Reading it back, the observations were better than the examples. The ideas have held up unusually well for eight-year-old writing about technology. The facts underneath them have moved considerably, and one of them was not quite accurate even when it was published. So this rewrite keeps the five ideas, corrects what needs correcting, and adds what the original left out: what each principle should actually change about a decision you are making.

---

A word on why this is a business article rather than a philosophical one. Each of these five ideas has a direct consequence for a contract you might sign this quarter. Non-neutral technology means your build encodes decisions about people. Dependency means switching costs you never priced. Poor documentation means the knowledge walks out when the person does.

Shared authorship means your product rests on code maintained by strangers. Business models mean a vendor's incentives are not automatically yours. That is the throughline. These are not observations to admire. They are things to check before you commit money.

From Principle to Decision: What Each One Should Change

Each principle turns into one specific question worth asking before you commit. This table is the practical summary of everything below.

The principle	What it means in practice	The question to ask
Tech is not neutral	Defaults encode someone's values	Whose assumptions are in this?
Dependency forms fast	Switching costs grow quietly	What would leaving cost us?
History is badly kept	Undocumented systems decay	Who can explain this in two years?
No single author	You rely on unpaid maintainers	What are we actually depending on?
Business models shape products	Vendor incentives are not yours	How does this company earn?
All five together	Reversibility has a price	What are we locking in today?

The last row is the one worth writing on a whiteboard. Almost every expensive technology mistake I have watched was a reversibility problem rather than a quality problem. The chosen tool was fine. The cost of changing your mind about it was never calculated. Putting a number on that before signing is among the most useful hours a discovery workshop services session can spend.

Technology Is Never Neutral

Every piece of software contains decisions somebody made about how people should behave. The original made this point with a good example: software that demands a square image rather than a rectangle, and it deserves extending because the stakes have risen considerably since.

Defaults are decisions

A form with a required gender field and two options has made a claim about the world. A pricing page where the annual plan is preselected has made a claim about what you should want. A notification switched on by default has decided that your attention is available. None of these are technical necessities. They are choices, usually made in minutes, that then govern millions of interactions.

The version that now carries legal weight

When systems make decisions about people rather than merely presenting options, non-neutrality becomes consequential. A model trained on historical hiring data reproduces historical hiring preferences. A fraud or credit system trained on past outcomes inherits the patterns inside those outcomes. This is no longer only an ethical argument. The EU's regulatory framework for artificial intelligence classifies systems by risk level and places obligations on the higher-risk categories, including areas such as employment and access to essential services.

The practical implication is straightforward. If you deploy a model that affects people, you should be able to explain what it was trained on, how it was tested, and what happens when it is wrong. That is a documentation and governance question at least as much as a technical one, and it is the first thing we establish before building anything with AI development services attached to a real decision about a real person.

Dependency Forms Faster Than You Plan For

The original said there is no escape from technology, which is true but not especially useful. The sharper version is that dependency on a specific provider forms far faster than anyone intends, and gets priced only when you try to leave.

How it happens

Nobody decides to become dependent. You pick a cloud provider for hosting, which is portable. Then its managed database, which is less so. Then its queue, its authentication, its serverless functions, its machine learning service. Each step is individually sensible and marginally cheaper than the alternative. Two years later, your application is not running on a cloud. It is written in one.

The concentration is real

Three companies hold the substantial majority of global cloud infrastructure between them, with Amazon Web Services around thirty percent of the market, Microsoft Azure around a fifth, and Google Cloud roughly half of that again. That is not a criticism of any of them, since all three are genuinely excellent. It is a statement about how few meaningfully different options exist, and about what happens to your negotiating position over several renewal cycles.

What to do about it

Not avoid managed services, which would be slow and expensive. The realistic answer is to know where your lock-in sits and keep the parts that matter portable: your data, your identity system and your core business logic. Everything else can be provider-specific if it saves real time. Teams that hire DevOps engineers early tend to draw that line deliberately rather than discovering it during a renewal negotiation.

Technology's History Is Badly Recorded

The original made an unusually good point here: we remember which technologies won and almost nothing about why the others lost. The failures are where the useful information lives, and they are exactly the part nobody writes down.

The same thing happens inside your own company

Every codebase contains decisions whose reasoning has evaporated. A strange workaround exists because of a bug in a library version from four years ago. A table has two columns meaning almost the same thing because of a migration that was never finished. The person who knew has left. What remains is behaviour without explanation, and the next engineer either preserves it superstitiously or removes it and causes an outage.

The cheapest fix in software

Write down why, not what. The code already says what it does. What code cannot say is which three approaches were rejected and for what reason. A short decision record attached to each significant choice, a paragraph at most, is the highest-return documentation practice available, and almost nobody does it consistently.

This is also the difference between a system you can hand to anyone and one that ties you to whoever built it. When we take over an undocumented codebase, reconstructing intent is usually the largest single part of the estimate, which is why support and maintenance services on inherited systems begin with an archaeology phase before any code changes at all.

Nothing Significant Has a Single Author

The original noted that the iPhone was not built by one person, which is correct and slightly understated. The more useful version in 2026 is that your own software is mostly written by people you have never met and do not pay.

What your application is actually made of

A typical modern application is a small amount of code you wrote sitting on top of a very large amount of code you imported. Hundreds of open-source packages, many maintained by one or two volunteers in their spare time. When a maintainer stops, or an account is compromised, the consequence lands in your product. 

Recent supply-chain incidents across several ecosystems made this concrete rather than theoretical, and bodies exist precisely because the dependency graph became critical infrastructure without anyone deciding that it should.

Three habits that follow from this

Keep an inventory of what you depend on, so that when a vulnerability is announced you can answer whether it affects you in minutes rather than days. Prefer dependencies with more than one active maintainer. And check occasionally whether the small library doing something essential has had a commit in the past year, because an unmaintained dependency is a decision you have already made without noticing.

There is a corollary about how you credit work internally. Software gets built by teams, and organisations that attribute outcomes to individual heroes tend to lose the people who quietly held the system together. That is a retention problem wearing the costume of a culture preference.

Follow the Money, Because It Shapes the Product

How a company earns determines what its product optimises for, and the original got the broad shape right while stating one thing inaccurately. It said Google and Facebook make money by selling information about you to advertisers. They do not sell your data. They sell advertisers access to you and keep the data, which is a meaningful difference, because the data is the asset and parting with it would end the business.

Where the revenue actually comes from now

Advertising remains dominant for Alphabet and Meta. Google Search and YouTube together account for the large majority of Alphabet's revenue, as its investor disclosures set out each quarter, and effectively all of Meta's revenue is advertising. That part of the 2018 article was correct and stays correct.

What changed is where the profit growth comes from. Cloud computing became the engine. Amazon Web Services now runs at roughly a hundred and fifty billion dollars annualised and produces a share of Amazon's operating income far out of proportion to its share of revenue.

Google Cloud, unprofitable for years, now contributes billions in quarterly operating income. Apple's services business earns roughly twice the gross margin of its hardware. The pattern is consistent: the high-margin business is increasingly the one you rent rather than the one you buy.

Why any of this affects you

Because incentives shape defaults. A company earning from advertising builds products that maximise attention and data collection. A company earning from cloud consumption builds products that make adding another managed service easy and leaving hard.

A company earning from hardware and services wants you inside its ecosystem across every device you own. None of this is sinister; it is simply what a business does, but it explains why the convenient path inside a given product tends to lead in one particular direction.

One further shift is worth noting for anyone planning a budget. Current AI investment is enormous, with the largest firms committing capital at a scale that has visibly reduced their free cash flow. That spending has to be recouped, which is why AI features keep appearing inside products you already pay for and why pricing across the industry is in motion.

Anyone budgeting a multi-year software programme should assume the cost of the AI services underneath it will change in one direction or another, which is worth reading alongside our guide to web application development cost.

What This Means When You Commission Software

Turn all five principles into contract terms, and you prevent most of what usually goes wrong. These are the clauses worth insisting on, whoever builds your software.

Own the output completely

Full intellectual property ownership of everything produced, transferred to you, with no residual licence back to the supplier. This sounds obvious and frequently is not the case. Ask specifically about code written on your project that a supplier intends to reuse elsewhere, because that is where the ambiguity usually hides.

Make documentation a deliverable

Architecture notes, decision records, environment setup, and a runbook, delivered as part of the work rather than promised afterwards. Documentation written at the end is written from memory. Documentation written alongside is written from fact, and it is the thing that lets you change supplier without losing the system.

Ask for a dependency inventory

A list of every third-party library and service the system relies on, with its licence and maintenance status. This takes a competent team an afternoon and tells you precisely how exposed you are. If a supplier cannot produce one, that is itself the answer.

Price the exit before you need it

Agree in advance what handover looks like: what transfers, in what format, over how long, at what cost. A supplier confident in the relationship will not object. We put an NDA in place before work begins and clients hold complete ownership of what we produce, which makes this a short conversation, and our software case studies cover engagements that ran for years on exactly that basis.

Where you lack an internal technical voice to hold suppliers to these standards, an independent virtual CTO is considerably cheaper than discovering the gaps during a dispute, and considerably faster than recruiting for the role.

What Independence Costs

The work that keeps your options open is small and predictable next to the cost of losing them. These are prevailing market ranges rather than fixed quotes. 

Location	Senior engineering rate	Relative cost
New York, USA	USD 110 to 200 / hour	Highest
United States (national)	USD 90 to 170 / hour	Very high
Australia	AUD 110 to 200 / hour	High
United Kingdom	GBP 65 to 130 / hour	High
Europe (EU)	EUR 70 to 140 / hour	High
India (Acquaint Softtech)	USD 25 to 49 / hour	Up to 40% lower

Protective work	What it prevents	Estimated cost (USD)
Dependency and licence inventory	Unknown exposure during an incident	1,500 to 5,000
Architecture and decision records	Knowledge leaving with people	3,000 to 12,000
Lock-in and portability review	Unpriced switching costs	4,000 to 15,000
Handover and runbook package	Being unable to change supplier	5,000 to 20,000
AI governance documentation	Being unable to explain a decision	6,000 to 25,000

Every figure in that table is smaller than a single month of the disruption it prevents. That is the whole argument, and it is the same argument running through all five principles: the expensive part of technology is rarely the building. It is the not knowing, discovered late. Where the constraint is capacity rather than intent, adding this work through IT staff augmentation is usually faster than squeezing it into an already full roadmap.

Frequently Asked Questions