For years, the sensible advice to most technical leaders was straightforward: buy software unless you have a very good reason to build it yourself.
That advice still has merit. Commercial SaaS products are mature, accessible and often far cheaper than commissioning a full development team. They provide capabilities that would be difficult to recreate from scratch: security, infrastructure, mobile access, integrations, support, upgrades and a product roadmap.
But the economics of small, specialised software are changing quickly.
If you have IT or programming skills, the question is no longer simply whether you can build an application. It is whether a focused, personalised tool could remove friction from a part of your work that generic software handles badly.
AI-assisted development has lowered the barrier to exploring that question. It has not removed the need for judgement. It has made practical experimentation possible for far more people.
My view is that technical leaders should start taking this possibility seriously.
My instinct was always to build
Earlier in my career, I was inclined to build rather than buy. I wanted software that reflected the way I worked, the information I needed and the decisions I had to make.
Commercial products often came close, but “close” can become expensive. You end up changing your process to fit the tool, maintaining awkward spreadsheets outside it, or accepting that important context sits in someone’s head rather than in the system.
That instinct, shared with our team eventually contributed to the formation of ApplyIT, our first software venture. The purpose was to create products that did not exist in the market at the time, or to solve problems in a way that existing products could not.
There was a cost to that approach. Building software used to mean development teams, funding, long delivery cycles and considerable risk. Even a small application required skills and infrastructure that put it beyond the reach of many capable individuals.
The principle was sound. The practical barrier was high.
AI has changed the starting point
Modern AI toolsets have changed what a technically capable person can attempt.
A developer can now use AI to accelerate routine coding, generate a starting data model, explain unfamiliar libraries, draft user-interface components, write tests and help diagnose errors. Someone with more rudimentary programming skills can use the same tools to build a working prototype, provided they are willing to learn, check the output and work through the inevitable problems.
This does not mean AI will produce dependable software merely because you ask for it.
Software still needs clear requirements, appropriate security, useful data structures, testing and ongoing maintenance. An application that handles customer data, safety-critical processes, financial records or regulated information needs far more care than a personal productivity tool.
The important change is more modest and more useful: a working experiment is within reach.
A technical leader can now build a small application to test an idea before committing to an expensive commercial product, a major implementation programme or a long list of compromises.
Build where the work is genuinely distinctive
The decision to build should start with a hard question: what is genuinely different about this part of our work?
If the answer is “we need email, accounting, document storage or standard HR processes”, buying is usually the better choice. These are well-understood problems. The hidden cost of building includes support, security patches, user requests, hosting, backups and the burden of becoming responsible for a product that someone else already maintains well.
The case changes when the work depends on specialised knowledge, unusual combinations of information or a process that gives your organisation an advantage.
Consider a simple CRM. A commercial CRM platform may offer hundreds of features, yet still feel awkward for a small consultancy with a handful of high-value relationships. You may want to see each prospect alongside their technical interests, past conversations, relevant projects, industry context, next actions and the intellectual property that might be useful to them.
You may not need a giant platform. You may need a small, well-designed database that reflects how you actually develop relationships.
That is a reasonable first application to build. It is bounded, useful and unlikely to cause serious harm if you keep the scope under control.
Start with experiments, not grand programmes
The mistake would be to treat this new capability as permission to replace every commercial system in the business.
It is better to begin with a limited problem that irritates you often enough to justify attention. Build the smallest version that makes the work better. Use it yourself. Notice where it fails. Improve it or abandon it.
This is where technical leaders have an advantage. You understand systems, constraints and the difference between a prototype that proves a point and a production system that must be trusted every day.
A good early experiment might be:
- a personal CRM for customers and prospects;
- a database for lessons learned across projects;
- a tool to prepare recurring reports from structured information;
- a specialist calculator or decision-support tool;
- a lightweight workflow for tracking commitments, approvals or follow-up actions.
Choose something close to your own work. You will understand the edge cases, recognise poor results quickly and have a strong incentive to refine it.
Some experiments will fail. That is part of the learning. The value lies in developing the judgement to recognise which ideas deserve further investment and which should remain a useful lesson.
apLabs began as a learning exercise
apLabs is an example from my own work.
I began building it as a personal productivity toolkit and a way to explore what AI could do in real consultancy work. I wanted better ways to organise knowledge, separate client and project context, reduce repetitive effort and create more capacity for work that required experience and judgement.
The early goal was practical. I was trying to improve how I worked.
Over time, the platform developed into something far more capable than I expected. It now supports structured knowledge work across research, projects, marketing, documents, communications and specialised workflows. It is not a replacement for professional judgement, and it is still being tested and refined through real work. But it has shown me how quickly a focused experiment can become an important part of a working system.
That outcome did not come from a grand plan to build a broad platform. It came from repeatedly addressing real problems, learning from each attempt and extending what proved useful.
Build with judgement, not enthusiasm alone
The renewed case for building does not mean buying software has become obsolete. In many situations, a SaaS product remains the right decision.
Buy when the capability is standard, the operational risk is high, the product is well supported and your real need is adoption rather than differentiation. Build when the work is distinctive, the existing tools force damaging compromises, and you have a narrow problem that can be explored safely.
AI has made software creation more accessible. It has not made software ownership free.
Someone must remain accountable for data, security, maintenance and the consequences of failure. Start with internal tools, low-risk data and a clear boundary around what the first version must do. Keep commercial products where they serve you well. Create your own tools where they can give you a better fit, better insight or more productive ways of working.
The point is to expand your options.
Technical leaders who learn to build small, useful applications will be better placed to judge where AI-assisted development can create real value. Some will simply become more informed buyers of software. Others will discover an opportunity to create tools that change the quality of their work.
When is it better to build rather than buy specialised software in your own organisation?
If you are experimenting with AI, software development or practical productivity systems for technical work, why not connect with me on LinkedIn and share what you are working on. I’d love to hear your experience and compare with my own.
