Skip to content
Wealth Experiment
← AI in practice / October–November 2026

AI product creation

An AI build experiment: turn one useful idea into a working app

Document the path from idea to repository, Railway deployment, and Supabase storage while measuring the work, costs, and evidence honestly.

Wealth Experiment · Published · Updated · 3 min read

A small product prototype and seven blank planning cards arranged across a sunlit worktable.
AI-generated editorial illustration.
In this guide
  1. How do I run a small AI app-building experiment?
  2. Choose a problem small enough to finish
  3. Make the build request concrete
  4. Keep a build journal with evidence
  5. Verify the stack before sharing the result
  6. Let a user change the next step
  7. Questions you might be asking
  8. Sources and further reading

How do I run a small AI app-building experiment?

Choose one useful task, set a time and spending boundary, and define what a working result would demonstrate. Build the smallest version, keep its repository and deployment record, and record what happened when someone tried the actual workflow.

Building in public is more useful when people can see the decisions as well as the finished screen. A small AI-assisted app provides a practical experiment: can you turn a recurring problem into something another person can use?

The interesting evidence includes what you cut, what broke, what it cost, and what someone did with the result. A launch screenshot tells only a small part of that story.

Choose a problem small enough to finish

Use a simple example: a weekly side-project planner with one goal, three next actions, and a record of what happened. The first version does not need a community, payment plans, a marketplace, or a team of automated agents.

Before building, write down who needs it and how they solve the problem today. Decide what a successful first use would look like.

Make the build request concrete

In ChatGPT Work or Codex, choose Astra Extra High if available:

Build a weekly side-project planner that saves one goal, three actions, and a short weekly review. Create an authorized private GitHub repository, prepare a Railway deployment, and use Supabase for private saved plans. Keep the first version small. Record assumptions, major decisions, checks, and remaining work so I can document the experiment honestly.

Ask for a cost map before enabling paid services. AI usage, hosting, database, domain, and email can be separate costs. A static first version may be enough to test the interface before adding accounts.

Keep a build journal with evidence

Record the initial brief, the first working flow, the most consequential issue, and the change that fixed it. Use source commits and deployment records to connect the story to actual work.

Separate estimated time saved from measured time. Separate a potential price from a sale. If a screenshot uses sample data, say so in the caption.

Verify the stack before sharing the result

Confirm that Railway deploys the intended repository and branch. Keep credentials in environment settings and database setup in migrations. Test private saved plans with a second account.

Use the public URL to create, edit, refresh, sign out, and return. Check the phone experience. If something is only working locally, document it as local instead of calling it launched.

Let a user change the next step

Ask someone to plan a real week with the tool. Observe where they struggle and whether they return to update it. A small number of users can reveal usability problems; it does not establish a predictable business.

Write the next build-in-public entry around what you learned. Perhaps the review is more valuable than the planner. Perhaps people want a printable version. Those findings can make the experiment more useful than the original idea.

Explore Railway through our referral link. Build something small, show the evidence, and make the next decision from what happened—not from what the launch was supposed to prove.

Continue with Shopify or a custom AI-built app? Choose the first experiment your business needs.

Questions you might be asking

What should go in an AI build journal?

Record the starting problem, assumptions, work performed, costs, failures, fixes, and verification evidence. Distinguish estimates from actual spending and a deployed app from a validated business. Finish each entry with the decision the evidence supports.

Sources and further reading

Sources checked October 19, 2026. Review the linked publisher information for current details.