Building with AI — Part 1: Before We Build

Experiment quickly. Govern deliberately. Build things that function.

It started with a simple idea

A few weeks ago, I opened Microsoft Copilot and started a conversation about an operational problem.

A fabrication workshop needed a better way to manage its jobs, plan its workforce capacity and understand the relationship between the work it had committed to, the people available to perform it and the revenue it expected to generate.

My initial thought was that we could probably solve much of this with Excel.

In fact, my opening instruction to Copilot was quite deliberate:

Don't make this yet, but we refine a specification first.

I wanted to understand the problem before we started building anything.

What information did the business need? What decisions were people trying to make? What were the relationships between jobs, employees, available hours, commitments and revenue? What would make the solution genuinely useful?

That conversation eventually became a functioning web application, delivered to the end user in late October for use during November.

The development took approximately three working days of my own effort.

We'll explore that implementation in Part 2, including what we built, the technology we used and the decisions that shaped it.

But first, I think it's worth explaining why I approached it that way.

Because the interesting part isn't simply that AI helped produce an application in three days.

It's what happens when we combine the capabilities of modern AI with an understanding of business, systems, architecture and the responsibilities that come with delivering technology people actually depend on.

A little about where I'm coming from

I've spent much of my working life somewhere between business and technology.

My early experience included software development, PHP, databases and building applications. I enjoyed understanding how systems worked, how information was structured and how software could solve practical problems.

Over time, my career expanded into infrastructure, networking, managed IT services, business systems and eventually leading an IT services business.

That introduced an entirely different set of considerations.

Building software is one thing. Supporting technology for real organisations, with real employees, customers, financial constraints and operational consequences, is another.

When a system fails, someone has to fix it. When information is lost, someone has to recover it. When a vendor changes direction or a product becomes too expensive, someone has to find an alternative.

And when technology doesn't deliver the expected business outcome, someone needs to understand why.

My studies in business, leadership and entrepreneurship, together with my MBA and more recent TOGAF enterprise architecture certification, have further shaped how I approach those questions.

I've worked across organisations of very different sizes and in different sectors. One thing I've learned is that the technology is rarely the whole problem.

Sometimes the difficulty is understanding the business process. Sometimes it's unclear accountability, poor data, unnecessary complexity or an organisation continuing to do something simply because that's how it has always been done.

I mention this background because it influences how I work with AI.

I'm not particularly interested in generating software for the sake of generating software.

I'm interested in what becomes possible when we can reduce the effort required to turn a good idea into something that actually works.

And I think we are entering a genuinely exciting period.

The cost of testing an idea has changed

Traditionally, developing a business application could require a substantial commitment before anyone had something useful to evaluate.

There would be requirements workshops, documentation, architecture, development estimates, procurement, project approvals and eventually implementation.

Those activities often had good reasons behind them.

The difficulty was that the cost of getting something wrong could be substantial.

And despite all the planning, it wasn't uncommon for people to discover what they really needed only after they had something tangible in front of them.

AI-assisted development changes that equation.

We can now move from an idea to a working proof of concept much faster than was previously practical.

We can explore alternatives, challenge assumptions, develop interfaces, build data structures, connect services and see how the solution behaves.

Something that might previously have required significant development effort can sometimes be explored in hours or days.

That doesn't mean the resulting application is complete, secure or suitable for production.

It means we can learn much earlier.

And learning earlier can change the way we make investment decisions.

Rather than committing heavily to an idea based on assumptions, we can progressively test whether those assumptions are correct.

The application becomes part of the discovery process.

AI doesn't necessarily make a bad idea good. But it can make discovering that an idea is bad considerably less expensive.

That alone is a significant opportunity.

Start with the business, not the technology

One of the habits I've developed over the years is to begin with the outcome we are trying to achieve.

It sounds obvious, but technology projects don't always begin that way.

It's easy to become enthusiastic about a platform, a product or a capability and then start looking for places to use it.

AI makes that temptation even stronger.

There's always another model, another framework, another agent, another development environment or another impressive demonstration.

But what does the business actually need?

In the workshop example, the initial questions weren't about databases, programming languages or cloud platforms.

They were about managing the operation.

How much work have we committed to?

Do we have the people and capacity to complete it?

Where are the scheduling conflicts?

What does the forward workload look like?

What revenue are we expecting, and how does that relate to the resources available?

Once we understand those questions, we can begin considering how a system might help answer them.

We can identify the information required, the people who will use it, the decisions it needs to support and the consequences if something goes wrong.

Only then does it make sense to start making technology decisions.

This is also where I find AI particularly useful.

An AI assistant can be a surprisingly effective participant in the discovery process.

I can describe a problem conversationally, ask it to challenge assumptions, identify missing requirements, propose alternative approaches and help translate that thinking into a structured specification.

But I'm not asking it to decide what the business needs.

That's still a judgement that requires understanding the organisation and the people involved.

The best technology isn't always the right technology

There's a tendency in AI discussions to focus on which model is currently the most capable.

I enjoy those comparisons myself.

I've experimented with OpenAI, Grok, Qwen and other models, including running AI locally on my own hardware.

Some models perform exceptionally well at particular tasks. Others can be disappointing, even when their published capabilities look impressive.

And the pace of change is extraordinary.

But in a business environment, capability is only one part of the decision.

I use Microsoft Copilot in certain workplace contexts because it fits within the organisation's approved Microsoft environment and associated protections.

That doesn't mean I believe Copilot is always technically superior to every alternative.

It means the decision also involves data handling, identity, governance, licensing, commercial arrangements and organisational responsibility.

Before choosing a model or service, I want to understand what information it will process, where that information might go, which protections apply and whether the service is appropriate for that particular workload.

A publicly available document is very different from confidential financial information, employee records or customer data.

There may be perfectly good reasons to use a cloud AI service.

There may also be circumstances where an approved enterprise platform, a private deployment or a locally hosted model is more appropriate.

And sometimes we don't need AI in the application at all.

The objective is to use the appropriate technology to solve the problem, not to find a problem that justifies our favourite technology.

That distinction will become particularly interesting later in this series when we explore local AI, alternative providers and hybrid architectures.

Security is a design decision

As someone who has spent a substantial part of my career responsible for IT systems and the organisations relying on them, I find it difficult to separate security from application design.

That doesn't mean every application needs the same level of security.

Risk should be proportionate to the information being handled, the people using the system and the consequences of something going wrong.

Our workshop application, for example, isn't processing particularly high-stakes or highly sensitive information.

Nevertheless, we approached it with sensible security-by-design principles.

We considered how users authenticate, what they should be allowed to access, how application secrets are managed and how information can be protected and recovered.

We used existing enterprise identity capabilities where appropriate and designed role-based permissions around the responsibilities of different users.

An important distinction here is that authentication and authorisation are not the same thing.

Knowing who someone is doesn't automatically mean they should be able to see or change everything.

A user may be permitted to view a schedule without being allowed to alter employee information, change configuration or delete records.

Those restrictions need to be enforced by the application, not simply by hiding buttons on a screen.

Another basic consideration is ensuring that credentials, API keys and other secrets aren't exposed in application code or public repositories.

These aren't particularly glamorous subjects, but they're important.

And AI-generated software isn't exempt from them.

In fact, the speed at which AI can generate functionality makes it even more important that we establish sensible design boundaries early.

Secure by design doesn't mean security assured

I want to be clear about something.

Our workshop application has been delivered to its end user, but it still requires rigorous end-user testing and a formal security audit.

I expect there will be bugs.

I expect we'll discover things that could have been designed differently.

And I expect users will identify features and improvements that weren't obvious during the initial discussions.

That's a normal part of software development.

The fact that AI helped us deliver the initial application quickly doesn't remove the need for testing, security review, operational monitoring or continued improvement.

The important distinction is between taking reasonable security precautions during development and having independent evidence that those precautions are sufficient.

We should never confuse the two.

Ownership matters more than convenience

Another principle I've become increasingly conscious of is ensuring that businesses retain meaningful control of their information and systems.

I've seen how dependent organisations can become on individual vendors, applications and service providers.

Sometimes those relationships are excellent.

Sometimes they become expensive, restrictive or difficult to escape.

Vendor dependency isn't necessarily a bad thing. Managed services can provide tremendous value and remove considerable operational complexity.

But organisations should understand those dependencies and the consequences of changing direction.

For the workshop application, we deliberately included functionality to export information and support migration and recovery.

The objective was straightforward.

If the business eventually wants to replace the application, change its hosting arrangements or move to another platform, it shouldn't lose control of its own data.

That doesn't mean every component can be effortlessly replaced.

It means we should know what is dependent on what, preserve the information required to move and avoid creating unnecessary barriers.

The same thinking applies to AI.

Models will change. Providers will change. Pricing will change. Capabilities that are difficult or expensive today may become commonplace tomorrow.

Where it makes practical sense, I want to design applications so that their core business logic isn't unnecessarily tied to one AI provider.

That flexibility has value.

The economics are changing, but they still matter

One of the attractions of AI-assisted development is the potential reduction in development effort.

But we need to look beyond the initial build.

There are subscriptions, API charges, hosting costs, storage, monitoring, support and ongoing maintenance.

As applications become more sophisticated, those costs can accumulate.

And once we introduce AI agents that can independently perform tasks, review work, run tests and repeat activities, the economics become even more interesting.

A single instruction could trigger dozens or hundreds of model calls.

That's potentially useful, but it also needs control.

I want to understand the cost of operating a solution, not just the cost of creating it.

For local AI, that includes hardware, electricity, maintenance and the time spent keeping the environment running.

For cloud services, it includes usage charges, licensing and the commercial consequences of scaling.

For software applications, it includes the cost of defects, outages, changes and supporting users.

Sometimes a managed cloud service will make much more financial sense than operating infrastructure ourselves.

Sometimes local computing resources will provide advantages, particularly for repeated workloads, experimentation or controlled data processing.

The interesting part is being able to make those decisions based on evidence rather than assumptions.

We'll explore that further in Part 3.

What about enterprise architecture?

You might reasonably ask whether formal enterprise architecture has a place in a relatively small application developed over a few days.

I think it does, but perhaps not in the way people sometimes imagine.

I'm a TOGAF Practitioner, and I value the discipline of considering business capabilities, information, applications, technology, governance and the relationships between them.

But I don't believe a small workshop application needs an enormous architecture exercise.

The value isn't necessarily in producing more documents.

It's in asking better questions.

What business capability are we enabling?

What information does that capability depend on?

Which systems need to interact?

What happens when a component fails?

How will the solution change?

Who owns it?

What decisions are difficult or expensive to reverse?

Those questions are relevant whether we're building a modest internal application or designing technology across a large organisation.

The level of formality should reflect the scale and risk of the problem.

And this is another area where AI can be valuable.

It can help us document decisions, explore alternatives, identify dependencies and maintain architectural information without necessarily introducing the same administrative overhead that might previously have made those activities impractical for smaller projects.

Perhaps one of the more interesting opportunities is that good architectural thinking can become accessible to a much broader range of projects.

Not because the architecture is being replaced by AI, but because some of the effort involved in applying it can be reduced.

Build quickly. Then keep building.

I think we need to be careful about the language we use around AI development.

There are plenty of demonstrations showing applications supposedly built in minutes.

Some are impressive. Others are little more than attractive interfaces with limited functionality behind them.

I'm much more interested in what happens next.

Does the application actually work?

Can people use it?

Does it handle unexpected inputs?

Are permissions enforced?

Can the data be recovered?

What happens when a user identifies a problem?

How easily can we change the system?

And does it deliver the business outcome we originally set out to achieve?

A functioning first version is a milestone, not the end of the journey.

The workshop application is a good example.

Three working days of development effort got us to a point where we could deliver a functioning application to the end user.

That's an outcome I find genuinely exciting.

But the next stages are equally important: user testing, feedback, defect resolution, additional features, security assurance and ongoing improvement.

What AI has changed is how quickly we can reach that first meaningful milestone.

It hasn't removed our responsibility for what happens afterwards.

Where this series is heading

This article is the first in a four-part series exploring how I'm using AI to turn business ideas into functioning applications.

I'm not claiming to have found the definitive development methodology or the perfect collection of technologies.

In fact, I fully expect some of the approaches I'm using today will change as the technology evolves.

That's part of what makes this so interesting.

In Part 2 — From Idea to Working Application, I'll take you through the workshop management application we've recently delivered, along with another example of a business website built using AI-assisted development.

We'll look at how an initial conversation became a specification, how that specification evolved into a web application, and how Microsoft Copilot, GitHub and Cloudflare contributed to the process.

I'll share actual screenshots, the development and deployment workflow, the architectural decisions and some of the lessons along the way.

In Part 3 — Beyond the Enterprise Stack, we'll move into my local AI environment, alternative models, cloud-versus-local computing and the importance of designing for change.

In Part 4 — From Assistant to Orchestrator, we'll explore something I've been increasingly interested in: using specialised AI agents to plan, develop, test, review and improve applications, with appropriate human oversight.

From there, I intend to develop an ongoing Building Blocks series, exploring the individual technologies and reusable capabilities that make these systems work.

The aim is to build a practical library of ideas, implementations and lessons that others can learn from, challenge and improve.

An invitation to challenge the thinking

One of the things I've learned over the years is that there is rarely only one way to solve a technology problem.

And the pace of change in AI makes that more apparent than ever.

I enjoy experimenting with new technologies, but I'm equally interested in understanding their limitations and discovering better ways to do things.

If you've built something similar, have a different architectural approach, know a better technology, see a security consideration I've missed or simply disagree with one of my conclusions, I'd genuinely like to hear from you.

Share what you're working on. Ask questions. Suggest alternatives.

I'd rather discover a better approach than spend my time defending an existing one.

Because, ultimately, the point isn't that AI can write code.

It's that we can take ideas, test them, learn from them and turn them into useful systems more quickly than ever before.

And if we combine that capability with sound business judgement, architectural thinking and appropriate governance, I think we're only beginning to understand what's possible.

Experiment quickly. Govern deliberately. Build things that function.

Building with AI is an ongoing series published by ConsultiQ, exploring practical AI-assisted development, business architecture, security, local AI and emerging agentic technologies.

Next: Part 2 — From Idea to Working Application.

This series documents real implementations, experiments and lessons learned. The technologies, designs and conclusions will continue to evolve as we test, learn and improve.