Six Ideas for My Second Project

After my first small website experiment, I wanted my second project to teach me something more valuable than how to ship another application.

I already know that I can build websites, applications, backend systems, and AI-assisted features. The next gap is on the business side: identifying real demand before building, understanding where a need comes from, speaking directly with buyers and users, testing willingness to pay, and learning whether a business model can produce profit.

The ideal project should provide market evidence quickly and cheaply while creating future options: recurring revenue, reusable systems, customer relationships, distribution, or an owned product catalogue.

I compared six possibilities:

1. A rental, water, and electricity record app
2. A stock-strategy execution tool
3. An offline card game with a stronger AI opponent
4. A friend’s e-commerce business
5. Digital materials and printable products
6. A poker training product based on AI

The comparison did not produce one perfect idea. It separated projects with immediate commercial evidence from projects that are mainly interesting hypotheses.

The evaluation criteria

For each option, I asked:

• Is the need visible in current behaviour, or is it only a casual suggestion?
• Can I reach the first user or buyer directly?
• Has anyone already spent money or time solving the problem?
• Would the person pay for a product, or only express interest in the outcome?
• How do they solve the problem today: notebooks, spreadsheets, employees, marketplaces, or existing apps?
• Is there a realistic distribution channel?
• Could the project create reusable assets or future relationships?
• What happens if the main hypothesis is wrong?

This changed the ranking. Technical novelty still matters for learning, but it is a weak reason to commit several months. Evidence of a buyer, a painful workflow, or an owned distribution asset is more useful.

Option 1: A rental and utility record app

This idea came from a specific user: a friend’s aunt collects rent and manages property-related payments. Her current workflow includes photographing water and electricity bills, recording rental income manually, organising fees by property, tenant, and month, and checking which payments have been received.

That makes the problem much more credible than an abstract idea. I could observe the workflow directly, build around actual bills and records, receive immediate feedback, and learn how a non-technical user interacts with a simple business tool. If trust develops, the first user might also introduce other landlords with similar problems.

The weakness is that one real user does not yet prove a repeatable market. I would still need to find out:

• How many small landlords have the same problem
• Whether they are already satisfied with notebooks, spreadsheets, WeChat, or general-purpose apps
• Whether they would pay for a dedicated tool
• Whether this is mostly a problem for older landlords or a broader segment
• Whether the value justifies ongoing maintenance and support
• Whether users would trust a small application with financial records
• Whether customer acquisition would cost more than the product could earn

A generic expense tracker would face strong competition. The narrower opportunity would be a tool specifically for rent, water, electricity, and property-level records.

Useful profit signals would be stronger than verbal enthusiasm. The first user would need to keep using it without assistance, replace her old record-keeping method, ask for additional properties or exports, or introduce other landlords. A possible path would be:

One-landlord tool → simple app for small landlords → paid setup and support → lightweight property-management product

This is a strong user-learning project with low risk. It is not yet the strongest business opportunity because the market evidence stops at one user.

Option 2: A stock-strategy execution tool

Another friend recently started investing and believes some of his trading strategies can produce reliable profits. His thinking is not yet organised into precise, deterministic rules.

He showed limited willingness to pay for backtesting, strategy analysis, and notifications. He showed much stronger willingness to pay for automatic execution of buy and sell decisions. That distinction matters. He does not primarily see the product as an analysis or productivity tool; he sees it as software that could help capture future investment returns.

There is a clear expression of willingness to pay, but it is attached to the most difficult and risky part of the product. If the strategy loses money, the user may blame the strategy, the execution, the brokerage connection, or the software itself. The expectations could become much higher than those attached to an ordinary business tool.

Before automatic execution could even be considered, the strategy would need exact definitions for:

• Entry conditions
• Exit conditions
• Position sizing
• Order types
• Maximum exposure
• Loss limits
• Failure handling

The business risks are substantial: regulatory exposure, brokerage API restrictions, platform permissions, incorrect or delayed orders, losses caused by strategy errors, losses attributed to the software, security of brokerage credentials, monitoring requirements, and expectations of guaranteed returns. A public application that trades through customer brokerage accounts would be especially difficult.

The current willingness to pay is therefore a weak validation signal because it depends on the assumption that the strategy will make money. Stronger evidence would be that the user documents the strategy precisely, commits to historical testing, uses paper trading for an extended period, accepts strict risk controls, and pays for a simulation or workflow product before live execution.

A safer product path would be:

Strategy specification → historical replay → paper trading → human-confirmed orders → private execution with strict limits

The legitimate long-term product might focus on strategy testing, trading journals, risk controls, paper execution, and post-trade analysis. It has stated commercial interest, but it is a poor fit for a fast public market-validation project.

Option 3: An offline card game with stronger AI

This idea came from a friend who already plays a specific card game on her iPhone during flights, when she cannot rely on an internet connection. She repeatedly uses an existing application but finds the computer opponent too weak and wins too easily.

That is meaningful evidence because it combines existing behaviour, a concrete environment, and dissatisfaction with a competitor. It is more useful than a casual suggestion for a game that someone does not currently play.

The problem is not operational pain. Games can create value through entertainment, challenge, replayability, and habit. The possible wedge is a polished, fully offline card game with a computer opponent that is genuinely challenging and fair.

The main questions are:

• Do many players complain that the competitor’s AI is too easy?
• Is the exact game large enough to support a new product?
• Would players switch from free alternatives?
• Would they pay for stronger AI, expert mode, or an ad-free experience?
• Would advertising conflict with the offline use case?
• Can a one-time purchase produce enough revenue?
• Can the product reach Chinese-speaking users if the mainland China App Store is unavailable?
• Is the improvement in AI noticeable enough to become a purchase reason?

Distribution is the largest ambiguity. Even an excellent game will struggle if the intended audience cannot easily find or buy it. Useful signals would include competitor reviews mentioning weak AI, test players replaying after losing, players repeatedly choosing harder levels, users stopping their use of the existing competitor, and overseas Chinese-speaking users showing interest.

This is a good low-risk launch experiment and a useful way to learn App Store validation. Its monetisation and distribution are still uncertain, so I would not put it ahead of a paying business customer.

Option 4: A friend’s e-commerce business

This option has the strongest combination of existing profit, buyer access, confirmed willingness to pay, immediate cash-flow potential, relationship value, and reusable commercial experience.

My friend has operated a toy business for approximately three years. He sells through a Chinese e-commerce platform and another East Asian platform, with existing products, customers, sales history, operational experience, and revenue. The business earns a 6–7 figure annual profit.

This is not a speculative market. It is an operating business. The owner actively wants an independent website as another sales channel, is eager to proceed, and is willing to pay.

The website itself does not guarantee traffic or sales. Marketplaces currently provide discovery, customer trust, payment infrastructure, and transaction support. An independent site would still be valuable as:

• An official brand presence
• A destination for advertising
• A repeat-customer channel
• A wholesale catalogue
• A controlled product and customer-data channel
• Infrastructure for future growth
• A foundation for other business systems

It would also give me direct experience building a real commercial website rather than a purely experimental site.

The distribution questions need to be answered early:

• How will customers discover the website?
• Will the owner run advertising?
• Will existing customers be directed there?
• Is the site for retail, wholesale, or both?
• How will shipping, returns, and regional payments work?
• Does inventory need to synchronise with the existing platforms?
• Who provides product data, translations, and photographs?
• How much maintenance will be expected after launch?

The commercial agreement should separate the initial build fee, product-data setup, third-party costs, maintenance, the bug-fix period, new-feature pricing, and responsibilities for traffic, advertising, fulfilment, and sales. My main risk is not technical difficulty. It is uncontrolled scope and indefinite support.

The possible business path is unusually concrete:

One paid website → ongoing maintenance → additional business systems → referrals → repeatable e-commerce service → productised service for cross-border sellers

The work can also create reusable assets for future projects: product-page modules, checkout flows, analytics, multilingual content, SEO structure, customer-service integrations, catalogue management, deployment, and maintenance processes. The right approach is to build for this customer first, then extract reusable modules from a working system.

The more painful problem may be customer service

The website is the clearest first delivery, but customer service may be the strongest long-term product opportunity.

The business owner currently pays someone to handle customer service and also responds personally. Customers sometimes expect replies within one minute. The situation affects his sleep, daily schedule, ability to disconnect from work, response quality, and labour costs. He is dissatisfied with the current employee and has clear willingness to pay for a better solution.

The real value proposition is not “add a chatbot.” It is to reduce repetitive work, improve response speed, reduce labour costs, and reduce the owner’s dependence on constant monitoring.

The first version should be an internal customer-service copilot:

1. Receive a customer question
2. Retrieve relevant product and policy information
3. Generate a suggested reply
4. Let a human approve or edit it
5. Record corrections and edge cases

Full automation should come later, and only for reliable, repetitive questions. The main difficulties are incomplete product data, changing store policies, edge cases, marketplace messaging APIs, orders and logistics access, multilingual communication, incorrect answers about safety, refunds, or delivery, escalation, monitoring, and responsibility for customer harm or lost sales.

Platform integration must be validated early. A technically capable system is not useful if the marketplaces do not permit reliable access to messages and order information.

The product could grow from reply suggestions into a knowledge base, partial automatic replies, order and logistics integration, a multi-platform customer-service system, and eventually a productised service or vertical SaaS for cross-border sellers.

The measurable signals would be the percentage of messages handled automatically, average response time, employee hours, owner involvement, correction rate, escalation rate, customer satisfaction, conversion, and refunds. This is a much more grounded path than starting with a generic AI assistant.

Option 5: Digital materials and printable products

This idea did not come from one identified customer. It comes from observing an established marketplace model:

• Create a digital product once
• Sell it repeatedly
• Deliver the file automatically
• Avoid inventory and physical fulfilment
• Build a catalogue that may compound over time

Possible products include printable pictures, colouring pages, board games, activity packs, educational cards, and customised digital products. The proposed route is to validate demand on an existing marketplace and move only successful products to an independent website later.

This is one of the best options for practising structured market validation. The initial cost is low, failed experiments are inexpensive, and products can be launched quickly. But the question is not whether digital printables sell in general. They clearly do. The question is which specific buyer, use case, keyword, and format can attract demand relative to competition.

The main business problem is commoditisation. AI has made illustrations, colouring pages, decorative graphics, and basic printable assets easy to produce. Competition is high, prices can be low, products are easy to imitate, free alternatives are common, and generic designs have little defensibility. The moat is unlikely to come from image generation itself.

Stronger differentiation could come from:

• A specific audience
• A specific situation
• A clear outcome
• Tested game mechanics
• Educational value
• Bilingual content
• A coherent catalogue
• Personalisation
• Automated generation workflows

The weaker directions are generic wall art, generic AI pictures, and large bundles of random colouring pages. The stronger directions are printable board games, travel activity packs, educational games, classroom resources, bilingual learning cards, personalised event products, and customised children’s activities. These combine design with utility, structure, rules, or personal relevance.

The validation funnel should be measurable:

Search demand → listing impressions → clicks → purchases → reviews → repeat purchases → customisation requests

Each stage identifies a different problem. Positive signals would include meaningful search volume, weak or outdated top competitors, recent reviews and purchases, customers buying bundles, repeated customisation requests, search impressions converting into purchases, repeat buyers, better conversion for specialised products, and the ability to raise prices through customisation.

The long-term asset is not just the files. It is the catalogue, niche knowledge, marketplace ranking, customer history, reviews, production templates, brand, automated customisation system, and distribution. This is the strongest independent validation experiment, even though it offers weaker immediate cash flow than the friend’s business.

Option 6: Poker AI and the boundary of a legitimate product

An experienced software-engineer friend pointed out that I may have an unusual personal advantage in poker. I have around two years of experience, more than 1,000 hours of play, experience grinding online, and the ability to compete around NL50 when studying and playing seriously. I also have strong software and backend skills.

The suggestion was to train an AI bot that could play microstakes online poker profitably. My initial view was that a strong bot might beat some regular NL5 or NL10 games before rake, but building and operating such a system would be difficult.

The bigger problem is that secretly playing real-money games against other players is not a sound business direction. Major poker platforms prohibit automated play and real-time decision assistance. A live bot would create account-ban risk, fund-confiscation risk, ethical problems, platform-policy violations, difficulty marketing the product openly, and no durable or legitimate customer relationship.

Even the technical hypothesis is uncertain. The system might fail to beat the real player pool, lose its edge after rake, confuse variance with skill, fail to generalise beyond training conditions, or be detected and banned. A technically profitable strategy could still produce a negative business outcome after enforcement risk.

The legitimate product path is different:

Poker simulation engine → offline AI opponent → hand-history analysis → leak detection → personalised drills → microstakes coaching product

The possible niche would be practical training for NL2–NL25 players, focused on the largest money-losing leaks rather than complex solver output. Useful signals would be players paying for hand-history analysis, struggling with existing tools, wanting simpler leak detection, repeatedly training against an offline opponent, uploading large hand samples, or paying for personalised reports.

The personal advantage and technical learning value are real. The real-money bot is not a project I should build as a business.

The final decision is a portfolio, but not an equal split

The friend’s e-commerce business is the primary commitment because it combines:

• A paying customer
• A profitable existing business
• Direct access to the owner
• Strong trust
• Immediate cash flow
• Reusable commercial infrastructure
• Visibility into additional operational problems
• Possible referrals from the owner’s network
• A path toward customer-service automation

The website should be the first defined paid delivery. At the same time, I can study the business as a source of future product opportunities around customer service, product information, cross-platform operations, and automation.

Digital materials should remain the secondary experiment. The initial goal is not to create many files. It is to validate one narrowly defined buyer and use case: research ten micro-niches, score demand and competition, choose two or three, launch a small collection, measure the funnel, and expand only around demonstrated demand.

The two projects complement each other:

• The friend’s business provides immediate revenue, customer access, real operational problems, trust, B2B experience, referral opportunities, and reusable e-commerce infrastructure.
• Digital materials provide full ownership, low-cost market testing, marketplace-distribution experience, a compounding catalogue, product and keyword validation, automated personalisation opportunities, and a path toward an independent brand.

The second project should not be selected mainly because it is technically interesting. The stronger questions are:

1. Can I access the buyer or user directly?
2. Is the need visible in current behaviour?
3. Has anyone already spent money or time solving it?
4. Can I test willingness to pay before building heavily?
5. Can I learn why buyers choose one solution over another?
6. Can the project create reusable assets?
7. Can it lead to future customers, distribution, or recurring revenue?
8. Is the downside limited if the hypothesis is wrong?

Based on the current evidence, the friend’s e-commerce business is the strongest primary project, while digital materials are the strongest independent validation experiment. The first should build cash flow, relationships, and commercial experience. The second should remain a tightly controlled way to build owned assets.