Building With AI as a Tool

AI Is Mostly a Tool, Not a Feature

Most software companies want you to believe AI belongs in the product.

Sometimes it does. In this case, it did not.

Last month, I built three interconnected systems solo for The Usual Suspects Garage: a customer-facing storefront, an administrative backend, and an internal portal supporting the development of a custom digital instrument cluster.

The client was also developing the physical hardware at the same time.

None of the shipped systems included AI.

There was no chatbot, no customer-facing content generator, and no model making decisions that should be made by a person. The storefront remained a storefront. The administrative system remained an administrative system.

AI was not the feature. It was the force multiplier behind the work.

Where the Speed Came From

The most obvious example was the digital instrument cluster.

Without additional tooling, the development cycle would have looked like this:

Change the code. Flash the physical device. Review the interface. Identify what needs to change. Repeat.

Every iteration would require access to the hardware, and every small design adjustment would carry the cost of another physical flash cycle.

Instead, we used AI to build a custom emulator.

The emulator allowed me to move interface elements, adjust values, and preview changes directly on screen without repeatedly loading each version onto the physical device. The hardware only needed to be flashed once the design was substantially complete.

AI did not decide what the dashboard should display. It did not determine how the customer should interact with it.

It helped me build a better development environment.

That distinction eliminated one of the largest constraints in the project.

The Less Visible Advantage

The emulator was the most specialized use of AI, but it was not the only source of speed.

Across all three systems, AI accelerated the routine development work that usually consumes a large portion of a software project: interfaces, forms, tables, dashboards, validation logic, and the connective tissue between different parts of the application.

None of that work was removed.

It simply moved faster.

That mattered because the project was not one isolated application. It was three systems that needed to operate together while the client's hardware development continued on a separate timeline.

The interface work could not become the bottleneck.

AI allowed one person to carry a scope that would normally have required several months, a larger team, or both.

What Stayed Out of the Product

The client restores vehicles and develops custom automotive hardware.

The systems needed to reflect how the business actually operated. They did not need to showcase every technology currently receiving attention.

Adding a chatbot or another visible AI feature would not have solved a meaningful customer problem. It would have added complexity without improving the product.

That is the mistake many companies are making.

They begin with the technology and search for somewhere to place it. The availability of AI becomes the justification for including it.

That reverses the correct order of product development.

The problem should determine the feature. The technology should support the solution.

The Difference Between a Feature and a Tool

A feature is something the customer experiences.

Using AI there is a product decision. It should face the same scrutiny as any other product decision:

Does it solve a real problem? Does it improve the customer experience? Does it perform better than a simpler alternative?

A tool is different.

A tool supports the person building the product. It may never be visible to the customer. Its value comes from making the work faster, more accurate, or easier to manage.

The risk is also different.

When I use AI as an internal development tool, I am responsible for reviewing the output, testing the system, and ensuring the final product works correctly. The customer does not have to carry the uncertainty of interacting directly with a model.

That creates a much wider range of useful applications.

AI can support research, generate initial code, accelerate debugging, create testing tools, document systems, and shorten iteration cycles without becoming part of the final user experience.

What AI Actually Bought

The result was a solo build completed in one month across three interconnected systems, running in parallel with the client's hardware development.

Without the emulator, each dashboard revision would have required another physical flash cycle.

Without AI-assisted development, the everyday interface work would likely have become the limiting factor.

Together, those constraints could have turned a one-month project into a three-month project.

The AI use that made the timeline possible left almost no visible trace in the final product.

That was not a missed opportunity. That was the point.

AI did not need to become the product to create value. It improved the process used to build the product.

The Better Question

The first question should not be whether a product needs AI.

The better question is where AI should live.

Inside the development process, the iteration loop, and the internal tools, the barrier to experimentation can be relatively low and the upside can be substantial.

In front of the customer, the standard should be much higher.

AI should earn its place by solving a real problem better than the available alternatives. Its inclusion should be based on customer value, not novelty.

AI can be a feature.

But in many of its most valuable applications, it is the tool behind the feature, the system, or the business.

Knowing the difference is what allows companies to use it well.