Non technical · Technical Architecture

Would you use the product to find your technical cofounder

kraig Into ICOs, fintech and saas

February 22nd, 2017

Problem. You can't find or judge someone yourself. people seem willing to give 'dev shops' a chance,even though that's not always the best and they don't know how to manage technical people.

people are worried that technical staff won't deliver (where do they come on the better/faster/cheaper axis)

technical people are interested, but can't always devote the time to the program(what happens if they get a full time job?) what if you don't pay?

How about a Developer API, which takes you from vague idea and manages you through the process of spEdina and finding your developer/cofounder and holds the payment and delivers as retainer/payment tied to ongoing development And support. So your developer knows you can provide the funds, and ycan have a regular income. While you know there is a refund in the event of a failure to deliver.

Adam Davis Embedded engineer with full stack experience

February 22nd, 2017

At its root this is a question about managing technical risk.

You choose a dev shop when you know exactly what you want, there's no (or very, very limited) iterative development, and you need to control costs and/or risk.

You choose a co-founder technical lead when you don't have funding to cover a full salary or a contractor, and you're willing to trade equity for results in a fast-paced, iterative development environment.

You choose a contractor when you need fast paced, iterative development, and have the funds to pay without giving up equity.

Within this ecosystem, I"m not sure what problem you're trying to solve that will actually be solved by your solution. If you know what you want and are only worried about actual delivery, then why not go with a dev shop? If you don't know exactly what you need, or the development needs to be nimble, then, by definition, none of the above can guarantee delivery. You're paying for their time, not a product or specific outcome. It's a path, not a product. And if it is a product, and not a path which might change, then you have no need for this solution, use a dev shop.

You should also make the escrow protect the developer - the development output (source code, design files, etc) should be withheld from the client, and then both the money and the design IP are released at the same time. This seems overly complicated, though, for processes many developers are already doing. For instance, many will accept deposits and regular payments based on milestones as the work progresses, and if the contract is terminated you keep what you have because work up until that point has been paid for, and the developer keeps the money that's been paid up until that point, for the work they've done. This reduces risk for both parties.

If you're suggesting, however, that a developer should work 100 hours on a project without pay, only the promise of pay showing up in an escrow, and then when the project is done you can say it meets your needs or it doesn't, and that determines whether the money goes to them or back to you - then there's little difference to paying them in full at the end. At best it provides knowledge that you have the money, but the biggest risk - whether you'll pay or not - is not solved.

If you could flesh out a few use cases and demonstrate the problem and how your solution would resolve it, perhaps I would better understand how it works and when it is most useful.

Thomas Sutrina Inventor at Retired Pursue Personal interrests and family

February 22nd, 2017

I worked of a development shop. Remember that their objective is to get paid so they will spend a portion and sometime a big portion on their objective, justifying. They also are very willing to go down blind holes. Not spend your money wisely. They will say that they are following your direction and justify it. Even while working for a fortune 500 company that is an OEM for aerospace components I experienced the same actions. An individual when hired will also do the same thing. So you will find yourself as the judge of their efforts and responsible for the tasks they address. The fact that you are not technical will not alter this.

So you do need a technical person capable of providing the leadership, is on your team, and has a stack in the outcome. That person will be a leader and making there own decisions for you but often independently. That can be a person fully employed elsewhere but having sufficient time to manage your needs. If you have the money to hire a development person or company then you can succeed with such a part time leader. So long as the people hired will not add cost for the schedule limits imposed by the full time employer.

kraig Into ICOs, fintech and saas

February 25th, 2017

OK, the ideas evolved a bit.

This is about managing risks for both sides of the equation

On cofounderslab discussions. There is no end of these I can't find a technical person. They over budget/under deliver threads.

Also the technical risk don't get paid etc.

So the ecosystem would address this.

1) It would be escrow in itself, combined with the rent-a-app approach. The developer would provide the source code/app to the ecosystem servers, which would also publish them to the app store. That way they can be turned off. As can the cash-flow. Obviously both parties need to trust the ecosystem for this to work


To overcome the perverse motivation for developers to low-ball their bids. The eco-system would use a 'double -blind' approach.

e.g. Lets say client posts their request, and gets four bids form four developers at $1000,$2000,$3000 and $4000 The ecosystem would prevent the client with four bids for $4000.

Now the client can't chose the cheapest option, so they are forced to look at some other measure to decide on the best developer. There is no reason for developers to low-ball their estimates. Since they can't tell which is the cheapest, they are only liking to hit a pared-to the bones low-balled Chinese sweat-shop-type by chance(or if they have a great salesperson) or really are the best for the job.