Using AI to Build a Blazor App 1: Start With the Problem

Many AI-assisted projects fail before a line of code is written because the idea was never properly defined. Here’s how to use an LLM to interrogate your own thinking until a vague premise becomes something you can actually build.

How do you go from idea to working software? That’s the challenge we face as software developers.

While AI feels like it’s changed everything, it hasn’t changed that fundamental problem.

It’s not a question of how quickly AI can write code (answer: very quickly), but rather how soon can we find out if our assumptions are correct and if we’re building the right thing to move the needle.

Do we even know what needle we’re trying to move in the first place?

In this short series, we’ll explore how we can use AI to build the right things, to solve the most urgent problems, without shipping substandard code.

• We’ll start with a vague premise and see if AI can help us sharpen our understanding of what we’re building (and why).
• Then we’ll move on to working with AI to carve out the headline feature we want to build first.
• We’ll remove ambiguity (and reach a shared understanding of what we’re building) using prototypes and tracer bullets.
• Then we’ll establish the architecture of what we’re building (including key technology choices), break the work down into smaller steps and build it.

First, we need to get clear about what we’re building.

A Journey of a Thousand Miles Begins with a Single Step

If you’ve been experimenting with AI, you already know the big AI trap. The temptation to just throw a vague prompt its way, cross your fingers and hope it magically builds the perfect web application (while you sleep).

In reality it’s not that simple.

AI will happily run off and build whatever you ask it to, which is problematic if you ask it to build the wrong thing, start with fuzzy requirements or give it too much to do in one step.

So, the first task is the same as it’s always been: get clear about the problem you’re solving.

In this case, I started with a simple problem to solve. I have a goal of writing at least one article a week for my personal blog and also an email to my newsletter audience (based on the same blog post). In reality, that cadence is rarely once a week, and often drifts to once a month or, in the worst case, once “every now and then.”

So starting with that problem, I gave this prompt to GPT 5.5 (via the Codex GUI):

I want to build a new web application using .NET 10 and Blazor. Please grill me on the idea, what it’s for, key technology choices, and help me scope out a reasonable first version so we can get user feedback as soon as possible

This did not go well.

GPT 5.5 responded with a giant wall of text and lots of questions. It started diving into implementation details about Blazor (which render mode to use, etc.) and essentially skipped the part where it finds out what I’m trying to build before focusing on those implementation details.

I started over, and tried different variations of the same prompt.

First I got it to ask me one question at a time, which worked better, but I realized it was still jumping to technical details. I wanted to keep it focused on problems and ideal outcomes, not technical matters or even defining the feature details at this stage.

After a few iterations we arrived at this:

I want to build a new web application using .NET 10 and Blazor.

Please grill me on the idea.

Ask me one question at a time, and include your brief recommendation for each question.

Dig into each answer until that thread is clear, then move on to the next question.

For notable decisions (anything fundamental, or where the reasoning for which can’t be deduced from implementation), capture that decision as an ADR in a decisions folder.

Help me explore the problem space, and the core outcomes we want this application to achieve.

Do not scope features at this point, that will come next.

This worked better.

Over the course of a 45-minute back-and-forth, we fleshed out the problem I was trying to solve, and the rough shape of any potential solution. I won’t include the entire conversation here, but here are some highlights.

It asked:

Where do ideas currently appear first: while at your computer, on your phone, in notes, in code/projects, from conversations, or somewhere else?

The answer I gave included this phrase: “Could be anywhere really.”

GPT 5.5 wasn’t having that.

This one isn’t quite a decision yet, because “could be anywhere” can lead to a lot of product surface.

Follow-up question:

For the first version, is it acceptable if mobile capture is only a lightweight inbox, with real writing/editing still expected to happen at a keyboard?

In my experience, AI shines with this kind of process, digging into answers you give it and getting clear so you can make concrete decisions, not just hand-wavey “ideas.”

Some more questions it posed:

What would make this application feel like a calm writing system rather than another obligation to maintain?

What is the smallest publishing rhythm that would still feel successful: exactly one post/email every week, or a sustainable average with occasional skips and catch-ups?

What would make you stop using this app, even if it technically worked?

Notice how GPT 5.5 stayed on task here, exploring the problem and not getting into feature design, or technical choices.

Eventually we arrived at this summary:

The core shape is now clear: a local-first, single-user Blazor/.NET app that helps you maintain a weekly blog-plus-newsletter rhythm, with the Astro repo as source of truth, a calm Markdown writing experience, lightweight AI assistance, and explicit publishing/Git steps.

The main technical decision made was the one I started with (that we’d be using Blazor to build it) and some high level thoughts around source of truth, and the existing systems (like my blog).

We also ended up with a number of architecture decision records (ADRs) captured in markdown documents. ADRs are typically used to capture technical decisions, but were also useful here for capturing the decisions we arrived at around the problem and solution itself.

Here’s one example:

# ADR 0028: Slug Generation
Status
Accepted

## Context
Blog posts need a final URL slug. The slug should usually be short, readable, and aligned with the article's content or main takeaway.

Manual override is sometimes needed.

## Decision
The application should generate slugs automatically from the article title or main takeaway, while allowing the user to override them.

Slugs should be treated as stable after publication unless deliberately changed.

## Consequences
Slug generation should optimize for short, meaningful URLs rather than blindly mirroring the full title.
The user must retain control over the final slug.
Published slug changes should be treated as deliberate edits, not incidental metadata updates.

Whenever I work through an AI interview like this, I find I emerge with a much clearer picture of what I’m building (and why). The LLM’s questions force me to think and often surface angles I hadn’t previously considered. In some cases I’ve gone on to realize building a feature is actually unnecessary (a change to existing habits or processes would achieve the same result).

In this case, though, we’re on the right track and have a clearly scoped brief for an editor to capture ideas and author content.

Make It Work for You

When you try to use AI to build something like this, you might feel like there should be some simple streamlined process you can work through. A clean process where you feed a feature idea in, AI gives you perfect code out and you ride off into the sunset.

Alas, software design is anything but streamlined, and no AI tool is going to take the chaos of defining and refining an idea and handle it in a nice straight line.

In this case, getting AI to grill you about the idea is one part of the design process, but there are others, which we’ll come to shortly. We started high-level here because this was an embryonic idea and a greenfield application. But if you already had an app and were adding a feature, you might skip this step and jump straight into designing a specific feature/requirement.

Iterate Your Prompts

But what about the prompt itself? Did I happen upon some perfect, fully formed prompt that made AI work perfectly? In short, no!

Prompts rarely arrive fully formed. In this case, I started with a vague prompt, then refined and tested it until I found one that worked better for my needs. This is a key difference I’ve noticed between people who get good results from an LLM and those who feel frustrated.

It’s useful to learn how to write effective prompts, or “meta prompts” (where you get AI to write the prompt for you), and run rapid iterations so you can get something that works for you. Here it took around five minutes to get to a prompt that worked well for this exercise.

You can also turn to examples published online (Matt Pocock’s skills are a clear standout), but it’s useful to learn how to create your own skills/prompts, based on your own unique workflow and preferences.

With that said, we’ve carved out our idea: a simple “surface” for capturing ideas and turning those into articles (with the source of truth being an MDX in an Astro blog).

Now to define the headline features. That’s next, in Part 2.