6 Replies Latest reply on Oct 11, 2012 9:18 AM by beverly

    Pricing questions


      I was wondering if someone could give me a little guidance on a fee structure for developing a database. Flat fee versus hourly? I'm sure many people have consulted with a customer but then a thousand different things come up once the customer really sees what is possible. I've heard of people charging a set fee per table but seems a little oversimplified. Then there is a testing phase where other employees start to test it in the company come up with new problems that the initial contact didn't see. Then there's the aftermath when the solution is actually in use and other functions or reports need to be developed. How do I avoid the unexpected pitfalls that will invariably come up? i'd appreciate the wisdom of those who have gone before me.

        • 1. Re: Pricing questions

          We use a combination of flat fee and hourly.


          We give an initial quote based on similar projects we've done. This is followed by a pre-approval from the client. Once pre-approved, we will have a discovery meeting where we develop an outline of the project. Once our development team has assessed the "features" of the database, we adjust our quote accordingly.


          The most import way to not get burned is to have a contract that defines what the client is getting for what price, with a stipulation that additional features will be concepted and created at an hourly rate, and that subtracting features will not lower the price. A contract that defines the payment points as well (IE 50% deposit, 30% at beta, 20% at install), with corresponding milestones will give you a rough estimate and "cutoff" points as well.


          Even more important than that, is putting your foot down on the hourly bill. Filemaker is a ridiculously easy platform to jump in and make "a few quick changes that are no big deal". Know that those types of changes compile into a whole lot of unbilled time if you don't be upfront with your client and tell them those additions are hourly.


          If you're super worried about a ton of changes to what's included in the flat fee, you might want to add some stipulations about the beta phase as well, capping a limit on the number of hours spent meeting and making changes once the beta is delivered.


          Good luck! And welcome to the wonderful world of consulting!


          1 of 1 people found this helpful
          • 2. Re: Pricing questions

            Hi Bluez,


            You might try a hybrid approach. (Caveat: I am not an independent FM developer). We have done this in our HR consulting work for some clients. We'll quote a fixed fee for a specific project, then any work beyond the scope of the original proposal is charged per hour at our standard bill rate.


            Two sticky points:

            1) The proposal needs to be VERY specific in scope and sequence. That way, both you and the client know when the "project" phase is over.


            2) Be very clear that feature requests outside the original proposal will be billed at an hourly rate. Make sure the client understands "this feature, xxx, falls outside our original proposal."


            Best Regards,


            1 of 1 people found this helpful
            • 3. Re: Pricing questions

              That sounds perfectly logical. It's pretty much what I expected. What I keep running into is when trying to convert a company wide "manual" method into a digital solution, the client suddenly sees possibilities he had a hard time imagining in the beginning and when the other employess get involved in beta testing they see a whole host of things that the original contact never saw. I can foresee alot based on previous projects but I always get a little nervous when I get a list (even a short list) and realize it's going to take hours and hours. I just don't want to make it seem like I'm surprising them with hidden costs. Needless to say I sometimes give away more than I would like to.




              • 4. Re: Pricing questions

                Scope creep will kill many things:


                1) The project

                2) Your profits

                3) Your relationship with the client

                4) Your nerves




                I usually suggest just estimating the incoming changes. Then let them decide if they want to pay the bill or not. Often, that, "Ooh, it'd be cool if it would do X" is blunted when they see how much that little doo-dad will cost them. But they still get to make the decision.



                • 5. Re: Pricing questions

                  Scope creep...I like that.



                  • 6. Re: Pricing questions

                    Scope creep


                    defined (at times) as: the client who demands work (on a solution) that was not in the original specs and then refuses to pay for it.



                    -- sent from my iPhone4 --

                    Beverly Voth