Need to solve a unique problem? There are options.

Most software is designed for a market.

It has to work reasonably well for a lot of people, which usually means compromise. The feature you care about may be buried. The workflow may not match how you actually work. You may be paying for things you don’t need while the one thing you really want is missing.

Sometimes that’s fine.

Sometimes it’s not.

AI-assisted development has changed the equation enough that building something yourself can now be a realistic option—even if you don’t know how to code.

You may already know how to code. You may not. Either way, the interesting change is how much less distance there is now between describing a useful piece of software and having something working that you can actually test.

Build around your problem.

One application we’re working on, Investment Portfolio Modeler, exists because the investing workflow we wanted is unusually specific.

It takes model portfolios we follow (or create ourselves) as input—for example, the High Yield Investor (HYI) model portfolio on Seeking Alpha. The app lets us combine models in proportions we choose, compare them against our actual holdings, account for things like ticker substitutions, drift tolerance ranges and custom variations, and produce dollar-based guidance for bringing our own portfolio closer to the model.

Could you do some of that in a spreadsheet? Sure.

But once you start combining portfolios, holdings, substitutions, tolerances and calculations, that spreadsheet can become complicated and unwieldy very quickly. It’s time-consuming to maintain and easier to get wrong.

Could existing investment software do some of it? Absolutely. But finding something that matches your particular workflow and priorities is a different matter.

Another application we’re building, Limits Express Operations, takes a very specific business process involving externally managed Google Sheets, inventory funding, sales, expenses and operational information and brings it together into one purpose-built dashboard.

Different problem. Same idea.

Instead of changing the process to fit the software, sometimes you can build the software around the process. In many cases, the software doesn’t exist until you build it.

AI changed what’s practical.

This is the part that feels different.

Not that long ago, an idea for a small custom application could mean months—or even years—of learning programming languages, frameworks, databases, development environments and everything else needed just to get started.

Even if the idea were possible, the investment often wasn’t practical. So a lot of ideas simply never got built.

AI changes that.

Those skills still matter, but they’re no longer necessarily a hard requirement for getting started. Depending on the problem, something that once might have taken months can sometimes take weeks or even days to get to a useful first version.

That doesn’t mean AI spits out a finished application.

You still have to explain the problem, make decisions, test the result, notice what’s wrong and keep refining it.

The AI can write a lot of code.

You still have to decide what “right” looks like. You are still in charge.

Want to try it?

There are almost unlimited ways to set up an app development environment. This is just one straightforward approach that works well for us on a Windows computer:

1. Set up WSL with Ubuntu.
2. Install Visual Studio Code.
3. Make sure Git is installed inside your Ubuntu/WSL environment.
4. Install the Codex extension in Visual Studio Code and connect it to your coding environment.
5. From a PowerShell prompt, launch WSL with wsl, create or navigate to an empty project folder inside your WSL environment, and open it in VS Code with code ..

Use the current official installation instructions for those tools rather than relying on detailed installation commands reproduced here. Those instructions will stay more current than this article.

Then start with the problem—not the code.

Start by explaining what you need the application to accomplish before deciding how it should be built.

A reasonable first prompt might be:

I want to build a small application that solves this problem: [describe your problem].

Before writing code, help me clarify the requirements, choose a simple architecture, identify important security or privacy concerns, and define a small first milestone.

Ask questions when something isn’t clear. Keep it simple.

Then start talking.

Answer the questions. Challenge things that don’t make sense. Try what it builds. Tell it what doesn’t work. Send screenshots. Change your mind.

That is a perfectly valid process. There isn’t necessarily a right or wrong approach. Do what works for you.

One user can be enough.

Your application doesn’t have to become a product.

If it saves you time, solves a problem, reduces mistakes, or simply works the way you want it to work, that can be enough.

The next time you catch yourself saying:

“I wish this application would just…”

don’t immediately assume you need to find another application.

That sentence might be the beginning of your own.