That focus on a specific, recurring problem was central to the project. Rather than asking Claude Code to build a generic “parenting app,” Tan described the information parents needed to enter, the calculations the system should perform and the way both users should access the data.

His workflow: requirements first, code second

Tan’s approach resembled a lightweight product-development process, even though he was not a programmer. He began by writing detailed requirements in ordinary English, then used Claude Code to translate those requirements into an application.

The reported workflow was:

1. Download and run Claude Code through Mac Terminal.
2. Write a four-page specification describing the app’s features and behaviour.
3. Ask Claude Code to build from those requirements and explain each implementation step in terms a non-coder could follow.
4. Create accounts with GitHub, Supabase and Vercel.
5. Connect the services so GitHub stored the code, Supabase handled the database and user authentication, and Vercel deployed the app to a web link.

The tools each filled a different role. Claude Code was the development interface, GitHub was the code repository, Supabase provided the backend services, and Vercel handled deployment. That combination allowed Tan to move from a written idea to a functioning web application without first mastering a traditional programming stack.

Why detailed prompts mattered

Tan did not expect the first generated version to be perfect. He tested the app, described anything that was missing or incorrect and asked Claude Code to revise it. The process was iterative: prompt, inspect, test and refine.

His experience led to a simple rule: vague instructions tend to produce vague results. The more precisely he described the desired fields, permissions, calculations and user experience, the more useful the generated output became. Claude Code could generally understand imperfect or “broken” English, but understanding a request was not the same as making the request complete.

That distinction is important for anyone using an AI coding tool. Natural-language development can lower the barrier to starting a project, but it does not remove the need to define requirements or evaluate the result.

Using AI for research required verification

Tan also used Claude Code with Perplexity AI for research because it returned citations. However, he did not assume that a citation automatically made an answer reliable.

When the research surfaced a claim identifying finned fish as a leading allergen concern in Singapore, Tan questioned it because shellfish was the more familiar concern in his experience. He checked the cited material and corrected the app. The account also highlights a broader risk: AI search systems can produce citations that point to fictitious studies, so important health-related information still needs independent verification.

For a baby-tracking tool, this caution was especially significant. The app could organise observations and compare them with guidance, but AI-generated research should not be treated as medical proof simply because it includes links or citation markers.

The same prompting skills produced a translation tool

The skills Tan developed while building the baby app carried over into his work. He created a one-button translation tool capable of converting English content into 48 languages.

His instructions went beyond word-for-word translation. The tool was first told to understand the source text’s meaning, intent and persuasive objective. It was then directed to produce natural writing for the target language rather than preserve English-shaped phrasing, rhythm or logic.

That workflow reflects the same principle as the baby app: the quality of the result depends heavily on whether the user explains the goal, context and constraints—not merely the task.

The larger lesson for non-coders

Tan’s experience is not evidence that AI makes software development automatic. He still had to identify a real problem, write a detailed specification, create accounts, connect services, test the application and challenge unreliable research.

But it does show how an AI coding assistant can let someone begin with a useful product idea rather than years of programming study. For Tan, experimentation and clear prompting are becoming practical skills for ordinary users, including people who do not write perfect English.

The most transferable lesson is therefore not “AI can build anything.” It is that people without coding backgrounds can use AI to prototype narrowly defined tools—provided they remain responsible for the requirements, testing and factual judgment.

That focus on a specific, recurring problem was central to the project. Rather than asking Claude Code to build a generic “parenting app,” Tan described the information parents needed to enter, the calculations the system should perform and the way both users should access the data.

His workflow: requirements first, code second

Tan’s approach resembled a lightweight product-development process, even though he was not a programmer. He began by writing detailed requirements in ordinary English, then used Claude Code to translate those requirements into an application.

The reported workflow was:

1. Download and run Claude Code through Mac Terminal.
2. Write a four-page specification describing the app’s features and behaviour.
3. Ask Claude Code to build from those requirements and explain each implementation step in terms a non-coder could follow.
4. Create accounts with GitHub, Supabase and Vercel.
5. Connect the services so GitHub stored the code, Supabase handled the database and user authentication, and Vercel deployed the app to a web link.

The tools each filled a different role. Claude Code was the development interface, GitHub was the code repository, Supabase provided the backend services, and Vercel handled deployment. That combination allowed Tan to move from a written idea to a functioning web application without first mastering a traditional programming stack.

Why detailed prompts mattered

Tan did not expect the first generated version to be perfect. He tested the app, described anything that was missing or incorrect and asked Claude Code to revise it. The process was iterative: prompt, inspect, test and refine.

His experience led to a simple rule: vague instructions tend to produce vague results. The more precisely he described the desired fields, permissions, calculations and user experience, the more useful the generated output became. Claude Code could generally understand imperfect or “broken” English, but understanding a request was not the same as making the request complete.

That distinction is important for anyone using an AI coding tool. Natural-language development can lower the barrier to starting a project, but it does not remove the need to define requirements or evaluate the result.

Using AI for research required verification

Tan also used Claude Code with Perplexity AI for research because it returned citations. However, he did not assume that a citation automatically made an answer reliable.

When the research surfaced a claim identifying finned fish as a leading allergen concern in Singapore, Tan questioned it because shellfish was the more familiar concern in his experience. He checked the cited material and corrected the app. The account also highlights a broader risk: AI search systems can produce citations that point to fictitious studies, so important health-related information still needs independent verification.

For a baby-tracking tool, this caution was especially significant. The app could organise observations and compare them with guidance, but AI-generated research should not be treated as medical proof simply because it includes links or citation markers.

The same prompting skills produced a translation tool

The skills Tan developed while building the baby app carried over into his work. He created a one-button translation tool capable of converting English content into 48 languages.

His instructions went beyond word-for-word translation. The tool was first told to understand the source text’s meaning, intent and persuasive objective. It was then directed to produce natural writing for the target language rather than preserve English-shaped phrasing, rhythm or logic.

That workflow reflects the same principle as the baby app: the quality of the result depends heavily on whether the user explains the goal, context and constraints—not merely the task.

The larger lesson for non-coders

Tan’s experience is not evidence that AI makes software development automatic. He still had to identify a real problem, write a detailed specification, create accounts, connect services, test the application and challenge unreliable research.

But it does show how an AI coding assistant can let someone begin with a useful product idea rather than years of programming study. For Tan, experimentation and clear prompting are becoming practical skills for ordinary users, including people who do not write perfect English.

The most transferable lesson is therefore not “AI can build anything.” It is that people without coding backgrounds can use AI to prototype narrowly defined tools—provided they remain responsible for the requirements, testing and factual judgment.