Thank you for the thoughtful comments :) I really liked the paper, I'll have to read it in more detail, but yes, it definitely helps with the framing. At a hig

Thank you for the thoughtful comments :) I really liked the paper, I'll have to read it in more detail, but yes, it definitely helps with the framing. At a high level I want to achieve the speed and efficiency of microtasks, but for interesting and intellectually challenging tasks as the ones present in broadcast search - we'll see how it goes. On to your points: - Absolutely, I added a few instances of the demo Counter task to show more or less how it will look. I plan to add more variety of tasks soon. - Definitely, as I plan to make Interviewless useful enough so I can use it to build Interviewless itself, there will be a much greater variety of tasks: API connectors (stripe, GitHub), task allocation algorithms, UI/UX components... The python example was mostly to get something out the door quickly for now. - My idea was to show that a task has 2 sets of tests: one clearly visible to the freelancer (logs and all) and another one hidden (so it's harder to cheat). As you say, the risk is there could be gotchas (or more likely errors) on the hidden tests. I'm hoping I can solve this with a reputation based system on the client side, and only consistently good clients can have hidden code. - The max development time is the amount of time a freelancer has exclusivity over solving the task. I don't want the platform to feel like a constant race, but at the same time, there has to be a limit on how much time a freelancer can take on a task. Price is separate. The max price label was for a bidding system I was planning. I'll fix this and clarify these things soon on the page. - Do you mean when a client is posting a task or after the freelancer solves it? The latter could be cool but if have to see how to implement it. - :)