Derek Sivers

Programmer, writer, avid student of life. I make useful things, and share what I learn.

Projects → Muckwork

Management of remote assistants doing projects for clients. See the story in the Schema, below, to understand the process.

status: building


A client submits a project - something they need done. They have already made a payment so their account has a positive balance.

A manager breaks it into a TO-DO list: each step called a task. If it's a common project, the manager will pull up a template and copy each template_task into that project's tasks.

The manager shows the tasks and estimated cost to the client for approval. The client's balance needs to be enough to cover the project before we begin.

A worker, a person paid by the second for their time, is alerted when there are unassigned tasks to do. They claim them if they have time, which assigns the task.worker_id to theirs, and have to start or finish soon or else the tasks are unassigned and put back into the pool so that other workers can be alerted.

As the worker marks a task as finished, the total number of seconds spent on that task are multiplied by the worker's fee per-second, to create a charge, which is subtracted from the client's balance, and a worker_charge. These are separate because sometimes the client will be charged a flate rate for a task, and not billed by the second, but the worker still needs to get paid for their time.

When Muckwork pays the worker, we log a worker_payment, and the corresponding worker_charges are updated with its, to mark those worker_charges as paid.

All activity through PayPal is saved as a paypaltxn (“txn” = transaction) - usually corresponding to a payment_id.


The website has all of the functionality described above, plus the REST URLs. All URLs except home/login/signup require authentication.

The REST interface needs to have the full functionality of the site, because many clients will choose to assign and monitor projects from alternate interfaces like mobile apps. So consider all website pages as just views, with all real POST/PUT/DELETE action run through the REST interface.

On, each of the three roles of browser-users have a subdirectory: /c/ for client, /m/ for manager, /w/ for worker. When a person successfully logs in, they are sent to the appropriate subdirectory. This allows for uniformity of URLs, but with the appropriate views and permissions.

For the client, the site gives a full transparent window into the execution of their project and its tasks. They can see exact time worked, by who, and the worker's notes for each task. If emails are sent and received for a project by the worker or manager, both are saved in the database and viewable by the client. If phone calls are made for a project, the audio recording of the call is saved as an MP3 and attached to that project. The client can interrupt a project at any time, or add comments/questions for the manager or worker.

For the worker, the site is an efficient TO-DO list, with quick and easy communication with the manager, an easy email interface for sending and receiving emails for the project.

For the manager, a central dashboard shows the status of all projects and tasks, with clear visual feedback when a task is taking longer than it should. Very easy to send and receive emails to the worker and client regarding a project. A manager will spend most time turning incoming project requests into specific tasks, and ensuring that current projects are being done well.