What should we actually build with AI?
AI & Automation
What to build, what to automate first, what stays human, and what ownership really means.
What is an AI build lab?
An AI build lab is a focused engagement that designs and builds one working system for your business. A client portal, a member platform, a buyer-facing application, or an automation connecting tools that do not currently talk to each other. AI is used hands-on to design, write and debug the build itself, which is what makes a two to three month timeline possible where the same scope previously meant two quarters, a development team and a six figure budget. Strategy, design and build sit inside one engagement rather than three.
Why it matters
The load-bearing word is one. The failure mode of internal software efforts is scope creep toward a platform that will eventually do everything and ships never.
Scoping to a single opportunity, with an explicit written list of what the system will deliberately not do, is what keeps a sprint inside its window.
What to look at
- One opportunity, scoped small enough to ship
- An explicit list of what it will not do
- Working versions in your hands early, not a reveal at the end
The VGL perspective
The interesting question is not what AI can build. It is what is now worth building that was not worth building two years ago. That list is longer than most companies have looked at.
What should a company automate first?
Start with the smallest system that proves value. One automation, one dashboard, or one workflow that should not still be manual. Integration work between systems that do not talk is usually the lowest-risk entry point, because the value is obvious and the blast radius is small. One working system reliably reveals the next one, and teams frequently discover the second build is worth more than the first. They only discover that by shipping the first.
Why it matters
Starting small is not a hedge against ambition. It is how you find out whether the thing everyone assumed was the bottleneck actually is.
The alternative, a transformation programme scoped over two quarters, tends to answer that question after the budget is committed rather than before.
What to look at
- Something running on spreadsheets today
- A clear owner who feels the pain weekly
- Two or three systems touched, not ten
Worked example: choosing between three candidates
A firm came to us with three ideas: a client portal, an AI assistant for proposal drafting, and an automation syncing project status from their delivery tool into client-facing reports.
The portal was the most exciting and the largest. The assistant was the most fashionable. The sync was the smallest, touched two systems, and removed about six hours a week of someone manually rebuilding a status spreadsheet.
We built the sync. It shipped in under three weeks and it worked. What it revealed was that the status data, once it was live and structured, was most of what the portal needed to exist. The portal then became a smaller build than it looked, and it was scoped from evidence rather than from a wish.
The proposal assistant never got built. Once the status data was live, the team found that the slow part of proposals was not the drafting, it was waiting on numbers that now arrived automatically. The most valuable outcome of the first build was learning that the second idea had solved itself and the third was never the constraint at all. That is the argument for starting small, and it is not an argument about reducing risk. It is an argument about finding out what is true.
The pattern has been consistent enough that we now write it into proposals. The first build is scoped to prove something, not to deliver everything, and the second one is deliberately left undefined until the first has shipped.
The VGL perspective
Every build we have started small has produced a second engagement. Every one that started large spent its first month arguing about scope. That pattern is consistent enough that we now scope it into the proposal.
What should stay human when you automate sales?
Automate sourcing, scoring, enrichment, sequencing and routing. Keep judgment human: how to answer a skeptical reply, when to break sequence, which opportunity deserves the founder's time, and when the right move is to walk away. A workable rule is that AI decides who and when, while people decide what to say the moment something unexpected happens. The exception is the moment that matters most.
Why it matters
The common failure is automating the reply. A generated response to a real objection reads as generated, and it costs you the account you just earned attention from.
The second failure is automating qualification judgment. A score can rank a list. It cannot tell you that the third-ranked account has a new VP who used to work with you.
What to look at
- Who and when: automate
- What to say when something unexpected happens: human
- Anything a named person will read closely: human
The VGL perspective
AI does not replace operators. It gives a capable operator the leverage of a much larger team, which is a completely different claim and a more useful one.
Do we own the code and infrastructure?
You own the system, the data and the infrastructure outright. There is no platform to keep renting from us and no per-seat fee after launch. That is the structural difference from adopting another subscription product. When the engagement ends the system keeps running and it belongs to you, including the source code, the hosting configuration, the database and every integration it depends on. Nothing is withheld and nothing is licensed back.
Why it matters
Ownership changes the economics over a three-year horizon. A subscription that half fits costs money every month indefinitely, and still leaves the workarounds in place.
It also changes the incentive on our side. We cannot retain a client through switching costs, so an engagement continues only when something has proven out.
What to look at
- Source, data and hosting transfer at launch
- No per-seat fee after handover
- The system runs without us
The VGL perspective
Every alternative except a build you own is a recurring cost. That sentence is the entire argument, and it is the one most software purchases never test.
How is an AI build different from hiring a development agency?
An agency builds what you specify, typically on a six-figure budget across two quarters, and usually retains the maintenance relationship afterwards. A build lab starts at the business opportunity rather than at a specification, scopes to one system small enough to ship inside weeks, and transfers ownership at launch. Strategy, design and build sit inside one engagement rather than being purchased separately from three parties.
Why it matters
The specification gap is where the money goes. An agency needs you to already know what to build, so the strategy work happens before the engagement, usually informally and usually incompletely.
Starting at the opportunity means the first session is about where value is leaking rather than requirements gathering for something already decided.
What to look at
- Who does the deciding, not just the building
- Whether strategy is inside the engagement or billed separately
- Where the maintenance relationship sits afterwards
The VGL perspective
Most companies do not need an AI department. They need someone who can decide what to build, and then build it. Those two capabilities are usually purchased from different people, which is why so little gets built.
Does a small company need custom software, or is SaaS enough?
SaaS is the right answer whenever your process is genuinely standard, and most processes are. Custom becomes right at the point where the workarounds have become the process, when everyone knows the platform half fits and the gaps are quietly absorbed by people. At that point you are already paying for custom software. You are paying for it in salary and attention rather than in a build, the bill recurs every month, and nobody has ever put it on a budget line.
Why it matters
A useful test: if you removed every spreadsheet, shared doc and recurring reminder your team maintains alongside the platform, would the platform still run the business?
If the answer is no, the platform is not the system. The people filling its gaps are the system, and they are the most expensive part of it.
What to look at
- Whether workarounds have become process
- How much headcount the gaps consume
- Whether the misfit is shrinking or growing
The VGL perspective
The wrong-fit subscription is the most under-examined line item in most companies. It renews because cancelling it would expose how much informal work sits around it.
Related insights
Long-form on this topic
Insight pieces expanding on these answers publish twice a month from October 2026. They will appear here as they go live.
First pieces publishing October 2026. In the meantime, the four concepts set out the thinking these answers are built on.
Start here
Find out where your own growth engine stands
The AI Growth Readiness check takes about three minutes. It scores you across six dimensions, places you on the growth maturity model, and gives a recommendation you can act on, including when the honest answer is not yet.
What you get back
- A score across growth dependency, unit economics and systems
- Your position on the growth maturity model
- A recommendation, or an honest not yet
- A concrete next step either way