[tpm] So I've got an idea for a web site ..

[Stuart Watt]

Good question, Alex. Like Olaf, I've avoided this, but for me too it's also resulted in a a few successes, mostly with friends who would participate equally-ish (not necessarily as coders, but e.g., as UX and content providers), and share the contribution. That's probably the safest bet for work on spec, as without that, the sunk costs are very unequal. Anyway, here are a few things I'd be keen to know.

1. What are you trying build? Is this a prototype, good enough to get funding? Or is it intended to be a scalable system? How many users do they expect this version to handle, before the whole thing is re-engineered. Which it will be, several times. The reason I ask is that a lot of early design decisions, not least whether a standard-ish SQL server will suffice, depend entirely on this. That defines a lot of coding decisions. Also, if they want a complete system in spec, you're essentially sunk. They are always fifty times more effort than you would think, most of which is support, admin, deployment, and so on. 

2. What's the external integration? On one large-scale site I developed, we spent longer integrating with Paypal automated payments that we did on almost the whole of the rest of the system. If this is needed from day one, you need to know about it. Mostly so you can walk away if you're the only one contributing risk, but dividing the return. 

3. Who is doing user experience design and/or visual design? Anybody? If you have a very good generalist, you might stand a chance, but without it, you probably need to plan early acceptance testing. That is a useful purpose behind a mockup. 

4. What is the business plan? If the plan is "doing in Instagram", i.e., get a bunch of users with no revenue model and intend to sell out as soon as you get a decent offer, I'd walk away. Too much risk. If there really is a revenue model, you stand a chance of getting better people on board, and the risk is much less. 

5. If it all goes belly-up (fails to achieve an acceptable funding system), who gets the code. (Sounds awkward, but I've seen more serious disputes over code than anything else in my career).

In effect, if it's wire framing something up, it could be good. I've done it. It usually doesn't take more than a few days, so the sunk cost is not so high, and I usually ensure that I try something new so that I learn something in the process. In effect, I make it "self-training time" as well. If they're after a full site from the get go, you need funding. But the first can lead to the second, and it is possible to build long-lasting and successful collaborations this way.

All the best
Stuart



On 2012-12-18, at 7:21 AM, Alex Beamish wrote:

> Good day, Perlmongers,
> 
> A friend of mine who's a successful businessman approached me recently with an idea for a web site. He didn't say it was going to be the next Facebook, but he did mention that the concept drew on ideas from a few popular web sites, and that it would have elements of each of them. He's looking for someone to either do the work (labourer-for-hire) or to partner with him and build the web-site for sweat equity.
> 
> We discussed the construction of a web application (web pages, business logic, data store), and I explained you probably need either a generalist working by themselves, or an architect to design it, and a project manager who would hire the various specialists and co-ordinate the work. The problem, of course, is doing that much work on spec.
> 
> I'd be interested in hearing your views.
> 
> Alex
> 
> _______________________________________________
> toronto-pm mailing list
> toronto-pm at pm.org
> http://mail.pm.org/mailman/listinfo/toronto-pm