Source: Image generated by chatGPT
The Code Got Cheaper. The Infrastructure Didn’t.
For years, I paid for software subscriptions because that was simply how things worked.
You needed invoicing, so you paid for accounting software. You needed ecommerce, so you looked at Shopify. You needed dashboards, so you paid for another SaaS tool. You needed a portfolio, a resume builder, a blog, or a CMS, so you signed up for another platform.
Each tool solved one problem, but over time the subscription stack grew into its own problem.
If I already have my own architecture, my own platform, and now AI to help me build and integrate features faster, why am I still paying enterprise-style prices for workflows I can recreate inside my own ecosystem?
That question is what led me to move away from QuickBooks for my own use case and integrate my sales workflow directly into Antsand.
This is not a post about QuickBooks being bad. It is not a post about every SaaS company dying. It is not even a post saying everyone should build everything themselves.
It is a post about a strategic shift I think is happening:
AI is reducing the scarcity value of generic software. Open-source tools are getting stronger. And if you have enough architectural understanding, you can now stitch together your own workflows in a way that was mentally exhausting or impractical only a few years ago.
The QuickBooks Example
I used QuickBooks for years. It did what I needed. But over time, I realized my actual needs were not that complicated.
For my use case, I needed to track sales, manage client records, support invoices or sales-related flows, and connect that information to the broader Antsand ecosystem. I did not need a massive enterprise accounting stack. I did not need to support millions of users. I did not need every possible accounting feature.
I needed the core workflow that mattered to me.
So instead of continuing to pay for a separate tool, I used AI to help me build a sales dashboard and sales module directly inside Antsand using my existing stack: PHP, Phalcon, HMVC, ES6, and the architecture I have been building for years.
That changed the equation.
The hard part was no longer typing every line of code. The hard part became knowing what I wanted, understanding my architecture, guiding the AI properly, reviewing the output, and integrating the result without breaking the existing system.
That is a very different kind of work. And for someone like me, that is powerful.
Why Antsand Matters
The key reason this works for me is that Antsand is not just a random collection of scripts.
It is a platform I have developed over the years. It uses PHP, Phalcon, HMVC, and a modular structure that allows me to add features methodically.
Antsand already powers my own web presence, including this blog. It also has modules for areas like resume building, ecommerce, sales, and content management. The goal is not to keep building isolated apps. The goal is to integrate capabilities into a broader ecosystem I control.
That matters because AI is much more useful when it has a strong architectural target.
If your system is a mess, AI can help you create more mess. But if your architecture is clear, AI becomes a force multiplier.
A standalone sales app is one thing. A sales module inside Antsand that connects to my clients, content, ecommerce, invoicing, and future AI workflows is much more useful to me.
A standalone ecommerce tool is one thing. An ecommerce module inside my own platform, hardened over time, is more aligned with how I want to work.
A standalone blog is one thing. Shiva’s Notes powered by my own platform gives me more control over publishing, monetization, courses, newsletters, and future experiments.
This is why I like HMVC. Almost every AI model understands the pattern well enough to help me extend it. It gives me structure. It gives me boundaries. It lets me keep expanding without turning every new feature into chaos.
I Do Not Need to Solve Billion-User Problems Yet
One of the biggest traps in software is overbuilding for scale you do not have.
People worry about whether their system can support a billion users before they even have consistent usage from a few hundred people.
Of course scale matters eventually. If one day I have a billion people hitting my server, that is a high-class problem. I would love to have that problem.
But I am not there today.
For my current use case — an individual, a small business, a handful of clients, my own blog, my own tools, my own ecommerce, my own sales workflows — I do not need to design everything like I am running Shopify or Salesforce.
A single well-configured server can handle a surprising amount of traffic before you notice meaningful performance problems. Most small businesses are nowhere near the scale where they need the complexity they are sold.
My priority is control, maintainability, cost discipline, and the ability to adapt quickly.
C Kernel Engine: Replacing Dependency with Understanding
Antsand is only one side of this story.
The other side is my C Kernel Engine.
In the same way Antsand is becoming my own business and publishing platform, my C Kernel Engine is becoming my own interpretation of what an AI runtime and mathematical kernel architecture should look like.
It is my attempt to replace parts of what I would otherwise depend on PyTorch, llama.cpp, or other large AI frameworks for — but in a way that is lightweight, inspectable, and aligned with how I think about computation.
I am not saying it replaces every feature of those systems today. That is not the point. The point is that I can now build and reason through my own AI kernels, memory layouts, inference paths, training flows, and mathematical operators instead of treating everything as a black box.
Once AI helps generate the scaffolding, the value moves back to architecture, validation, mathematical understanding, and systems thinking.
I can look at the code. I can reason about it. I can generate diagrams. I can write tests. I can compare outputs. I can validate numerical behavior. I can expand it module by module.
That is a very different relationship with software than simply consuming an abstraction as a service.
AI + Open Source as the New Integration Layer
The QuickBooks example is only one part of the story.
The same pattern is showing up in engineering, embedded systems, electronics, simulation, design, and content creation.
For years, I looked at tools like MATLAB, Autodesk Fusion, Altium, Cadence, Keysight tools, Adobe tools, and many others as the serious options.
And in many ways, they are serious. They are polished. They are powerful. They are used by professionals. They have support, documentation, ecosystems, integrations, and institutional trust.
But they are also expensive.
How much of what I need can I build by stitching together open-source tools with AI as my guide?
For scientific and engineering work, there is Octave, Python, Jupyter, OpenFOAM, OpenEMS, KiCad, FreeCAD, LTspice, Qucs, Blender, GTK, Qt, and custom C, C++, and Python tooling.
Historically, the problem was not that these tools were useless. The problem was that stitching them together was hard. Learning them was slow. Documentation could be fragmented. Workflows were not always smooth. Commercial software won partly because it reduced friction.
AI changes that.
AI can now act like a tutor, code generator, debugger, translator, glue-code assistant, and workflow designer. It can help me go from “I want to connect these tools” to a working prototype much faster than before.
That does not make everything easy. It does make many things possible.
MATLAB Coder, Flight Controllers, and the Evaporating Feature Moat
A lot of what I want to build involves quaternion math, state estimation, filtering, Kalman filters, PID control, flight dynamics, simulation, and embedded C code.
Historically, this is where expensive tools like MATLAB felt almost unavoidable. They gave you high-level functions, polished workflows, simulation environments, and code generation.
That is still valuable. But the relationship is changing.
If I understand the math, AI can now help me generate the code, diagrams, documentation, tests, and simulation scaffolding around that math. I can ask it to help build a quaternion attitude representation, derive pieces of the control loop, generate C code for a PID controller, sketch a Kalman filter structure, create validation tests, or produce diagrams that explain the state estimation pipeline.
The first version may not be perfect. That is fine. I can write test cases. I can compare against known results. I can validate edge cases. I can iterate until the code is correct enough for the use case.
A polished abstraction is nice. But if AI lets me recreate the abstraction, inspect the generated code, validate it, and then adapt it to my own embedded system, the value of paying for abstraction-as-a-service starts to fall.
That process deepens my understanding instead of hiding the details behind a high-level black-box function.
This Is Not for Everyone
I want to be clear: this path is not for everyone.
Most people should probably keep paying for the software that saves them time. If a business depends on payroll, tax compliance, financial reporting, medical records, payments, audit trails, or regulated workflows, replacing mature software with a homemade AI-built tool may be a terrible idea.
There are categories where the moat is not just the code:
- Payments and banking rails
- Tax, audit, and financial compliance
- Medical records and privacy-sensitive workflows
- Enterprise security and identity
- Regulated infrastructure and legal liability
I am not arguing that all software dies.
I am arguing that generic software with weak moats and high pricing should worry.
If the main value of a product is forms, dashboards, CRUD, reports, notifications, and basic integrations, then AI-assisted custom software and open-source alternatives are going to pressure that value over time.
Maybe not tomorrow. Maybe not immediately. But over three to six years, I think the pressure becomes real.
The Code Gets Cheaper, But the Infrastructure Still Matters
This is also why I am more interested in hardware, semiconductors, embedded systems, compute, sensors, robotics, and infrastructure than generic SaaS.
AI can make code cheaper.
But AI does not remove the need for chips, sensors, compute, power electronics, servers, networking, manufacturing, test equipment, and physical systems.
Someone still has to move electrons. Someone still has to design boards. Someone still has to build embedded systems. Someone still has to test hardware. Someone still has to make the infrastructure reliable.
That is why my strategic view is shifting. I am less excited about generic software companies and more interested in the physical and computational foundations underneath them.
What This Means for Antsand
For Antsand, this means I want to keep hardening the platform as my own operating system for business and creation.
Not operating system in the Linux kernel sense. I mean operating system as in the system I use to operate my work:
- Publishing Shiva’s Notes
- Building landing pages
- Managing ecommerce
- Creating sales workflows
- Supporting client projects
- Building resume and portfolio modules
- Experimenting with AI-assisted interfaces
- Integrating custom dashboards
- Reducing dependency on external SaaS tools
The more Antsand becomes my own ecosystem, the less I need to rely on separate subscription tools for every small workflow.
That does not mean I will eliminate every subscription tomorrow. I still use commercial tools. I still use Adobe today, for example. But over time, I want to reduce dependency.
If I can use Blender for 3D, Kdenlive or other open-source tools for video, Inkscape instead of Illustrator, KiCad for electronics, FreeCAD for CAD, Octave, Jupyter, and Python for scientific computing, and AI as my tutorial guide, then I can gradually build a powerful open workflow.
That is the direction I want to live and breathe.
Stitching Pain vs Subscription Pain
There is still a real question:
Is the pain of stitching open-source tools with AI worse than simply paying for polished commercial software?
For some people, the answer will be yes. Paying is easier.
For me, the answer is increasingly no.
I would rather own the workflow. I would rather understand the system. I would rather build on my own architecture. I would rather reduce recurring costs. I would rather learn the open tools.
I would rather use AI to accelerate the boring parts and preserve my mental energy for architecture, design, and integration.
That is the bet.
How This Shapes My View of Software Companies
This also affects how I think about investing.
I am cautious about generic SaaS companies because I believe AI compresses the value of software that is mostly workflow and UI. I may still trade software tactically if a signal-based process says the setup is good, but I do not want generic SaaS to be the core of my long-term worldview.
My bias is toward infrastructure:
- Semiconductors
- Analog and embedded systems
- AI compute
- Sensors
- Hardware
- Industrial electronics
- Aerospace and manufacturing
- Energy and physical infrastructure
Software can be generated faster. Physical systems still have to be built, powered, tested, shipped, cooled, repaired, and scaled.
A Teaser: Infrastructure May Be Next
This post is mostly about the software layer.
But I think the same pressure eventually moves downward into infrastructure.
That does not mean cloud providers, semiconductor companies, EDA vendors, or infrastructure platforms disappear tomorrow. Infrastructure is harder. Chips, fabs, packaging, networking, power, cooling, data centers, and manufacturing supply chains are much more difficult to challenge than generic SaaS workflows.
But a lot of infrastructure is still wrapped in software abstractions: runtimes, frameworks, orchestration systems, managed services, inference engines, training stacks, observability platforms, and deployment layers.
My C Kernel Engine is partly my own experiment in that direction. It is my way of asking whether a smaller, lighter, more inspectable AI runtime can replace pieces of my dependence on large frameworks and black-box infrastructure.
My suspicion is that software gets challenged first, infrastructure gets challenged next, and semiconductors get challenged on a much longer timeline — maybe ten to fifteen years — through AI-assisted design, open tooling, RISC-V, custom accelerators, and domain-specific systems.
That is a bigger thesis for another day.
Conclusion: Software Is Not Dead, But the Old Pricing Power Is Under Attack
I do not think software is dead.
I think software scarcity is changing.
The old world rewarded companies for packaging workflows into polished subscription products. The new world may reward people and companies that can combine AI, open-source tools, and strong architecture into custom systems that fit their own needs.
For large enterprises, regulated industries, and mission-critical workflows, commercial software will remain important.
But for individuals, small businesses, technical founders, creators, engineers, and builders, the equation is changing quickly.
If you know what you want, have a good architecture, and can guide AI effectively, you may not need to subscribe to every SaaS tool forever.
You can build. You can integrate. You can own more of your workflow.
That is what I am doing with Antsand.
And that is why my current thesis is simple:
The code got cheaper. The infrastructure didn’t.