Don't Start with AI, Start with a Problem

The most common trap in building with AI is starting with the technology rather than the friction. You discover a powerful language model and immediately ask: “What can I build with this?”

That approach can produce a prototype before anyone has decided what problem it should solve. A better starting point is the person you want to help, the task that is getting in their way, and the part of that task where AI may be useful.

Here is a practical framework for moving from an everyday problem to a useful tool.

Step 1: Dissect the problem statement

Before writing a single line of code or drafting a prompt, isolate the friction you want to eliminate.

A useful problem statement answers three specific questions:

1. Who experiences this pain point? (e.g., parents helping children revise for Singapore school examinations).
2. What is the manual bottleneck? (e.g., parents struggle to mark open-ended science questions against official SEAB criteria and explain why points were awarded or docked).
3. What is the current alternative? (e.g., flipping through printed assessment book answer sheets that provide only a single model answer without explanations for variations).

Notice that artificial intelligence is not mentioned anywhere in this initial diagnosis. The focus remains entirely on human friction and operational reality.

Step 2: Map the information flow

Every software application is fundamentally an information pipeline. Once the problem is defined, sketch the step-by-step path that information takes from origin to resolution.

Trace the three essential stages:

• The Source: Where does the raw data come from? (A student uploads a photo of handwritten homework or types an answer into a browser).
• The Processing: What transformations must occur? (Extract text from the image, match against the exam mark scheme, score the response, generate a personalized explanation).
• The Destination: Where does the final output go? (Displayed on the student’s phone screen with interactive follow-up chat options).

Mapping this pipeline on paper exposes every dependency before development begins.

Step 3: Divide labor between code and LLMs

Once your workflow is laid out, decide which steps need ordinary software and which steps need language understanding.

What usually belongs in normal code

Normal code is a good fit for work with a clear, repeatable answer:

• Database reading and writing.
• User authentication and access controls.
• Arithmetic computations and score tallies.
• Routing network requests and checking HTTP response status codes.
• Formatting structured tables and exporting PDFs.

If a task has a fixed rule, start with code. It will usually be faster and easier to check.

Where an LLM may help

Language models are useful when the input is messy or the output needs to be written in natural language:

• Deciphering unclear text from photographed handwriting.
• Comparing an open-ended answer with the ideas in a marking guide.
• Turning an unstructured meeting transcript into a short task list.
• Writing an explanation in a tone or reading level that suits the person receiving it.

Keep the model focused on the parts that need language understanding. Keep the rest in normal code so the result is easier to test and correct.

Step 4: Define what constitutes success

Before building, you must define the acceptance criteria. How will you know whether your tool actually solved the problem?

Vague aspirations like “the app should feel smart” are difficult to check. Define observable criteria:

• Can a student submit a photo of homework and receive useful feedback within an acceptable time?
• Does the feedback point to the relevant idea from the marking guide?
• Does the tool ask for a clearer image when the original is too blurry to read?

When you have a clear problem, a mapped workflow, a clean division between code and language models, and an unambiguous definition of success, building the actual application becomes straightforward.