Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm building a shareware software that allows users to import various types of files (XML, CSV, etc.) into a database. I'd like to provide a trial version, but limit it in some way to prevent users that really need it, from not having to buy it ever.
I considered time based limit, but it seems that there are so many ways to work around that, especially today with virtual machines and stuff.
So, I'm thinking to limit the functionality, but I don't want this trial version to become crippleware.
Have you ever bought some shareware software? What was limitation of its trial version?
edit: Also, how do you feel about nag-screens as a user?
Look at this blog post, it's a survey made by Andy Brice on small software vendors. Here you can find the trial types and its % of use.
http://successfulsoftware.net/2009/04/23/the-truth-about-conversion-ratios-for-software/
I recommend you the Business Of Software Forum:
http://discuss.joelonsoftware.com/default.asp?biz
Regular posters there seem to agree that you don't have to think too much about piracy. People who won't buy won't buy anyway and complicated copy protection schemes run the risk of bothering the honest customers.
This is an excellent post by Patrick McKenzie about this issue:
http://www.kalzumeus.com/2006/09/05/everything-you-need-to-know-about-registration-systems/
Limit to number of uses is the fairest way.
As for stopping circumvention... Anyone who wants to crack your software will, and most people are too lazy to circumvent anything but the most trivial usage.
I'd argue that you want to get those people who regularly use your software to happily pay for it. They're most likely to happily pay for it if they've used it a non-trivial number of times.
b.t.w. Beyond compare has a system where you can use the software for 30 non-consecutive days. i.e. If you use it one day, and then use it 2 weeks later, then this will only count as two days. I've never been so happy to pay for software than when I paid for Beyond Compare.
Many people will only need this tool once in a lifetime for an import of some data.
So you will definitely have to go to a limited version instead of a time version.
It is common for software during the trial period to lack (or limit) some significant feature, such as printing or saving. I've tried (and bought) a panorama assembly tool that put a large watermark across the finished image. It allowed the quality of the tool to be evaluated, but put a real limit on further use of the images created during the evaluation period.
I've shipped a trial version of a commercial product that allowed all features to be used with limits generous enough to run through all of the tutorials in the user manual, but did not permit saving your work. We know that many users were able to quickly determine whether the tool would work for them by constructing tests with their own data, and it generated more than enough sales to justify the added development work to create the demo version.
The trick in your case will be to find a way to limit the functionality without eliminating the key utility of a trial period: actually trying out the software.
Perhaps limiting the number of records that can be converted in one run would do the trick?
I would definitely go with a time-based limit. As you mentioned, this usually is fairly easy to circumvent, but I promise you that if your software has a large enough user-base, cracks will be around in no time anyway. Thus there IMHO is no point in making it hard/impossible to pass by your software's time limit.
Any other limitations (such as annoying pop-ups or limited functionality) would definitely be a show-stopper for me. If I cannot evaluate the software properly, it has to be very good to make me consider buying it.
Please do not fall into the trap of limiting anything about the trial version other than time or number of uses. Reducing functionality and/or having annoying popups saying "This is a Pro feature" will simply alienate your users. Besides, the trial period is a chance for you to impress potential buyers, so you should showcase all of the features rather than hide them.
This is a marketing decision and the answer to any marketing decision is always "it depends...". For example it doesn't make much sense (commercially) to have a 30 day time limit on software that most users will probably only use once (e.g. harddisk recovery).
There are some issues association with time-limited trials:
A user might use it once and then not get chance to complete the trial
before the 30 days is up.
Time limitations are easy to work around, e.g. using VMs, registry
hacks, additionalmachines or
resetting the system clock.
Longer sales cycle - most customers will only buy on day 31.
Some of these are avoided if you go for a limited number of uses.
The main issue with feature limited trials is that the customer might not feel they can fully evaluate the system. But this isn't too much of a problem if you have a good money-back guarantee (and you should).
As a vendor I prefer feature limited trials in most cases. You can be quite creative in how you cripple the trial (watermarking, limited number of records input or output etc).
I just wanted to add that this is a strangely biased group. As programmers we want to be able to see all of the features, and play with them, etc. We get annoyed by certain limitations, and ads, etc.
However, normal people seem to react to these things differently. I'm just saying that we aren't really the target market here, probably.
ALSO, we should note that most people aren't nearly as good as we are at circumventing these things, so as has been mentioned, something pretty dumb is probably ok...
We have one product with a free - limited version, and a pro version, and another product with a 2 week free trial. Actually the free version also had a 2 week free trial of the pro, so it was sort of both...
All in all, I think it depends on the product and the people using it...
Limited number of uses
Ads
Splash screens that make you wait X seconds before it goes away
Not all functionality is available
Demo limited to a single database
Closing the gap was a very enlightening read when Eric first posted it, I believe it is equally relevant today.
You could limit the size of the import file supported. Or the number of uses. Or if insertion speed is a critical factor you could start out at full speed and then after 30 days add some delay (but be sure to tell your users this is intentional).
BTW, one of the worst schemes was in the Ingres database for Sun workstations 20-odd years ago. If you entered the wrong license key, Ingres silently enabled a dozen serious query processing errors. After playing with it for an afternoon, I told the salesman that his product was ridiculously buggy and that we'd be going with a competitor. He quickly told me what the issue was, but by then the sale was all but lost.
You can limit the number of times the users can use the functionality within a given time period; say they can use it 8 times in a month, before it throws up a "nag screen" when they use it. And if they need to use it more than, say, 20 times in a month, insist that they buy the software. If you do this, you may want to provide a certain number of keys for charitable purposes or educational purposes as well; it helps users to buy the software when they know that there are some charitable purposes their money is going to pay for.
I've purchased plenty of shareware but always tend to be annoyed when it disables certain features. I prefer to check all features before I make a purchase.
I do like the limitations that Altova add to their software. You always need a registration key to use their software and to get one, you have to provide your email address to which they will send you your temporary key. You can then use their software for up to a month and then you'll need a new key. Some people will just continue to request a new temporary license but most users will sooner or later purchase a permanent key.
The Altova software does make a "call home" to validate the key it uses. It does this to restrict the number of users that can use the software. I can install their product on as many computers as I like, but at any moment, I can only use it on a single computer. If I try to use the software on two or more systems at the same time, the software will discover this multiple usage and thus block my access to the application.
Still, I do know that many people are willing to pay for your software if it's good enough. Especially if you can provide some additional services next to the software itself. (E.g. regular updates or subscriptions to additional data feeds.)
No, I have never bought limited trial versions. However, I have donated to a couple of open source projects. If this were a software for people, instead of companies I would recommend a donation system.
This software sounds like a work-related app, so:
constant reminder, like Foxit
just 2 file formats
app married to a single database
Since this is a software to import data in a database, you could also add rows to the database indicating that the importation was made with a shareware version.
Just annoying enough (rows are still deletable), but you get most of the functionnalities.
How about keeping all the functionality in but randomly re-arranging the menu/buttons in the non-paid version ;)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
The context is as follows: Enterprise software developed without enough direct customer involvement. We did not develop this software for a particular customer but to fill in a market gap. We worked the core requirements with major customers only, more customers jump on now. Mandated deadlines, requirements changing, little time to design. Fun time! :)
We got the first release out of the door. Then we got second release out of the door (luckily in a more organized fashion)
Most problems that the sustaining engineering is facing for both releases are what they call 'design bugs' rather than good old code defects.
In general these 'design bugs' are such that a feature or part of a feature behaves as designed but that behavior is not what some customers want the product to do. It is not that all customers have these problems - each customer is different and what is enough for one is not for the other.
This makes me wonder about several things and I could really use an insight from y'all with more experience.
Here are some esoteric questions:
How much do you think is this a common phenomenon in product lifetime?
How much do you think did the context contribute to this?
What is/was your experience and context?
This is absolutely common that needs differ from client to client and that they want to drive the product in different directions.
There are three options for any given change:
1) You don't do it - they've bought product software, they have to live with the product. I wish Word did somethings different but I paid a couple of hundred pounds for it rather than having a bespoke word processor built from scratch so I have to live with it.
2) You branch the product and have two different versions - as often as not this is the worst thing to do. As a software house your model is dependent on many clients contributing to a common code base. Having multiple versions significantly increases costs (every bug fixed twice, two manuals, etc. etc.) and breaks your business model. Again, if they want bespoke software built exactly to their requirements then they need to pay for that - you don't get bespoke software at package prices.
3) Customisation (potentially as an option / module / configurable setting) - this can work but you really need to think about whether it's the right thing to do for your product. Each extra options massively increases the number of ways in which the code can interact and the number of tests which have to be carried out so there is a significant cost attached. In the enterprise space you will have to accept that clients will make demands in this area but you need to accurately assess the consequences and costs (one off during development and on-going for support) and make sales and management aware of them.
But essentially they all come down to the same thing - product software, even on the enterprise level, is far far cheaper than having an in-house team (or consultancy) build something bespoke. That price advantage comes with a downside - it's that you don't get exactly what you want and that the business needs to flex to the software sometimes.
It's not usually a popular message with clients or with sales but you need to work out which market you're in (product or bespoke) and remember that when making decisions.
In terms of the other two bits of the question - I don't believe the context created it at all. The root of it is that organisations are different. Unless you have all your clients the same, it was always going to be a problem at some point. Maybe it's a bit worse than it might have been but probably less than you think.
My experience in this area: I've been on both sides of the fence. I've been a development and / or project manager commissioning enterprise (and non-enterprise) third party software products (portals, finance systems and travel booking systems) and I've worked for two software houses developing them as a development manager (which is currently what I do).
Enterprise software developed without
enough direct customer involvement
in such cases, this will be a common phenomenon in product lifetime. If the customer is not involved and you don't know what and how he wants things, you'll be up for quite a bit of disappointment when you deliver the product and you find out his reaction.
How much do you think did the context
contribute to this?
I think it's the main cause.
What is/was your experience and
context?
Similar context, up until about half-way across a project's development period, when delivering an intermediary product, I found out that many of the customer's expectations were quite different than what I had in mind. I guess it was a good idea to send something intermediary for approval, this way I had much less to modify than if I were to send a final product that would not meet customer expectations, so I suggest you keep a connection with the customer from time to time, and get him to approve features before you move on to new ones. This way, when the final product is ready, it'll be what the customer has seen and approved step by step all along.
It depends how long-lived the product is: the longer the life-time, the more evolution is possible and/or required.
For example I helped to sustain one software product from 1991 to 2003; and at the end, it was hardly anything like at the beginning:
It started as an assembly TSR for DOS, implementing modem-sharing for small (e.g. lawyers') PC-LANs.
It ended as a distributed service for NT, implementing least-cost fax routing for several telcos.
It was sold throughout this time, several releases per year; it was what customer wanted, but the customers (and their needs) changed over time, as did the underlying O/S, the competition, etc.
This is why you create API's. I've also seen enterprise level applications that allow users to create their own vb/java scripts behind forms and inside reporting tools. Yes, embed a reporting tool writer and don't try to make all of them yourself.
Enterprises are notorious for their desire to have massive amounts of features in every app. Even within the same company, you can get multiple ways of doing the same thing. I their defense, time is money, so when you save a 1000 users a click, it can add up. On the other hand, they also have people with too much time on their hands to think of every possible piece of data they may ever have to track in the entire lifetime of their company and will want them all in your app. They have the money and are set in their ways a lot longer than say a startup.
When you deliver something the customer did not want, you have failed with requirements engineering. Since this is the first stage of software development, and design, coding and testing are based upon it, bugs in the requirements are the most difficult and costly to fix.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am a first time intern at a large corporation and I created a GUI tool that lets my coworkers visualize the log file that their product produces. The tool, known as MRI, is nearing completion and I face a conflict.
One party, (Two ambitious Indian guys that live in California) want me to adapt MRI to a new format and to display much more detailed information. The current version of MRI is built around the idiosyncrasies of the 20 year old log file format. In my opinion it is a bad idea to attempt to grow a more powerful, more universal tool out of a less powerful and idiosyncratic one (Better to start from scratch; something I probably don't have time to do).
The other party is composed of several marketing types and my father. They are drooling over the shiny new GUI that I slapped on top of their crazy old log file, and every one of them wants some feature that would help them with their day to day work.
Whom should I please? I just want to code. Which path will lead to less dumb conflicts like this?
Sounds like you are getting your first taste of the world of a manager! I'm doing exactly the same thing 10 years later, with a much bigger budget and head count. So it never really ends.
I love the answer about doing some time estimates for each requested addition, and then sitting down all parties and working on a negotiation that gets the greatest degree of satisfication. I'm betting that since you are an intern, and many of the people you mention have seniority, that they will be able sort out amongst themselves who has the biggest stake and most power in the situation. But if not, don't hesitate to act as moderator -- after all, this is your project.
Other things to think about:
Types of stake holders:
Customers - the person who controls the budget is often the most powerful of stakeholders, after all, they control your ability to do the work by controlling your funding. For an internal tool, this is probably an internal stakeholder, but it may be someone from a non-engineering group, if this tool is for a non-engineering purpose.
Users - in the long run, users often make or break a tool. They definitely determine the tool's longetivity. It's not unusual, though, for users to lack advocates. And in a big internal project, it's entirely possible that users are not the customers.
Technical Management - particularly when you are an intern and when you are working on an internal project, technical management is the group that's most important for you (as an individual) to please. They may have their own stake in the feature set, as they may be looking for a certain feature path for the product that fits a long term technological end game. Ideally, they should be on your side, and helping to figure out the best feature set.
In a big company, hopefully these roles are really well defined. Probably with an org chart. But not necessarily. And in a group that's used to working together, they may not make it really clear to a new comer exactly what the official roles are. As the guy doing the work, you're job should be to accurately and honestly tell them your best guess on what effort it will take to get the feature done. And to be open to ideas for making it cheaper/easier.
Negotiation:
The best negotiation advice I've ever gotten was "A good negotiation is one where everyone thinks they won". Sadly, the frequent outcome is that everyone feels equally screwed. The trick between every stakeholder leaving happy and every stakeholder feeling beaten down is to see the big picture and be innovative about getting everyone's needs met. In the end, no one really cares how you do it, if you can make their jobs easier, they will be happy. So finding features that serves everyone well can be the key to resolving the conflict.
Being able to do this well will really make a positive impact on your bosses. This is an extremely rare skill, and this type of finesse does get noticed.
Not having it does not mark you as a pariah, however, not many engineers enjoy negotiation. And it's never worth making every engineer be good at it. It's far better to find an engineering manager who is good at negotiating and to let them be the "speaker for the geeks", so the rest of the engineers can do their work in peace. :)
Sit the two parties down in the same room. Show them a list of the features each has asked for and how long you think each will take. Then explain that all of it is possible but all of it takes time, and ask them to come to agreement on what they would like when. Note down what is agreed and mail it to everyone afterwards so there is a record. Don't forget to pad your estimates to allow for testing and debugging time.
Alternatively, work out who the person directly responsible for managing you is, implement what they tell you (feeding back estimates of how long each thing will take) and tell anyone else who asks you to implement anything to go talk to that person to get it on your schedule; then doing the above management work becomes their problem.
Explain, if doing one of the above does not cause the matter does not resolve itself, that the Californians' features would require a refactor, and if you are going to do that you would rather hold off implementing any features for the other party until that is complete since doing the same work twice is wasteful.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
How do you cope with that?
Is it normal to allow the costumer to change the software as often as he wants? I´m working in a environment where there are no specs and constant requests for changes.
For every new costumer we have to create a new branch and makes so many changes that by the time I finish I have a complete different product. I´m pretty much losing my interest in programing because of that.
So, am I wrong to say that the costumer should not be allowed to change the software at his will?
English is my second language, so please excuse any mistake.
Related:
How to deal with poorly informed customer choices
EDIT: I originally missed the part that you have many customers and are customizing a single piece of software for each. I'll leave my original answer for reference, but it's not really applicable to this particular situation.
In your case, I would suggest that you need a different tack to addressing customer concerns. One technique I have seen used is that any changes need to be consistent with making the product more useful for all customers. This would mean that you can say yes to many changes. For example, making the UI customizable via templates. That would benefit all customers, but may be driven by a particular customer's desire to fit the look-and-feel into their standard. But it would also mean that you need to say no to some requests, or modify them in a way that they are generalized to be useful to all.
You may also want to have your customers use something like UserVoice to make feature (and bug) requests and vote on them. This allows your customers to have some direct input into the direction of the product, but forces the requests to be filtered through all of them. Again, you need not always accept the highest rated requests and you can accept some lower rated requests. The guiding principle ought to be making your product useful to the widest range of customers.
I don't think that it's practical to have a separate, custom branch for each customer unless you plan to have only a limited number of very high-paying customers. Eventually, your version control system will become your bottleneck and not allow your company to grow or even serve your current customers well.
Once you get into a more sustainable feature selection mode, my original answer may still apply. Hope this helps.
Original
I'll say up front that some customers are just not worth having. Only you can tell when this is the case.
Typically, though, it's our job to discover what the customer actually needs and deliver that. I'd recommend following an agile development methodology to do this. Rarely does a customer actually know up front exactly what he needs. Even more rarely does a developer understand what a customer needs before they start writing code. Agile methods embrace this reality and follow practices that make change less damaging to the process.
First, agile methods employ lightweight processes and delays making decisions until the latest possible moment. There is "just enough" up front planning to lay out a basic architectural framework, but for the most part it is design-as-you-go. This is not as freewheeling as it sounds as the techniques used in agile methods, such as TDD, pair programming, refactoring, etc. are sound techniques that encourage good design and design improvement.
Second, agile methods are light on documentation. While not documentation-free, these methods keep document maintenance to a minimum. One of the worst aspects of change is that documentation becomes dated and must be constantly updated to be correct. Agile methods identifies those documents that are truly useful and maintains those, but other documents that become out of date can be discarded. They are used in the moment as needed, but you are not tied to them. Agile methods put a premium on the code, and tests, being self-documenting.
Third, agile methods encourage a cooperative form of development based on mutual trust. This goes both ways. The customer must trust that you have their best interests in mind, while you must trust that the customer knows or, at least, can recognize what he needs when he sees it.
Lastly, the hallmark of agility is release early, release often. Getting the product in the customer's hands early is the best way to get feedback (again, early) on what he really needs. Once you have a concrete product you'll start getting information on the changes that really matter. By planning to release early and often, and coupling it with other agile practices, you'll also build a framework into which change can fit more easily.
Even when following these methods, though, as I said earlier: some customers are not worth having. If your customer doesn't trust you enough to follow your advice when a change is bad or if the customer doesn't know and can't recognize what he truly wants, then there may come a time to sever your ties with them. I'd suggest that talking with them and letting them know that you want to get them what they need, but they need to know what that is. Spend some time talking about it so that you both have a better understanding of the goal and put into place agile methods to deal with the reality of change. If they are still unreasonable, then perhaps it's not going to be a good fit for you.
am I wrong to say that the costumer
should not be allowed to change the
software at his will?
Who owns the software? You or them?
If I own a house, I can hire someone to paint it in a different color every week if I want to. If the painter complains, I can get a new painter. If I run out of money, maybe it is because I am an idiot. But the painter did nothing wrong in painting my house, getting my money and using it to feed his family.
If I own a certain software, I am allowed to do whatever I want with it. And if you don't do it, then I'll ask someone else.
specing out the app is as important (more even) then implementation. Giving the customer at least a base line document, UI mock up or something like that i think is critical.
you have to accept change requests as the system evolves and matures, otherwise the system will suffer from entropy and any hard work you have put in will be lost forever. if it is a more commercial product try and restrict to changes that all your customers want. then everyone is getting added value.
If you have baseline documentation you can then charge for customization. the less you want to do the customization the more you charge :P make sure you document and estimate all the change requests. (i use fogbugz for this but there are many other tools out there) If the customer is paying for the changes then at tleat you will be getting renumerated for the pain of changing the system.
Your company is running itself hopelessly into the ground.
You should go job-hunting immediately.
before i put forward my suggestion, i should say i personally believe that a business is there to make money. so if a client is willing to pay for something they want, figure out how to accommodate them (rather then turn them away).
now, a solution:
i was at a company where they had a software package which they sold to many government organisations - each with their own particular tweaks and features.
i asked the managing director how they avoid version hell - considering they have to maintain a specific version for each client. he said "we dont, everyone gets the same version". they simply maintain one version for all clients, but switch off features which arent specific to a client.
LM
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I currently work for a bespoke software agency. Does anyone have any experience of how to win well priced work?
It seems there is so much competition from offshore/bedroom programming teams, that cost is extremely competetive these days. I feel that it is very different compared to a software product company or an internal IT department in terms of budget.
As someone else said before, we only ever really get to version 1.0 of a lot of our software, unless the client is big enough. In this case it doesn't make business sense to spend ages making the software the best we can. It's like we are doing the same quality of work as internal IT staff. Also a lot of our clients are not technically minded and so therefore will not pay for things they don't understand.
As our company does not have the money to turn down work it often goes that we take on complicated work for far too little money. I have gotten a lot better at managing change and keeping tight specs, etc. It is still hard.
Edit-----------------------
Almost 3 years on from this post and I can list some important lessons that I have learnt since then.
Please see below for my answer
If you are concerned with doing too much work for too little money then work on an hourly basis. Yes, that is harder to sell in most situations.
Maybe you can try a two-phased approach instead. Have a very short initial engagement where the deliverables are very specific requirements documents that become the property of the client. You risk having to compete for the actual development but you take away the risk of pricing the project too low because you will already understand what the client is like to work with, as well as, the application requirements.
Once you win the work at a fair price then use the best practices suggested by mathieu to help ensure quality and productivity which both lower the cost you incur.
What you described in your post, (not your question), I think is a sales, management and marketing question first and foremost.
You say that your clients are not technically minded, this will require to have a cohesive sales, consulting and communications strategy, this isn't about programming skills.
Also, if your company constantly accepts projects that are too complex or expensive for your team, and you deliver low quality products you'll sooner or later be stuck in a hole. You will attract customers that you do not want, and existing clients will be turned off by your 'incompetence' and sooner or later find another company on which they'll try to play the same price game. Those clients are worth nothing in my opinion.
You ask 'how do you win well priced work'? People are social animals, they talk with each other. If there's a market perception that you are an unreliable company, people and future clients will sooner or later know. Customers don't care whether you offered them a product at a really low price, on a too tight schedule - It's not really their error, it's you who accepted it. So once again, I think whole ordeal is a bad business practice.
I found that you really have to define tight specs on jobs with low budgets, define what you will and can deliver, tell them the price, stop your boss from offering too many long term customer discount price tags because they are too afraid to lose the client. Communicate early and often when things start to get out of hand. Write precise offers for additional features. Write these precisely down, don't rely on phone conversations (you: "that's an additional 4 hours of work", client: "ok"... 4 months later, client "what was that again??? why am i supposed to pay for this").
Now of course, one way you keep prices down is by not hiring complete morons that might be initially cheaper than better qualified programmers. This is a shortsighted approach and will fail miserably.
It is the relationship with your customer that will win you additional business. One developer actually stepped forward and halted a project because his sales consultant basically lied to us concerning a solution set. The developer then offered a straight forward, bare bones solution within the same budget and he delivered on time.
This guy and his team has been consulting at my company now for over 6 years. His integrity and earnest, hard working nature has been an immense advantage, and he has found quality people to work for him as his reputation has grown. His honesty is worth more than any savings I could get by shipping my company's intellectual assets overseas.
"so much competition from offshore/bedroom program teams" - sounds like you guys need to put some time into networking. At the end of the day, people like to do business with people, not with businesses. If you're well known and liked in your client communities, you'll be the front-runners and you'll get a better price from the confidence you have built. And referrals will give you a powerful edge - ask for them.
"our company does not have the money to turn down work" - lot's of companies have this as a start point, but ultimately you have to get past this approach The time you spend on these types of jobs stands in the way of being successful. You need to make decisions about what type of work you want to do (and who the customers will be) and just as importantly what you don't do.
As a consultant, I have personally moved to an hourly-rate-only model for just this reason. I have been burned by too many contracts-gone-wild, and I feel your pain.
In the end, people who only ever go with the lowest priced proposal will be trouble for your company. While you can't be so choosy, such that you don't ever get projects, you definitely want to steer clear of contracts whose supporting management are so agnostic about the actual software development process that they only look at the initial price tag for something. Usually, it's the stuff not in the contract or specification that changes the profit margins and timelines.
It's often in you best interest to be picky up front rather than lowering prices in order to receive a wave of what end up to be trouble-clients anyway. In your case, while there's always the contention between an RFP that is not as concise as a technical requirements specification, initial quotes should be understood as a general estimate based on the level of clarity in the RFP.
And I definitely agree kitsune, that if your company is consistently accepting contracts that don't fit your company's development expertise or bandwidth, all that will result is overhead and bad reputation.
This could be seen as quick guide to the above problem.
Proposal Document
Start with a proposal document that explains your understanding of the clients needs as best as possible. This can be done in 1-2 pages of writing as a minimum. It can start heading towards requirements, but it should be more casual than that.
Budget Document
Now go to Excel and list all the tasks in the project you think you will have to do. Put down the times in days, none bigger than 2 (0.25, 0.5, etc.).
Add a column for testing, and make it a percentage of the development time (20-30% is normal)
Now add a column for management (project + account) and add a % of time for that (over the previous two columns). 20-40% is normal. (70-30 split pm/am)
Set a day rate for your company. You can get more complex and have different rates for different user functions, but as a minimum set a rate that will mean that you will have a good margin whatever the work is being performed.
Work out what the value is for the total days that has been recorded so far. Then add a contingency amount on top of this (for fixed price work) 10-20% is normal here, but can change based on experience with the client and the amount of change you are used to with them.
At this point you can discount the total amount, which is better than lowering any other part of this document, as it will show the client that you are not magically making jobs go faster, rather you are removing some of your margin. They should therefore not expect you to reduce the timeframe of the project.
**Important - Analyze your client's budget and business when developing a costing. There is no point in you delivering a costing designed for a huge enterprise to your mate who wants an application done cost effectively. Likewise, make sure that you charge correctly to an organisation that will be used to high end freelancer rates.
Think like a business analyst. Not only will it help you make the client happy when they see your costs, but it will probably give you a greater insight into their business. If they are going to make money by using you, then you are probably onto a winner. If you can't ask directly how much money they have to spend with you, work it out by asking how many customers they have, what they charge, how many employees they have, etc. You should then be able to work out if what you are proposing is going to be profitable for them.**
Go back to your proposal document, and add a table with sections for design, development, management, etc... You could show the client your costing sheet in certain circumstances, but it is better to avoid complexity in most cases. It's there as a backup though, and you didn't just cough up a number.
Timeline Document
Take the list of design and development tasks from the budget, and put it into a new sheet (or Project if you're posh like me). Put in the start and end dates of each section adding roughly 30-50% extra on top.
Add some graphical representation of the days as blocks in Excel or use a Gantt template like this one.
Go back to your proposal document and add key milestones from the timing document.
Proposal stage completed
Send or present your proposal to your prospective client. Hopefully they are excited with what you have proposed and happy to proceed to the next stage, full requirements gathering. In subsequent projects with the same client you may be able to go straight to requirements.
Requirements stage
List each requirement against a separate id, either 1,2,4,5 or 1.1,1.2,1.3. It doesn't really matter, but the second one can help with large lists.
There are some tests for requirements and you can try to follow these, but sometimes they don't apply (some requirements might be design led for example). Some of these are: Is the requirement testable, is it singular, is it clear? I'll try to find a link to this somewhere.
This is my developer standpoint:
Version control best practices: Keep the trunk clean, don't commit code that doesn't compile, and commit frequently
Continuous integration
Unit testing (with code coverage)
Automatic deployment on test servers
Automatic packaging of the application
Automate as much as you can :)
Also, hire good developers, and treat them well :)
Sell fixed price, fixed scope work, not hourly work. That mitigates your customer's risk of an over-run (you absorb all the risk, but you're doing that anyway), and frames the project in terms of the value of the software, not the quality of the effort going into it.
We are trying to build a product and reuse existing experience. Comparing to UK in Ukraine (where I work) salaries are lower, but still 4-5 times higher than in India.
So far, the best result is to get two new clients, which need a similar solution, so we can offer better pricing and we are more confident in our estimate.
BTW, I checked out whywaitdigital.com, and it seems that we have a product which your clients might need. We do portals - editorial, B2C, geo-enabled product catalogs and we use ASP.NET MVC also. You can find contact information on our website, www.socialtalents.com.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
What are the main reasons personal projects (software apps etc) never get to the level of competing with your salary?
To me one big problem is "on-the-fly" feature expansion, with this problem, the end only gets further and further away!
For me, it's simple: I work 8 hours a day already. I spend a few more hours a day keeping current. I have a girlfriend, some local family and a decent circle of friends. I have (gasp) non-computer-related interests and hobbies. In other words, I have a life.
So ... Time. Time is not on my side. Would that it was ... My blog might be a bit more current if there were just two more hours in every day. :)
(Originally posted by John Rudy.)
If you want your hobby to become your job you have to acquire all the other skills you need to be in business. At the end of the day your pet project has to stand on its own two feet in the real world. At the same time you are enjoying the coding you need to get yourself a concrete plan to commercialise your activity.
Most hobby projects fail to make the big time for one of two reasons:
The idea is not commercially viable
The discipline necessary to commercialise the idea is missing
Just because you are a great technologist does not mean you'll be a great businessman. You may be, but the two are not necessarily linked. It is no weakness to consider partnering with someone who has no technical skills but a good network and some proven business acumen. Quite often people like that are looking for techies too so you might find a great partnership. That person can provide the structure and commercial discipline that you probably lack if feature creep is pushing your completion backwards.
I think the primary reason is the simple work overload that most developers experience. Most personal projects take place in the evening and weekends, and as excited as most of us get about our ideas for personal projects, after 40 hours (or more) of salaried programming, it's hard for "more work" to compete with watching a game while sipping a beer or spending quality time with the family.
Different skill sets are required to start and maintain a business than to develop software. Entrepreneurship skills can be learned, but not every has the skills to make it happen. A lot of times the skills it takes to get something started and off the ground are different than the skills it takes to finish it and polish it. For me, I know that I have the creativity to make software and find ways to solve problems, but I have little interest in finding funding for a business and marketing a product or service.
Assuming that you're a developer, it's most likely due to the fact that you do not know when, or are incapable of, stopping development and focusing on other things, like marketing and sales.
Time and Losing Interest, there is always a new tool or technology that can take your attention away from completing projects.
I'm not sure if I understand your question, but here are a few answers:
Adding "on-the-fly" features isn't necessarily a bad thing. In fact, it's the expected model of Web 2.0 and Web 3.0 projects. The key is to keep them very simple, only roll them out once they've been tested, and listen to your users. If you try to dump the kitchen sink in on the first release, it will most likely be ugly, confusing, and buggy.
Being a great programmer is only a part of it. You need business skills, marketing, knowledge of the user's needs and how to meet them, artistic/design skills, and a hell of a lot of luck.
Lot's of people have great ideas. Often different people have the same ideas. Most never get implemented. Of those that do, very few of them succeed. In some cases, revolutionary products took years to convince the buyers and users that they even wanted the product. Often the people or companies behind the first few iterations failed miserably and then a third or fourth person or company finally hit the market at the right time with a right product. Apple is great at both ends of this by the way - they not only innovate (first Mac, the Newton, etc.), but they also wait until the market need grows and they sense a place to pounce in and take advantage of it (the iPod, the Mac vs. Windows issues, etc.)
Most of these bullets apply as much to software as they do to widgets and services. The big advantage that software has is lower startup costs. Just like the saying "On the Internet, no one knows you're a dog" - "When looking at a web app, the user doesn't know if you are a multi-billion dollar company or a single guy sitting in your underwear in your parent's basement." If your software is good, that is...
I'd say one of the big reasons is that by nature, personal projects don't get as much attention as your job will.
I have a slew of personal/side projects I'm working on, but they get far less of my attention that my 'real' work does because, right now, that's what's paying the bills.
If I were to take a month off and work only on my personal stuff, it'd probably be pretty cool / worth money.
developers often design for themselves instead of for their customers
developers tend to put off releasing products until things are 'perfect' - and they never will be
Weakness of mind and spirit. Build a team around your product early.
Scope creep. Concentrate on selling what you have already got: "The customer can have any color he wants so long as it's black". Henry Ford
Small feature set. Leverage features of your product by what is already available on the market.
Not enough hours spent daily. Often achieving something might depend just on simple routine, putting your time in.
Deep down I think its a lack of belief in the project. If I believed in what I was doing I would not stop in completing the project.
Desire to build an ideal product
For example: There are various ways (algorithms) to get a particular task done. But, people wait to discover that one ideal solution. Even if there are multiple solutions for the same problem already available. That ideal solution is never found.
Procrastination
Your personal software projects don't compete with your salary for one reason.
What do you do for your salary? Whatever that is -- however much you may like or dislike it -- it more valuable than your software product.
"But my day job involves a lot of stupid time-wasting meetings." So? Clearly, someone will pay you more for wasting your time in meetings than for your software products.
"But my day job forces me to waste months in useless analysis and design documents and test plans that never even get used." So? Clearly, someone thinks this activity is more important than writing software.
"How can meetings or useless documents be more valuable than software?" I don't know, but look at your experience. Companies love to pay programmers relatively large amounts of money to hang around and waste time.
Companies don't love to pay for software.
Your personal projects don't compete with your salary because your time is more valuable than your products.
The biggest reason? Because if you can write it yourself and people like it, someone else can make an open source version with much better support than you can provide alone. Why not skip the middle man and release it as open source yourself? Sure, you miss out on the direct profit, but that looks very good come hiring time.