I thought I would try this here, as this site has been a fantastic place for answers so far! I’m interested to find out how people price up projects, as I’m currently having a problem with a client and the amount of designs/concepts we are doing.
So when you price up a project, do you give a fixed price and say you get 1 or 2 design concepts within this price? Then extra designs are so much each time?
Any examples of how you might spec up say a generic content managed site would be great too ;)
We look at the average complexity of the project and work out an hourly rate, then we estimate how long it will take and charge accordingly - so the client doesn't know about the hourly rate only a fixed amount.
This works well for both ends, the client doesn't have to worry about us going over budget if a problem comes up and if we do it quicker than our estimate we still get paid the fixed rate.
Regarding the hourly rate, it really depends on the project - for your example it would depend if we had to build a bespoke CMS or they already had one in mind.
at first, i give the customer a price range, based on estimated hours and our hourly rates ... if he is ok with that, i dive into details, doing a detailed plan and feature description, recalculating the price more exactly and seperating out parts/modules/features that i believe to be optional ... the most important thing is, that the customer gets all he wants and that you get paid for all you do ...
about estimating:
you should always take into account, that some problems might arise ... this fenomenon of course varies from task to task and you need to know very well, what how chances are ...
if you don't, take external manpower to do the job for you (don't force doing everything inhouse ... don't take responsibilities for things that exceed your competence ... also, you might find new potential employees) ...
always let those make the estimations, who will do the job ...
also, take in account, that people have different "estimation factors" (not sure this word makes complete sense in english ... by that i mean, that you DBA might always estimate 1.5 times as long as it takes him, and your CSS monkey maybe just half as long) ...
don't forget to plan a budget for communication and feedback loops ... talk about this to the customer ... explain him, that an hour of really thinking about what he wants and explaining that to you, will save you/your team many hours, which in the end is his money ...
if you still cannot plan a reliable estimation in some areas, discuss this with the customer and possible solutions ...
it is in everyones interest, that your estimation is good, because too much leeway will make your offer bad and chase away customers ... and a budget that is too tight is very vulnerable ... you wanna get paid for the work you deliver and your customer wants to pay for the work he gets delivered ... be fair and honest ... and don't hesitate telling your customer if the expect something to be far to cheap, but also be a good consultant and don't sell them stuff they don't need, or charge them too much ... that way, they will come back ...
greetz
back2dos
I just give a fixed amount, for the reasons that Tjkoopa lined out. The trick is getting the estimation part right. That means that you need to measure how much work you put into every website you built. Joel Spolsky has a great article on evidence based scheduling. Only if you can estimate how much time you are going to spend on a project can you quote a fixed price to your customers.
I've found for smaller sized businesses, or maybe even the mom and pop type folks that want to get their small little project up on the web, a fixed "package" price works great. I lay out for them that they'll have up to X amount of pages, some basic database work (if needed), and some basic shopping cart/forum/blog setup done for them in this package. I typically provide two different design options for them to choose from. If they want to out beyond these items, then I start applying hourly rates based on the work.
More importantly, I also indicate the service available. They get free basic maintenance (simple page added, spelling corrections, not content block to the basic page) on the site as long as they are with me. There are plenty of outfits out there that will do things for a decent chunk less than what I'll charge, but they won't get the updates, they won't get the customized design decisions, and most importantly, they won't get the personal attention to their site they would want.
Those kind of features help justify a slightly higher price, and the fixed price allows the customer to not guess how much they are going to have to pay, which may make them try and nickel and dime your time away. You give them a solid product, at a solid price, and they can feel confident in that.
Related
How do I go about explaining that I am a "Web Application Developer" and not a "Web Site Designer" to prospective clients - without talking myself out of the project?!
Often I am approached to "design a web site" for someone where it turns out to be more of a "brochureware" presentation site and less of a real web application.
While I am a highly skilled developer, I am not a graphic artist. That said, I would still like to be able to close deals with prospects without disqualifying myself. Simply stating, "I do backend work, not frontend" will quickly end the conversation, and along with it my opportunity for work.
Sure, I can just subcontract the project to a real designer and mark up his rate, but I would rather be up front with the client that I am not going to be the guy doing the actual work and they would be paying $120/hr for $60/hr work.
...and then they will ask price - is visual design often quoted hourly like app dev is, or will I get sucked into the oblivion that is fixed fees?
First thought: You sound like you're a good developer, which is a great foundation in this situation because people feel that we have a broad understanding of technology -- and they're right! You're correct in your insecurity though - a good developer is not exactly what they're after.
They want a solution, and if you can become the guy who knows how to navigate all the complexities involved in delivering that solution... Well, then you're the guy. And you're much more valuable.
And you don't have to stop coding, either. Which has always been my phobia.
So that's more or less how I present myself to my clients. I'm a developer, but I'm also a competent project manager. I know how to take your project from here to done even though it may involve designers, IT guys, additional developers, datacenters, etc.
Working with other professionals: You probably aren't in a position to hire folks. That's fine, but find good partners, and you can market your self as a shop or consulting group that is good at more than one thing. Believe me, people will appreciate that! For instance, we have a fantastic partner in Romania that we use for a lot of design, and we add value because we know how to get results from them and handle all the communication and so on. My customers don't want to talk to 3 to 6 people, they want a single point of contact who is accountable for all of it.
One thought here: try to find people who do this full time. Moonlighters and people doing side jobs have constantly let me down. I sympathize; I know what it's like to be spread too thin.
Fixed prices: You will probably have to deal with fixed prices, and you will need to hold your partners to fixed prices (or have some other mechanismf or controlling costs) if that's the case. Once the relationship becomes more comfortable, I usually try to give clients a range of what I think a job will take -- 5 to 8 hours, etc. And I let them know that fixed prices are a little bad for them because I have to assume some risk, which means they get charged more.
Most companies still want actual fixed prices for larger projects though and many large companies are shockingly comfortable with being overcharged in this situation. Fixed prices seems to be unfortunate fact of life in the contract development space.
First of all, I think you're exaggerating a bit - you don't really want to have a $30/hour designer working on a $150/hour website. If you do, and your client doesn't notice a difference, they deserve what they get.
And if we're talking about, say, $60 - $75/hour range vs $150/hour (which, IMO, is more realistic), you have to count in the time you spend working with said designer, so it's not like remaining $75-$90 goes directly into your pocked with you doing nothing.
If I am a client, I want a FINISHED PRODUCT and I'm paying YOU to deliver. Consider yourself a general contractor. I DON'T WANT to deal with designer / tester / technical writer / what have you myself - that's what I'm paying you for. My time may be a lot more valuable to me than $90 / hour difference. I may (will) get a second / third / fourth bid if I think you're too expensive.
That said, if you need to placate your conscience you can always bill couple hours less.
I tend to say something along the lines of "My job is to develop the stuff you don't see, but that make your site work"... And that is actually quite true.
... And you might add something that says that building a website is an activity that requires several very different abilities, like :
creating something that looks nice, and is usable ; that's a job on its own ; do your client have designed to logo of their company ?
integrating this nice looking thing into a dynamic application ; that one is your/my job ^^ Your clients send/receive e-mails every day, but do they know how it works ?
administration of the hardware / server : your clients use a computer every day to go in the Internet, use Word/Excel and the like, but do they know how to install those ? How to secure their network ? How to deal with security alerts the right way ?
You can use analogies with other processes ; designing / building / using / repairing a car, for instance ; some people understand better when we just don't speak about computers at all...
The way I always try and explained it, since I'm a Developer not a Designer is.
Developer -> Makes it work.
Designer -> Makes it pretty.
Of course there are vest generalizations, but for the most part they're true.
-> Developers creates the product
-> Designers create the package
Do you bill enough hours that you could consider hiring a program manager/product owner type person at least part time to do most of your customer interaction? Because if you do, you can abstract the "design/code" questions away from the customer; let the program manager really focus on figuring out what the customer wants built.
It sounds like your average customer isn't that technically savvy. If that's the case, figure out a way to speak their language (which most experienced program managers can do). They really don't care about the difference between a designer, a developer, and a tooth fairy that shows up and delivers the site that they want.
It's also worth considering whether you really want to take on projects that are mostly web design. If not, you should work on improving your marketing materials to focus on what you do best (interactive line of business web applications, or whatever).
You can steer the conversation toward what business problem the customer wants to solve, and propose the statement of work that best matches their objective. I think this will do the most good, and then it's never a question of misleading them. It's about packaging up a solution that matches what they want.
"I do backend work, not frontend" will quickly end the conversation, and along with it my opportunity for work.
This is not necessarily a bad thing. It's generally a good idea to be honest with prospective clients, and if they do not understand exactly what your job entails up front, then they may end up expecting too much from you when the job is done, or for future projects.
If you do really want to push your services on them, you could always try to point out exactly what kinds of benefits you will be offering to them. Make a point in explaining how much value can be added to the end-product by using your expertise.
A car may look great on the store floor, but if its powered by a lawn mower engine held down with duct tape and chewing gum, the only thing it's going to be doing is looking pretty and collecting dust in your garage.
I'm working in a small development group. We are building and improving our product.
Half a year ago we couldn't think about higher characteristics, such as usability, because we had so many problems with our product. Many bugs, high technical debt, low performance and other problems kept us from being able to focus on usability.
With time we've improved our process substantially. What we've done:
Real Agile iterations
Continuous integration
Testing(unit-tests, functional Smoke tests, performance)
Code quality is 'good'
Painless deployment process
So we are now producing stable, reliable releases. The following quote (paraphrased) describes our current situation:
first - make it work; after that, make it reliable; after that, make it usable
We are geeks, so we can't 'make' a great UI by ourselves.
So what should we do? What direction can you recommend?
Maybe we should hire Usability experts part-time or full-time?
How can we explain the importance of Usability to our stakeholders?
How do we convince them that this is useful?
What do your Business people say will make you the most money? Do that. Maybe usability is the next thing to do, maybe more features, maybe a different product. It's not something a "geek" will necessarily be able to guess.
I'm in the same boat as you are - I basically live on the command line, and I'm completely out of touch with the modern UI (both web and desktop application).
The solution for me was using a real UI developer for all my GUIs, and I just live in the back-end as it were.
There are quite a few benefits of this arrangement:
You don't have to debug your own crappy UIs anymore :) that's their job, and they're better at it than you, so no worries.
Your code will naturally gravitate to a MVC or at least tiered API approach, which is easier to code against for all parties involved.
Good UI people know what questions to ask end users, and know when those users don't know what they're talking about. I certainly don't have that skill.
You can do what you do best, and they do what they do best, making a stronger team overall.
The cons are obvious - you need to not only find the money for a talented UI dev, but you need to find a talented UI dev!
Now, I can't speak for you and your company's position in your market etc etc (I also don't do buisnessspeak :) ) but if you can afford another hire, it will give back more to the team than the cost of the position. It did for me!
You ask, "How can we explain the importance of Usability to our stakeholders?" but I'm not sure that you yourselves get it!
Interaction design (iD) and usability aren't things that you can tack on to an existing products when the "important" things are done. They should be there from the very first start, preferably done in small iterations with small tests and studies. I'm talking about cheap and dirty iD/usability, stuff like lo-fi prototyping, user testing with just four people, having enough stats to be able to detect user errors and such.
If you don't to iD/usability from the start, you risk ending up with the same crappy product as your competitors and/or providing users with band aids when they need surgery.
What do your users want ? They're probably the people best placed to identify requirements.
You are the ones who know and understand the product, so don't assume that just because someone else has 'usability expert' in their title that hiring them will somehow make your product usable.
Also, don't undercut your own instincts for usability. As a programmer, you use software all the time, what products do find the most usable? Think about what you like about them and compare them to your product.
Think about what your product does, and imagine that you are the person having to use the product and imagine how you would want it to work. Think of what a user wants to accomplish using your product, and imagine the steps they would have to go through to do it. Does it seem easy to understand what to do? Can it be done in fewer steps?
Most importantly, talk to your customers. Find out what they found confusing or difficult to accomplish. See if they have come up with their own workarounds for using your product in ways you didn't initially picture.
If you put as much thought, planning and effort into usability as you did into improving the reliability and deployment, you will end up with a much better product.
When analyzing the next step it really all comes down to business requirements & goals.
What is upper management like? Are they tech-savy? Are they open to new ideas? Do they think that the current product needs adjustment, improvement, etc? Is the product still in high demand? Is the marketplace changing such that the product/service will soon be obsolete? etc. etc. etc.
IF there are real business reasons for spending the $/time/resources then you can begin to explore product improvements. At that point consider the opinions of previous posters regarding user opinion.
I know so many geeks including myself who know usability, so one way would be learning it. Another way bringing someone in who can do UI design and usability.
To convince them that usability is important:
It's useless if you can't use it!
I don't know what sort of product you build but you always got clients, and clients always love usable applications. This will increase sales, happy client count and decrease tech support.
What does it do for your users? What do they think about the usability? Maybe it's not an ssue for them.
Make it more valueable to your users. Deliver more business value. Help your customers getter a better return on their investment. Do this by making it do more of what they need it to do, to do it better (more accurately, more quickly, more reliably more useably), or to do it at lower cost (less infrastructure needed to run it, reduced maintenance costs because you improved reliability), more flexibly (deals with their business changes)...
Lots of dimensions which do connect with the technical ones you refer to (usability reliabilty stability etc). But paying customers normally care about their business needs/features, not your technical ones that deliver them.
Go talk to your users (or potential users)
My one-liner about the importance of usability:
What use is a reliable system that is not usable?
If you have an existing product with existing users, then what makes you think that your current UI is not usable?
Do you suspect that there are some minor changes you can make that will greatly improve usability or is something more revolutionary required? If the latter, then what about the needs of your existing users, will they be willing to re-learn a whole new UI?
Edit
A user interface can be considered "poor" for a variety of reasons...
It is just plain ugly / old fashioned / does not "look like a Windows application"
It uses metaphors or workflows which do not relate to things that the user understands or wants to do
The first of these is relatively easy to fix, especially if you hire in a great designer. The fix would be the equivalent of redecorating your lounge and buying a new sofa and TV. Same room, different experience. Your existing users would still be able to use this application.
Fixing the second of these gets a lot more complex and involved, and might really impact your codebase. It's hard to comment further without knowing more about your application.
I think the answer is in the order of things, you say its:
"first - make it work; after that, make it reliable; after that, make it usable"
But the most important thing here is "make it work". Acceptance criteria for a functionality to "work" is that it is in fact - usable. If not, it will not be executed. Then it's just a block of dead code. And dead code should not be in the system in the first place.
Make a UI.
Then throw that away, and make another after you tried to use the first one. Then simplify as much as you can. Any time you can programmatically determine what the user wants from inputs, instead of multiple explicit choices, do so. Too many buttons induces paralysis.
In my very short time working in the programming field, I've seen two extremes:
Projects where little to no planning was done and thus become maintenence nightmares.
Projects that are perpetually in the planning stages and don't move from there.
It seems like the latter oftentimes happen as a reaction to the former. Where is the happy medium? And more importantly, if a project is moving in one of these directions, what is the best way to move it towards said happy medium?
In my own personal experience, I have found that 'decisions' are my bottle neck.
If this is the case, then :
List all your design options
Pick an option(s) (pick a few if you can't decide on one)
List the risks of the best option(s)
For each risk, brainstorm a solution, then design a conclusive proof of concept and write it.
If your proof of concepts proves it will NOT work, then toss that option, and pick another one.
A 'Proof Of Concept' is a minimal app to prove something. (mine are usually 1-6hrs)
If you have a situation where 2 or more options are equal, give yourself a time limit (like 5 minutes, not 2 months) and make a decision ... any decision, and don't look back.
And trust yourself to be able to deal with any problems you will hit which you did not take into account at design time.
Initial planning should be roughly O(log n) where n is expected total development time.
If you have to push in a week, sketch something on a napkin.
If you have a month, the first day is for initial design.
If you have a year, spend a week.
This does assume that you revisit planning iteratively, and don't just go all commando-style on your codebase, without adult supervision :-).
Analysis paralysis can have many symptoms. One that I have noticed is that same questions are asked each meeting and no resolution is reached. If you can point this out to people that might be able to help them admit that the planning process is stagnating.
If you can, at the start of the project, state that you want to cover a certain percentage of the requirements in the planning stage, say like 80-90%. This way there is a clear goal and you aren't trying for perfection. You can revisit the planning and analysis later just don't let it hold things up.
I think it depends on 2 factors:
The length of the project
Is it a 1 week project?
Is it a 1 year project?
Or somewhere in between?
The risk of the changes being introduced in the project
Are they architectural in nature, potentially affecting a lot of the original code?
Or are you simply adding a new feature?
Obviously, it's a combination of the above 2 factors. It simply doesn't make sense to spend 1 month designing a feature which will take 2 days to implement and is of little risk to the architecture. I'm picturing a matrix here of length/risk/design time tradeoffs.
There was some interesting advice in Code Complete 2, which I am currently in the process of reading. I can't remember the exact wording, so I am paraphrasing here, but it said something along the lines of:
The 2 biggest mistakes you can make in a design are:
1. Attemping to design EVERYTHING (you will fail)
2. Designing NOTHING before implementation
Finding the happy medium between these 2 is the key to successful design and planning.
Great questions - with no absolute answer - this is what makes experience meaningful. Experience including:
how much detail can you actually get from any user/sponsor and from this specific group
how much detail does your current team need (technical/business specific skill levels)
how open are your sponsors/users in helping during the development (how agile of a team do you have - does it include the sponsor/user?)
how good are you are identifying gaps
A big factor is the system being developed - the more 'life' critical the more details you will need (heart monitor compared to a web page).
The more complex, cost/time constrained, life-critical the more up front work - the less the more you can detail out as you do the work (prototype to production)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have my moments of inspiration like many others -- most of them bad, with a few diamonds in the rough. Is it possible to monetize those diamonds with stakeholders or entrepreneurs without actually being the person to handle development and technical? Any avenues that you can recommend would be appreciated.
Yes it's possible but also you should consider this:
From Getting Real
Awful idea = -1
Weak idea = 1
So-so idea = 5
Good idea = 10
Great idea = 15
Brilliant idea = 20
No execution = $1
Weak execution = $1000
So-so execution = $10,000
Good execution = $100,000
Great execution = $1,000,000
Brilliant execution = $10,000,000
To make a business, you need to
multiply the two.
The most brilliant idea, with no
execution, is worth $20. The most
brilliant idea takes great execution
to be worth $20,000,000.
That's why I don't want to hear
people's ideas. I'm not interested
until I see their execution.
However I think it's possible make a draft and show it off to seal a deal.
It's possible, but consider this: how much value is there really in an undeveloped idea? You're not the only one out there with great ideas you can't implement.
Having said that, if you really think it's new and original, you might as well use the broken system to your advantage and look into patenting it.
Ideas are a dime a dozen.
Getting them out the door is where the real work is.
There's a lot more to a new product than just an idea and software development. Frankly, these are two of the easiest parts. Marketing your product and getting people to actually buy it - that's the hard part!
Depends on the nature of the idea, but if all you have is an idea, but no work, you're unlikely to find a buyer who will pay you a decent amount.
No.
Everyone has ideas. They are a dime a dozen. Less than a dime a dozen.
Ideas without implementation are wothless. You can neither get, nor deserve, any money without anybody doing any work.
Start a business, get a business loan to fund your business early on. Pay people to work for you developing said idea. Once you have early prototypes then you can start looking for outside funding and try to make returns on your initial investments.
It is possible to sell an undeveloped idea but probably almost impossible to protect it. Consider this, no matter what you do competitors are watching for quick solutions.
The only real means of protecting a niche in a market is to be the best at it, to gaurentee that a replication of your product will be a waste of money, because it will pale in comparison, due to your head start in developing the product.
In short if you can't be the best at your idea, it will be replicated and you'll be outcompeted.
Therefore,
If, and only if, you're convincing (or crazy) enough to find someone who can competitively produce your idea will you be able to monetize the idea.
In general I would say no. Investors will at least want to see a prototype.
If your idea is amenable and you are willing to do some work, you may be able to take your idea and sell it as a consulting engagement to a company. You can structure the agreement to keep the rights to your software. I've worked on a project like this before.
Of course, you could always build a time machine and travel back to 1995 where you could sell ideas without having anything built.
You said that you have potentially money-making ideas, in moments of inspiration, and that most of them are bad. I suspect most of us are like that.
How do you tell which ideas are bad and which are good? It's usually impossible to do so without trying them out. If you're willing to go out and work on one, you're at least showing that you have confidence in that one. If you aren't willing to, why am I to have confidence in your idea? Give me some reason to believe somebody (perhaps you) thinks it a good idea. (Alternatively, you could try patenting it, which last I heard cost about ten thousand dollars or more in the US, but that could also turn me against the idea.)
How do you handle a situation where I might have had the same idea, and for whatever reason didn't pursue it? I'm not interested in giving you money if I implement an idea I came up with independently. If you tell me the idea, I can always (honestly or otherwise) claim I had it also. I'm not interested in signing anything that restricts my actions in the future (like the ability to profit off an enterprise without cutting you in) unless I get something for it. I'm also not interested in putting myself in the crosshairs of a lawsuit if I start a business and you think it was from your idea. I have no business reason to listen to your idea unless I already have some confidence it will be profitable to me, and for that see the paragraph above.
Ideas come to everybody. I have ideas. You have ideas. Why should I pick an idea that gives you a cut of the profits, when I can pick an idea I had myself? Sure, I probably overestimate the value of my own ideas, but you probably do also.
You see people making lots of money for no particularly good reason, an author cleaning up on a book that's not all that good, a financial analyst getting millions while bankrupting his company, that sort of thing. What you don't see is that those people put in a lot of time and work to get into that position, where they could profit unfairly. If you're willing to put in that effort, maybe you can get an undeserved profit too.
So, if you have an idea that could be worth millions, get a start on it. Don't try to profit from it without something to show, preferably something that shows off advantages without giving away the whole idea. That shows that one person, at least, has some confidence in the idea. It puts you out in front, if only slightly, and demonstrates that you're probably the logical person to keep going with the idea. It allows you to discuss possible ways to exploit it without giving away the whole thing. It allows me to save face; rather than admit that you have better ideas than mine, it allows me to finance you on the basis of something tangible. (Never expect somebody to pay you just for being smarter than they are. If you are, they won't want to admit it. If not, well, why should they pay you?)
I run a small software shop and over the last 20 years I've had dozens of people approach me with ideas. Most were users who were thrilled to simply see their ideas brought to fruition. Some were convinced, as you appear to be, that they had the "next big thing" and just needed a programmer to make it work. One guy actually sent me a "non-disclosure" agreement that would have, in essence, given him ownership of everything I developed in our field forever after signing the NDA. His "logic" was that his idea was so wonderful that anything I ever thought of after hearing it would be colored by his brilliance! Obviously, I threw it away and he faded into obscurity.
My take is that ideas are free, period. If you don't have the wherewithal or initiative to turn your idea into a real product, or even just a prototype, then you simply have no claim that anyone else need honor. My apologies if this sounds harsh but I've simply been at this too long to buy into the proposition that the people who do the actual work should owe anything to people who just free-associate.
If you do put in the effort to make the idea real, then you are owed the full protections of the copyright and patent laws to the extent that they apply.
First : You should discuss your idea with people you know who are good in that technical domain. They will tell you if 1. The product is worthy 2. There is nothing like it in the market already.
You could then try venture capitalists with your market analysis. There you might have to justify as in why you don't want to develop the product but want the money up front.
There are people who would buy the idea but the chances are slim if there is no prototype at least.
Genius is 99 percent perspiration and 1 percent inspiration.
-- Thomas Edison
If you don't have the time to develop your idea, you might have to be satisfied with giving it to others and watch it flourish. Or else, found a company, hire a CTO and CEO, and offload the implementation work. You might then have to be satisfied with only a small fraction of the company.
Professors give away their ideas to "student entrepreneurs" all the time, trying to get them to actively perform implementation work. The professors would co-found and then provide consultation to the company.
Yes, it is possible to sell idea/s. But before that just google it if your idea is already implemented or already stolen by someone else. Its a huge world with common thoughts. Every time google disappoints me by showing number of results of my (so called unique) ideas. But keep trying, you may be Genius.
Get yourself a sales guy that has no problem selling "vapourware".
Then when he's sold a version of it, code like mad to get it done.
Unethical, maybe, but if you can pull it off, it'll get a startup up and running nice and quickly.
How do you know it's a good idea? Evaluate your idea, assess the market it will play in, identify experts or talent that could implement the idea, create a rough marketing plan or launch plan, make some blue sky revenue guesses, and figure out the next smallest possible step towards realizing the idea (that is, plant your first milestone).
Now bounce all this around friends, and business people asking for evaluation. Take it to your local Small Business Developer Center and see if they have advisors that you can meet (most have some type of network of retired executives).
If (and it's a big if) you have the capability to implement the idea than yes, you might get angel round funding, a business loan or a team of excited volunteers willing to sweat for equity. That first milestone is key for some investors - "Fund me to this point and then we'll sit down and look at what we've got and re-evaluate and hopefully decide to continue funding."
Ideas are cheap. Implementation takes money, time and especially effort. And it's effort that is valuable.
If you just want to jot down your ideas and sell them, just write a book of ideas.
I would probably buy your idea if it would be so great.
For me ***the lack of idea is the issu***e, I would stand up for its execution (after its evaluation of course).
Not sealing a deal here, but startups would not be able to pay for the idea, instead they would be able to make you co-founder, stakeholder or similar when they will start implementing your idea.
I am throwing puzzle of my mind towards community leaders for some answers.
We friends decided to build products which already have some big names in the industry. Our motto is not to beat all those players (As we can't), but to develop basic product which is cost effective for some segment a customers.
What we are trying to achieve in first step is cheaper option, as we all knows product grow over the time period, not at once.
Now our catch-22 part-
Should we start building the product as there are already big names?
Price is a right option for USP (unique sale point).
As we all are dependent on jobs, what would be the best option to move forward.
As we also have some customers through verbal confirmation, should we go ahead?
What all major principles we should keep in mind during product development.
Please brain storm yourself on the definition of Product.
It's not just a CD that get shipped, but support, and trust.
Using this extended definition, if you can still beat existing
products, go for it.
Also, don't forget the amortized development cost of product has
probably been recovered by existing company already, so they can
reduce cost any day.
All said, don't let this analysis paralysis stop you ... go for it.
Big Names on the Market
I'm in the eve of such a startup, sometimes being small is a definitive advantage. If you believe you can use that not only price-wise but being agile, doing the core job maybe even better than the big names. If you up for that, I think you can easily infiltrate the market.
Job Dependency
Depends of what you do? If you are opening a next-digg or YACW2A (yet another cool web 2.0 application) then stay in your day job, because generally you can do both, especially if you got your friends with you. If it's a bigger scope you might want to stick with your day job until you got a almost there product.
Don't forget, also you can find an investor, sometimes it's best way to go. So you can just quit and still have a salary in your own job.
Verbal Confirmation
It's great that you already got couple of potential clients, now you need to look into and make a business plan. Understand your monthly cost including salaries, and see what percentage of it you can get out of these clients. If it's good then get some more certain answers from these clients and go ahead. If possible establish the company beforehand and get them buy the product. (one of your friends can do it, not all of you need to leave your day job straight away)
Product Development
Being the big market means do the core functionality perfect, it should just work, and it should be easier. Price by itself can not justify a buy unless you get the core functionality right. Ignore useless enterprise features, or any useless feature. You need to be aware that you got so much more limited resources than your competitors therefore 20/80 Rule (Pareto Principle) is for you. Do not try to satisfy 20% of the market by including crazy features, stick with 80%'s requirements. Big players can satisfy or can try to satisfy 100% of the market, if you try to do the same thing you gonna fail miserably.
Finally
Read Getting Real, Do not follow religiously but this book will give you good ideas and will explain advantages of being small.
You didn't mention, but I wanted to write. Make a proper agreement between you and your friends, ensure everything is in the paper before doing anything! I've seen so many similar startups fu*ked up before even start because of this.
If you think you can build a better product than the ones already on the market, sell it a fair price, and reach your target audience with a limited marketing budget. Absolutely, Go for it!
Our motto is not to beat all those players (As we can't)
First, change your motto. There isn't a product in existence that is perfect for everyone all of the time. There is always a niche to exploit. How can the current products be improved or simplified?
Second, don't focus on price. Customers expect to pay a fair price for a quality product, but they won't buy poor software at any price.
Well. Me and my fellows from our current company having the similar aims.
Here's few our ideas about it:
We are developing (web-based) product that we will use too. This is important for us and hope will help to improve our own performance in some areas and will give inspiration for new features.
We are going to develop product in stages. Not just sit and code silver bullet for industry. Going to start with core and minimal feature set.
Pricing. We are going to give options: use product on our hosting or purchase own copy and install it on own server. Additional and obivious things are different feature sets (technically -- different plugins integration).
Even more, think we'll make the core (as framework) and some plugins public. It'd be good (even neccesary in our case) to create community.
We already have few customers that would like to have highly customised versions of product. If this will have progress, we're going to focus on such activity and provide community with more and more free basic plugins.
That's just general ideas set. Hope you'll find some of them useful.
If by doing so you can satisfy your own requirements (e.g. for risk+cost-versus-reward)
You might want another USP as well: for example, ease-of-use
Work on this in your spare time, or have a part-time job
?
If you don't finish, or if customers don't want what you offer, then you don't get paid
Write up a proper business plan. Be sure to include critical risks and defensible barriers to entry. If no one on your team knows how to do that, then you can stop now as you don't have the right team in place yet.
The business plan is not just another marketing brochure that targets VC. Tell the truth. After you are done, turn it over to people you trust and ask for money. If they wouldn't invest in it, then why should you?
Have you identified a market for a reduced feature (and hence reduced price) product? It sounds like you have not.
Does your group have a passion for a particular product? It doesn't sound like you do. It might be difficult for everyone in your group to really inspired by just some program. Especially if you haven't done the market research.
I wouldn't count on the 'verbal confirmation' customers. Of course, it depends on the amount of money involved. The larger the price of the product, and the longer it takes you to make it really work, the less chance they will actually buy when you have it ready. Do you have reason to believe that there will be many more people that would be interested and would actually buy your product?
If you have enough market research, and a marketing plan, you may be able to get some venture capital, quit your current jobs, work on this full time, get paid, and hopefully make some big money when it goes big.
Best of luck.