Keys for a successful project:
Break off a piece of your application and work on building or improving that for a short time. Initially this should only be a few hours of work that both parties go over carefully before starting work on the next iteration. As you gain more trust, you can work in larger chunks, as long as communication is fluent. Regardless of trust, there should at least be some kind of demo and significant testing at least once per week. Note: do not start work on the next iteration until you have received payment for the previous one.
Attack Challenges Early
Identify technical or business challenges early on and try to address them right away. Prioritization is key. There is always a temptation to add many different features or ideas. Its critical to focus on the most important aspects of the system, and especially start to work on them early if they are difficult.
You may consider posting some information about payment in the project thread. That would include a reception of the code and working demo or iteration, an agreement for payment and amount, as well as the sending and receiving cryptocurrency address. This provides a public record of payment or non-payment which others can check. It could save someone from being scammed or taken advantage of in the future if there is a problem.
Remember, you must READ and FOLLOW the RULES as well as the ones on this page or you will be banned!
There is only one type of post allowed here, and four types of replies. Posts are specifications only, as described in the rules.
Replies must be either A) clarification requests (when there is ambiguity in the specification) or B) include links to demo applications or videos (read and follow the rules, see link above), C) acknowledgement of questions where the poster then updates the specification or D) replies recording an agreement to enter into a contract or publicly documenting aspects of the transaction such as code reception and payment for iterations (see Guidelines).
Once you have made a post, you may not attempt to make the programmer develop the application inside of the topic by requesting changes in the thread without first paying for the time spent developing the demo. If you see a good demo, you may contact the programmer as you like and hire/contract them. Once they have received payment for their time working on the demo then they can continue work (not before).
READ THE RULES in the link above and follow them or you will be banned.
The simple answer is that at the time I created the site, I needed to pick up another part-time client, so that I could continue studying and experimenting with my computer vision during the other part of the week.
And by far the easiest way for me to get a contract over the years has been to find a specification and create a demo. But the freelancing sites that have specifications can be quite horrible.
The biggest issue is that they lock you into a very hefty ongoing fee for the privilege of using their site. This easily adds up to thousands of dollars.
Another problem is that specifications and bids do not have very many constraints, and tend to be fairly low quality. There is not a serious effort to ensure that the project postings make sense, or that the programmers have even necessarily read the project description. This means that there is quite a bit of noise that must be filtered through and a fair amount of risk for both parties.
Then there is the issue that this third party controls all access to your money.
This site is run by volunteer moderators and does not charge a fee. By requiring a useful specification and demo, risk is significantly reduced. We also require full names, email addresses, face photos, and have a section for honest testimonials. The testimonials section does not break down to a simple star rating, but rather encourages people to provide details about the interactions.
READ AND STUDY THIS ENTIRE PAGE CAREFULLY. IF IT BECOMES APPARENT THAT YOU MISSED ONE OF THE POINTS BELOW, YOU WILL BE ENTHUSIASTICALLY BANNED AND/OR POST(S) DELETED.
This message board connects people with software development requirements to programmers who can implement them. It is free of charge and run by volunteer moderators.
You must provide a valid email address, your full name, a picture of your face, and a detailed background, or your registration will not be approved.
For programmers, this includes experience, skills, websites, etc. If you are part of a team rather than working entirely on your own here, you must say so or be banned.
For employers, this means the name of the company, your position, whether its a startup, how you plan to use this site, whether you are part of a team or working on your own, etc. If you are a recruiter then you must say so here, so that your registration can be appropriately denied.
How it Works
- First, someone posts a partial requirements specification for their application. It does not need to be complete and professional, but it must list specific things that the program needs to do. More on what qualifies as a spec on this site is described below.
- Then, a programmer creates a reply with a link to a demo implementing some key part of that specification. It can be a video or, if it is safe to do so without key code being transferred, a live site or application. Rules for demos described below.
Ways to Get Banned (Or Not, if You Read and Follow These Rules):
If moderators suspect you have violated any of these rules you will be banned.
The absolute minimum payment for any demo work before receiving code or continuing work is $200. The absolute minimum cheapskate rate is $25/hour.
You must NOT attempt to spy on programmers' computer screens by requesting installation of software for that purpose or any other means. Use very short iterations (e.g., start with one or two hours of approved work, then maybe one or two days, etc.) until there is more trust.
Note: despite the name similarity, this is NOT a site for "spec work" (speculative). Programming projects only, not design (too easy to take without paying for it). Time spent on demo work must be payed for if that programmer is hired/contracted, and under no circumstances should any code be transferred without payment.
In addition, the demo development period should be a few hours or a few days in the extreme. Project posters must NOT expect a complete application or significant specification to be completed entirely as a "demo".
This is a bit of a grey area, but for example, any significant back-and-forth asking for changes before accepting a candidate and paying for demo work will likely result in a ban.
Once a programmer receives payment for a work period, he/she must deliver code immediately.
The absolute maximum iteration period is two weeks. Work must be delivered by that time (ideally through an existing source code repo owned by the one commissioning the work.) Payment must NOT be made without delivery of the current application code. Work must NOT continue until payment for that work period has been made.
Specifications for the project posting purposes must detail one or more key features or technical challenges that are actually important for your business or technical framework. The most critical thing for this stage is that the instructions are unambiguous and verifiable. So that the programmer does not have to guess what you want, and the demo program can be evaluated as to whether it meets those requests.
The expectation is that the programmer will help you evaluate your requirements and flesh them out over the course of multiple iterations. So the original specification is mainly a tool for reducing risk for both parties and finding a good match, rather than an attempt at completely designing the program up front. Part of reducing that risk is mentioning key technical challenges at the start.
Do not specify technology as requirements if it really isn't. For example, React is not a requirement for your website just because it is the only front end framework you have ever heard about.
You must specify if No Code tools are not permitted and why.
Demos are small prototype programs or websites that fulfill one or more of the features or technical challenges mentioned in a specification post. The safest way to do this is with a screencast or video of an application being used. Live demos are okay as long as some key parts of the source code are not available, such as backend code, or only a smaller portion of the specification is implemented.
Demos that are generic rather than addressing the specific requirements or technical challenges will result in a ban.
If you use a No Code or Low Code tool, you must indicate that you did so.
Transferring or exposing all of the code implementing a specification in a demo (i.e., giving the system away for free) will result in a ban.
Authorized moderators such as Jason Livesay (nbbadmin, the site creator) may post demos to try to win projects. (Its the #1 reason I am creating a free site like this.)