Make Mula: useful work, honest offers

Before you begin

• Portfolio capstone; inspect the worked fixture before beginning.
• A text editor/spreadsheet for the manual route. Hosted Python/Jupyter for code exercises; applicable dependencies are in requirements.txt.
• For actual AI calls, a legitimate available cloud service and authorised learner credentials; no particular provider or country is mandatory.

Free original, non-accredited practice. Self-review is not independent assessment. No particular provider, payment platform or country is mandatory; use a legitimate available route or explicitly labelled manual practice.

Find a problem through discovery

An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Ask three consenting potential users about their current workaround; keep simulations explicitly labelled. Inspect the supplied input before using any tool. Write the decision rules in your own words and calculate one small result independently. The reference output is an answer key for this deliberately bounded fixture, not proof of general capability. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. For learners across regions underserved or excluded by mainstream providers: verify country eligibility, language, account/identity requirements, data terms, cost, quota and connectivity before choosing a cloud service. Use only legitimate available alternatives; never bypass restrictions or invent a country/account. No service access? Complete the labelled manual/fixture route without claiming a live AI run. Project clinic: Discovery is listening before proposing automation. Ask about the most recent time the task occurred: what triggered it, who did it, how long it took, what went wrong and what the consequence was. Avoid leading questions such as 'Would you pay for my AI tool?' Ask permission to keep anonymous notes; do not record private documents or collect payment details. Three conversations reveal hypotheses, not a representative market.

Worked example

CONSTRUCTED DISCOVERY NOTE — NOT A REAL CUSTOMER
Role: owner of a fictional repair shop.
Recent task: copied five enquiry messages into a weekly job list.
Current workaround: paper notebook; owner checks every entry.
Problem hypothesis: duplicate transcription and missing appointment dates.
Unproven: willingness to pay, available budget, accessible payout route.
NEXT QUESTION: 'Can you describe the last time a missing date caused a problem?'

Your practical task

1. Ask three consenting potential users about their current workaround; keep simulations explicitly labelled.
2. Open input.json and expected.json from the practice pack; keep an unmodified original.
3. Record a manual prediction and the relevant rule before consulting the answer key.
4. Perform one small change and predict its effect before rerunning.
5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
6. Use the discovery guide in market-evidence.md for three permission-based conversations, or clearly label a rehearsal; separate exact observations from your interpretation.

Evidence to keep

• Find a problem through discovery — a saved, inspectable artefact tied to the supplied rule.
• A baseline or change-test record with expected/observed results and a limitation.

Mistakes to watch for

• Add a 10-unit refund: net becomes 15 and hourly return 3.75.
• Treating a supplied answer key, an authored example or self-review as independent field validation.

Check your understanding

Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?

No-service / offline route

Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.

Build and break one sample

An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Choose checked reports, approved replies, verified content or a tiny web tool. Establish a baseline before changing prompts or code. Keep the original input immutable. Record expected values, observed values and whether each comparison passed. If the expected file conflicts with a justified policy, investigate rather than forcing a convenient match. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Project clinic: Choose one lane, not a general AI agency: a checked report, approved reply pack, verified content pack or tiny web calculator. Write acceptance criteria before building. A report buyer might require totals that reconcile, visible rejected rows and a readable one-page explanation. Make the same sample manually first so speed and accuracy can be compared. A synthetic shop example remains a portfolio demonstration until a real buyer supplies authorised requirements.

Worked example

SAMPLE OFFER LANE — CHECKED WEEKLY REPORT
Input: a fictional three-row expense table; no private customer records.
Deliverables: unchanged source.csv, checked summary.csv, a one-page report and rejection log.
Acceptance: category subtotals equal the grand total; unsupported causes are omitted.
CHANGE TEST: add one valid row; the total and narrative must both update.
NOT CLAIMED: a real customer, saved labour or earned revenue.

Your practical task

1. Choose checked reports, approved replies, verified content or a tiny web tool.
2. Open input.json and expected.json from the practice pack; keep an unmodified original.
3. Record expected and observed values separately; explain every mismatch.
4. Perform one small change and predict its effect before rerunning.
5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
6. Select an existing Open Practice report, replies, editing or web project; create the deliverables and write three buyer-readable acceptance criteria.

Evidence to keep

• Build and break one sample — a saved, inspectable artefact tied to the supplied rule.
• A baseline or change-test record with expected/observed results and a limitation.

Mistakes to watch for

• No paid order obtained: record zero earned income, not the hypothetical price.
• Treating a supplied answer key, an authored example or self-review as independent field validation.

Check your understanding

Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?

No-service / offline route

Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.

Price the full workflow

An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Include selling and support time, fees, rework and refund assumptions. Build one inspectable transformation or bounded AI prompt. Keep calculation and validation deterministic where possible. If you make a permitted hosted call, save the actual response separately from the authored examples and verify its material claims; the supplied reference never simulates a live model. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Project clinic: Pricing is a hypothesis, not a number copied from an income guide. In the fixture, a price of 30 minus tool cost 3 and fees 2 leaves 25 before tax. Four hours include two delivering, one selling and one supporting, so the effective return is 6.25 per hour before tax. Equipment, connectivity, foreign-exchange charges and additional rework may reduce it further. A refund of 10 leaves 15 and changes the return to 3.75. If no one pays, earned income is zero.

Worked example

HYPOTHETICAL ECONOMICS — GENERIC CURRENCY UNITS
Price: 30; tools: 3; transaction fees: 2.
Net before tax: 30 - 3 - 2 = 25.
Time: delivery 2h + selling 1h + support 1h = 4h.
Effective hourly return before tax: 25 / 4 = 6.25.
Refund scenario: (25 - 10) / 4 = 3.75.
These are assumptions to test, not a quoted market price or earnings result.

Your practical task

1. Include selling and support time, fees, rework and refund assumptions.
2. Open hosted-lab.ipynb and the reference code from the practice pack; keep an unmodified original.
3. Record expected and observed values separately; explain every mismatch.
4. Perform A marketplace unavailable in the learner region is a stop condition until a legitimate route is verified.
5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
6. Run the supplied cost fixture, then add your own clearly labelled cost assumptions and one refund/rework scenario; do not enter bank or identity documents.

Evidence to keep

• Price the full workflow — a saved, inspectable artefact tied to the supplied rule.
• A baseline or change-test record with expected/observed results and a limitation.

Mistakes to watch for

• A marketplace unavailable in the learner region is a stop condition until a legitimate route is verified.
• Treating a supplied answer key, an authored example or self-review as independent field validation.

Check your understanding

Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?

No-service / offline route

Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.

Check access and test the offer

An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Verify regional payout and identity rules, then use a small appropriate personalised approach with opt-outs. Change one assumption at a time and predict the result first. Retain the failure, the revision and the rerun evidence. A failure is useful information: hiding a bad output or editing a test target after seeing the answer destroys the value of the experiment. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Project clinic: Check access before accepting money: seller-country eligibility, supported receiving method, identity and business requirements, currencies, fees, payout timing and refund handling. Record the official source and date, not a guessed green tick. A locally agreed lawful payment route may be more practical than an unavailable global marketplace, but it still needs verification. Outreach must be appropriate, truthful and small enough to personalise. Mention a demonstration as a demonstration; never claim past clients or savings you have not established.

Worked example

ORIGINAL OUTREACH EXAMPLE — USE ONLY WHEN TRUE
Hello [name], I noticed [specific publicly visible task relevant to their work]. I made a small demonstration of [bounded deliverable] using fictional data. I do not know whether it fits your process. Would you be open to a brief look and a question about how you handle this now? No problem if not; I will not add you to a sequence.
BEFORE A PAID OFFER: verify the legitimate receiving route and agree scope.
LOG: permission, response, objection and next step—not assumed conversion rates.

Your practical task

1. Verify regional payout and identity rules, then use a small appropriate personalised approach with opt-outs.
2. Open failure-tests.md from the practice pack; keep an unmodified original.
3. Record expected and observed values separately; explain every mismatch.
4. Perform Add a 10-unit refund: net becomes 15 and hourly return 3.75.
5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
6. Complete access-check.csv using dated official sources; prepare one truthful personalised approach and record actual responses or an explicitly untested offer.

Evidence to keep

• Check access and test the offer — a saved, inspectable artefact tied to the supplied rule.
• A baseline or change-test record with expected/observed results and a limitation.

Mistakes to watch for

• Add a 10-unit refund: net becomes 15 and hourly return 3.75.
• Treating a supplied answer key, an authored example or self-review as independent field validation.

Check your understanding

Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?

No-service / offline route

Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.

Deliver ethically and hand over

An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Define scope, approvals, rights, revisions, accounting boundaries and support. Review what the fixture cannot establish. Explain who owns the decision, where human approval is needed and which access or professional constraints remain. Do not describe a small educational success as production readiness, certification, legal compliance or a guarantee. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. For learners across regions underserved or excluded by mainstream providers: verify country eligibility, language, account/identity requirements, data terms, cost, quota and connectivity before choosing a cloud service. Use only legitimate available alternatives; never bypass restrictions or invent a country/account. No service access? Complete the labelled manual/fixture route without claiming a live AI run. Supporting practice — Ethical records and professional boundaries: Keep revenue, costs, unpaid time and refunds separate. Preserve consent, client approval and conflicts of interest. Do not describe an educational price sheet as accounting, audit or tax advice. Applicable obligations depend on jurisdiction; involve a qualified professional when required. Add a dated cost ledger, confidentiality rule, conflict disclosure and a professional-review boundary. Project clinic: Delivery requires agreement on inputs, scope, acceptance, revisions, payment and maintenance. Ask permission before sending client data to any cloud service; a client saying 'use AI' is not a blanket data-processing agreement. Keep a private cost ledger and record refunds accurately. Use the offer template to exclude medical, legal, tax, investment, safety and employment decisions. Hand over an exportable result and explain which changes need fresh checking; do not lock a learner or buyer into an undisclosed subscription.

Worked example

SCOPE EXAMPLE — NOT A LEGAL CONTRACT
Included: one fictional CSV-to-summary demonstration, checked totals, README and one revision.
Excluded: bookkeeping, tax filing, live account access, autonomous messages and ongoing hosting.
Acceptance: source totals reconcile; rejected rows and limitations are visible.
Authority: buyer reviews before use; no external action without separate approval.
Support boundary: fix agreed defects for the stated period; new requirements are a new scope.
Use qualified local advice for actual contracts and obligations.

Your practical task

1. Define scope, approvals, rights, revisions, accounting boundaries and support.
2. Open README.md and your evidence log from the practice pack; keep an unmodified original.
3. Record the human decision owner, limitations and any untested service access.
4. Perform one small change and predict its effect before rerunning.
5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
6. Add a dated cost ledger, confidentiality rule, conflict disclosure and a professional-review boundary.
7. Complete offer-template.md and handoff-checklist.md; retain approvals, record conflicts and keep professional advice outside the offer.

Evidence to keep

• Deliver ethically and hand over — a saved, inspectable artefact tied to the supplied rule.
• A baseline or change-test record with expected/observed results and a limitation.
• Add a dated cost ledger, confidentiality rule, conflict disclosure and a professional-review boundary.

Mistakes to watch for

• No paid order obtained: record zero earned income, not the hypothetical price.
• Treating a supplied answer key, an authored example or self-review as independent field validation.

Check your understanding

Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?

No-service / offline route

Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.

Decide from actual evidence

An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Record acceptance, refunds and net return if a paid pilot occurred; otherwise report the real market-test result without invention. Deliver a reproducible bundle rather than a screenshot alone. Include inputs, rules, output, failure tests, a short README and residual limitations. Ask another person to follow the instructions if possible; self-review and actual external review must be labelled separately. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Project clinic: Decide from evidence rather than the excitement of a launch. Track conversations, relevant interest, offers, paid orders, accepted deliveries, refunds, costs and time as separate stages. A friend praising a demo is not a paid customer. A paid pilot is stronger evidence than an intention to buy, but one sale does not establish typical income or repeatable demand. If no buyer agrees, document the obstacle and choose a smaller test, a different problem or a stop decision. Completion rewards honest work and learning, not earning at any cost.

Worked example

CONSTRUCTED DECISION RECORD — NOT ACTUAL RESULTS
Conversations: 3; offer discussions: 1; paid orders: 0.
What is supported: one person agreed to discuss the problem.
What is NOT supported: demand at the proposed price, a repeatable sales channel or any earned income.
Decision: revise the sample around the observed missing-date problem and retest once.
If a real paid pilot occurs: log acceptance, refunds, actual costs and time with permission; redact identifying details.

Your practical task

1. Record acceptance, refunds and net return if a paid pilot occurred; otherwise report the real market-test result without invention.
2. Open README.md and your evidence log from the practice pack; keep an unmodified original.
3. Record the human decision owner, limitations and any untested service access.
4. Perform one small change and predict its effect before rerunning.
5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live.
6. Write continue/change/stop with evidence for and against; label real, constructed and untested evidence separately and record zero earned income when no payment occurred.

Evidence to keep

• Decide from actual evidence — a saved, inspectable artefact tied to the supplied rule.
• A baseline or change-test record with expected/observed results and a limitation.

Mistakes to watch for

• A marketplace unavailable in the learner region is a stop condition until a legitimate route is verified.
• Treating a supplied answer key, an authored example or self-review as independent field validation.

Check your understanding

Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested?

No-service / offline route

Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run.

Capstone self-review

Score each criterion 0 (missing), 1 (partial), or 2 (demonstrated). A self-review pass needs at least 8/10 and 2/2 on the critical safety/limits criterion. This is learner practice feedback, not verified assessment.

• Defined task and preserved input: Original input and the project policy are retained; the actual question is clear.
• Checked baseline: The supplied baseline reconciles field by field; unsupported live-run claims are absent.
• Three failure/change tests: All three specified changes have predictions, observed results and explanations.
• Repeatable handoff: Another person can follow the README; supporting practice evidence and unresolved limits are included.
• Safety, rights and access honesty — critical: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Regional access route is legitimate; credentials and private data are absent; manual/constructed work is clearly labelled.

Review questions

Practice files

• README.md
• access-check.csv
• evidence-log.csv
• expected.json
• failure-tests.md
• handoff-checklist.md
• hosted-lab.ipynb
• input.json
• lab_engine.py
• market-evidence.md
• offer-template.md
• reference.py
• requirements.txt

References and editorial limits

Original authored practice material; deterministic fixtures build-tested. Not independently expert-reviewed or learner-validated. Time estimates unvalidated.

• ILO Start and Improve Your Business

Browse all build paths → · Curriculum overview