Research

What Task4Task is working out.

An AI-powered marketplace for tasks raises questions that a listings board never has to answer, from how well AI understands a request to how skills should match work. These are the ones we are working on. They are questions, not results: findings will be published when there are findings.

Progress path: Question → Observation → Experiment → Finding → Product implication. Until a finding exists, the question stays open. Related notes appear in Updates and the Network.

Specified
Part of the current product specification. The question is how well it works.
Exploring
Being designed. Some of it is specified, the rest is not decided.
Open question
Not decided. No direction has been chosen.
  1. RQ-01

    AI

    Specified

    How much of a task can be understood from one request?

    Why it matters

    Most people don’t describe work the way a form wants it, and many would rather say it than type it. If the first step is a form, many requests never get made.

    What the product specifies

    Requests by voice or text, in English, Urdu or Roman Urdu. AI extracts them into structured fields that fill a seven-step task wizard, which autosaves. The person reviews the task, and AI reviews its content, before it is published.

    Still open

    • When should the AI assume, and when should it ask?
    • Which missing details matter most to the people who propose?
    • How to handle requests that switch between languages mid-sentence, as people often do.
    See AI review
  2. RQ-02

    Exchange

    Exploring

    How do two people agree that an exchange is fair, without money?

    Why it matters

    Skill exchange only works if both sides believe they got a fair deal. There is no price to compare.

    What the product specifies

    A barter contract names both deliverables side by side, and each side approves the work it receives.

    Still open

    • Can the size of a task (time, effort, skill) be made comparable across very different kinds of work?
    • Credits are not part of Task4Task. Could something like them let an exchange span more than two people? An open question, not a plan.
    • What should happen when one side delivers and the other doesn’t?
    See an exchange
  3. RQ-03

    Trust

    Specified

    What lets two strangers trust each other enough to meet?

    Why it matters

    Physical tasks mean opening your door to someone, or going to a stranger’s address. A rating alone is not enough.

    What the product specifies

    Identity verification, pre-hire chat, a contract both sides can see, messaging, live location during physical work, reviews after a job with separate hiring and working reputation, and disputes.

    Still open

    • Which of these signals actually change whether someone hires, or accepts?
    • How should a new worker, with no reviews yet, earn a first job?
    See the trust layers
  4. RQ-04

    Physical world

    Open question

    How much location should be shared, with whom, and for how long?

    Why it matters

    Live location makes physical work easier to coordinate and safer to agree to. Shared carelessly, it does the opposite.

    What the product specifies

    Directions open in Google Maps. Task4Task shares the worker’s live location with the hirer during physical execution, and the hirer confirms arrival.

    Still open

    • When exactly should sharing end? Not yet decided.
    • Should the hirer’s exact address be revealed before hiring, or only after?
    • What does a worker need to know about a place before accepting?
    See travel and arrival
  5. RQ-05

    Matching

    Specified

    When a task is urgent, who should hear about it first?

    Why it matters

    For a dead battery or a burst pipe, the best proposal is often the closest person who is free now, not the cheapest.

    What the product specifies

    Workers switch on Available Now. An urgent instant request notifies nearby workers who have it on, and the hirer can browse available workers nearby.

    Still open

    • How far should an urgent request reach, and should the radius grow if nobody answers?
    • How to keep Available Now accurate, so “available” means free right now.
    See an urgent request
  6. RQ-06

    Reputation

    Exploring

    Should someone’s reputation as a hirer count separately from their reputation as a worker?

    Why it matters

    The same person can be an excellent worker and a difficult hirer, or the reverse. One number would hide that.

    What the product specifies

    Reviews happen after a job, and Task4Task keeps hiring and working reputation separately.

    Still open

    • How to show both on one profile without confusing either audience.
    • In a skill exchange, each person is both. Which review goes where?
    See a review land
  7. RQ-07

    Disputes

    Open question

    How should a disagreement about the work be settled fairly?

    Why it matters

    Most disagreements are small and are solved with a change request. Some aren’t, and those decide whether people trust the marketplace.

    What the product specifies

    Change requests come first, against the contract. When the two sides can’t agree, a job can go to a dispute.

    Still open

    • What counts as evidence: the contract, the messages, the submitted work?
    • How is a dispute about a skill exchange settled, when no money changed hands?
  8. RQ-08

    AI

    Specified

    Can recommendations based on skills put the right tasks in front of the right people?

    Why it matters

    A worker shouldn’t have to search every listing, and a hirer’s task shouldn’t wait to be found. But a recommendation is only useful if it’s right.

    What the product specifies

    AI supports task recommendations and matching based on worker skills. Workers still choose what to propose on, and hirers still choose who to hire.

    Still open

    • Which signals besides skills should matching consider, such as area or availability?
    • How should a recommendation explain itself, so people can judge it?
    • How to recommend fairly to new workers who have no history yet.
    See recommended tasks
  9. RQ-09

    Systems

    Specified

    How do both sides always see the same state of a task?

    Why it matters

    If the hirer’s screen says “on the way” and the worker’s says “arrived”, trust breaks. Every state change has to reach both sides, reliably.

    What the product specifies

    Messaging and real-time updates keep both sides looking at the same task state as work progresses.

    Still open

    • Failure handling and performance are not yet documented.

Continue

From open questions to the product record.

Findings stay unpublished until they exist. For how the product is built as a company effort, see DevDevise.

The Task4Task record at DevDeviseInvestor view of open questionsChangelog