 How's everybody doing? Did everybody go to the pub crawl last night? Somebody? Nobody? Anybody? Some of us are a little bit slow today so we hope this presentation goes okay. So just to make sure you're in the right room, we're talking about Drupal on a dime today. My name is Jennifer Holes and this is Ben Coder. Just a little bit about who we are. I'm the director of sales and marketing for a full service Drupal design and development agency and we're based in Vancouver, Canada and my partner here Ben. My name is Ben Coder and I'm the lead developer at Ediminish X Media. And the CTO. And transitioning in the role of CTO. So basically we tried to focus this presentation on sort of two sets of people. One would be a designer slash developer looking for strategies to build a Drupal site. Cost saving, time saving, budget saving, whatever. And then the other is if you're actually a client interested in building a site with Drupal and looking to kind of leverage those things as well. We just get like a show of hands. How many people here are kind of like in the designer developer camp? And then other people are you from organizations potentially looking to use Drupal for your sites? Anybody like that here? Okay, so nice mix of everybody. And basically why we're here is just to kind of go over some of our experiences with helping clients build sites that are cheap, fast and good all together. So where this all kind of started at our company the way that we started looking at new opportunities and new ways to take on kind of lower budget jobs was this was actually from a prospect that had contacted me and he said in looking for a developer I found that there are an equal number of single person companies who cannot handle this job as there are multi person agencies who will not work for less than twenty thousand dollars. Unfortunately neither of these is the right fit for me. We're about fifteen people about ten of those are developers and a couple of years ago we said listen we can't take projects under twenty five thousand dollars just the way that our team is set up. It just proved to be too costly and budgets were getting run up because we were treating each individual project kind of starting from scratch and working with that client to kind of I guess lean towards their needs versus trying to kind of instill and force upon them some strategies that could help them get what they want but at you know a good budget within a good timeline at a good price. So I don't know how many of you read the Oatmeal are you guys familiar with the Oatmeal.com so this is like one of my favorite comics from the Oatmeal how web design goes straight to hell. So it's kind of the idea where a prospect comes to you as me the sales person as I'm potentially taking on somebody's business. You have a couple of calls or a couple of face to face meetings with the client and everything seems great you kind of outline their expectations and you collect your requirements and based on what they need you say yeah sure we can do it in X amount of price and then we find right from that moment on when it gets to the development stage all of a sudden all this other crap gets thrown into the mix and soon you're finding your scope is getting out of line and your budget is getting out of line and your timelines are getting pushed back. So one of the things that we started doing with clients is you know I am a unique snowflake I think you guys anybody who's designed and developed a website it's like somebody will come to you and be like no I've got the best idea it's like Facebook and YouTube and Twitter all rolled into one and it's totally unique and there's nothing like it out there so it has to be a total custom build no like that module sounds great but I need it to do this this and this and that's kind of like the first stop that we are putting on clients like you're not a unique snowflake chances are something's been done before how can we take something that's been done before and make it work for your unique business needs to give you the most value at your ridiculously low budget that you've made us work with. So again fast, cheap good you're always hearing you need to pick any too you can't have all three so what some of the things that Ben's going to go into in a minute is just talking about strategies within the design and development stage where you can get all three. So you can't always get what you want there are certain red flags that usually come up right in the beginning stage of projects that we have with the client so we wanted to share a couple of those with you and also kind of like how to approach these red flags if they come up and one of my absolute favorite that sometimes comes up is that a client will say to you well I want to switch to Drupal I see all the benefits of using Drupal and open source CMS and all of that but I want that my site at least works the same way as my old system at least should look like my old system or have the same functionality as my old system so that is kind of like a first red flag that you really need to address right away because if they want to have something that is exactly like their old system why do they want to switch in the first place it doesn't make sense this will create later on it will be more time consuming to try to recreate in Drupal something that was built for example over years as a custom PHP system and easily you can easily run out of budget if you're trying to if you're going along with a client there that has that expectation and actually also a little bit further on to that today at 1230 there's also another presentation called I'm leaving you at the risk of dumping your old CMS for Drupal so you manage them so if you're someone who actually is thinking about doing that is switching from your old CMS system to Drupal that might be also a presentation that is really interesting for you the thing to keep in mind and to really make sure that the client is getting that is that every CMS doesn't matter if it's Drupal or WordPress or Joomla or if it's something proprietary it has its idiosyncrasies it works it's certain ways it has its strong points and it has it's weak areas and Drupal might be a little bit plain out of the box but y'all are aware of like the multitude of modules that are provided by the community and that are out there so again thinking about that concept of I'm a unique snowflake which is not true chances are that someone already has built something that addresses your needs or your client's needs now will that solution that is already built fit 100% to the requirements that you have now well chances are that this will not be the case but I don't know if you're familiar with the 80-20 rule that you can get about 80% of your requirements done for 20% of your budget if you think about that then this is a really good starting point with the project so the idea would be to reuse already contributed modules instead of recreate modules or recreate functionality just because there's one little piece that is okay we're trying to sorry about that is that any better okay sorry now where was I so the idea of reusing functionality modules that have been already built that are already out there instead of recreating something completely new just because there's this tiny little bit that is not how you envision it to work and I'm also going to go into that a little bit later as well another red flag that sometimes comes up during the initial discovery is if someone is saying well I would like to my side to look or work like Amazon or Facebook well if you're on a tight budget that's probably not possible and it's really important to make clear that these sides haven't been built within like one project phase over like two or three months these sides have grown over years and years and have improved over years and years so that is something to keep in mind and also other things that sometimes clients like to slip by a little bit on the side is well we have this little in house system that we use and we just need to have like a little connection to the Drupal side but it's nothing big just to see as we file and in the end it's turning out into like a full on live connection to their MS access machine that they have sitting somewhere without an internet connection in their office so those are things that really you need to kind of like make sure to iron that out and to make clear that it might sound simple but to make sure that your client knows that no this is actually way more difficult than what you had in mind also another one that we hear from time to time is that someone is saying well we want the site to basically manage our day to day business so it shouldn't be just like a website that shows information it also should also completely handle all our business on the back end side so if you hear something like that and they're coming to you and say well we only have $20,000 then you might have to talk with them about their expectations that they have regarding that but coming again also to the 80-20 rule and as you see on the slide here you just might find what you need so a client might have the great expectations of how things should work might not be familiar with how Drupal works and some of the ways that Drupal does things but it is important to help the client to understand like well you know what give it a try this is what we can do within the budget and within the timeline that we have so have a look at it because even though it's not exactly what you envisioned it might be exactly what the people that work on a day-to-day basis really like or that this is actually really the thing that they would that they will find beneficial so I put this slide up because I think it's really hilarious when a web project gets started and you kind of pick out your point person in the company that you're working with who acts as their project manager working alongside our project manager and then things like IA mock-ups like wireframes or design mock-ups or as we're in agile development doing sprints and we're having things tested all of a sudden these other voices start coming to the mix and before you know it like everyone has got their own opinion of how things should work and you've already discussed the requirements with the client and outlined them but now that they've passed it around to more people in their organization they're coming back with more and more requirements that are just blowing the scope out of the water and no word of a lie we actually had a client who said he just wanted to show the design to Mr. because his sister did design in a magazine like 20 years ago so she should have some input into like what this looks like and she came back with a whole bunch of little changes etc etc where it's like go ahead and collect that list of requirements but table that and have the one point person and try and keep as few people as few key people involved in the project as possible rather than sending it out to the whole company for feedback so a couple of key departments are the people that should be representing the new site and getting a prototype out there built to kind of get people playing with rather than everybody saying oh well if it just did this if it just did that leading to scope and budget creep and further to what Ben was saying about a site like Amazon Rome wasn't built in a day you find clients that when you we were in the past a few years ago we were taking a waterfall approach to projects so we're taking on projects anywhere between 50 and 150 thousand dollars and then the requirements just started growing and growing and when a project is that big and it takes like six months to a year to complete you're finding that by the time that six months comes around that their business or maybe even their requirements have changed and now you've spent all this time building something that may not even necessarily be relevant anymore so we've really got obviously we've embraced agile development like I'm sure most of you in the room have as well and we really encourage clients even if budgets not an issue to prototype small things and explain to them they're kind of going to get a more vanilla version but they're going to be able to get their hands in and test and like Ben said be able to figure out Drupal a little bit more and figure out what they like and don't like and then sort of add those Lego blocks in rather than building this big Lego castle and handing it over and it might not even be relevant to the client by the time that it's done so the idea there just you know prototype and build upon the smaller thing that you started with and I'll start off with this one and then pass it back to Ben but you know the proof is in the is in the pudding everybody in a company when you when you're working with a with a site and when you're working with your business you have sort of an inside intricate knowledge of everything that you're doing but you start to forget what the people who are actually using your site are using it for so our thing that we're always trying to push on clients rather than try and get a million requirements or features functionality different design things social media etc start with something small and then get feedback and you know spend the budget where that feedback has come so your site makes the most sense to the people that use it and again if we think about for example Google Google started out as a search engine and not started out as a replay as an online replacement for Microsoft Office so things like that have developed over over years and years and just wanted to mention like two real life examples where it makes sense to break it down into these stories and into these different phases and really look at what is really important in the beginning for your client or for your company so imagine the requirement well if I if I post a if I publish a new blog post I want this to be sent out to Twitter and on the Facebook page and on Google Plus which is a valid requirement and there are modules out there that will help you to do exactly that it's not a big issue but if your client or your company don't even have a Facebook account yet or a Twitter account yet or working with Google Plus this might be something those might be like 5 to 10 hours that actually would be better spent on something different the ability with Drupal is there that's a nice thing and that's the thing that needs to be made clear the ability to do that is there but is this really the most important part that we have just because it is really fancy and you would like to have that as a feature or is that something that can be put a little bit on the side and in the end if there's still budget left or maybe in the next phase this can be used another point also regarding prototyping and regarding the other slide that we had with you might not get what you want is content workflow Dries mentioned the workbench module for Drupal 7 which is a really nice addition and really powerful but your client or your company might have a very complicated workflow about who should be an editor of a node and who can approve if that node goes live and how about then revisions and all of that so that might be really complicated in your case and you might not be able to absolutely replicate that one-to-one with the workbench module so prototyping in this way would be that you're trying to get as close as possible to that required workflow with a module like workbench and then you let the client go in and you say like okay this is a prototype and we set up the workbench module and all the support modules in a way that we think is as closest to what your company is doing and then actually let the people that need to do the approvals that need to do the reviews let them have a week or so to play around with and see how it works see how the workbench module is approaching things and again then you might find that people come back and say like this is absolutely horrible this is not working for us at all okay then you can address that or they might say this is great this is actually exactly what we need and in reality some of the approval process is actually not happening online and there's no need to have that approval process online because that approval process is happening offline so this is kind of like also again the 80-20 approach and trying to break down the big picture into the smaller little pieces that can be achieved easier and again might be something that your client actually likes already the way it is and how money and time can be saved a couple of different options that you can go as a company or as a development shop as a developer so how can you achieve that to be really cost effective here and the nice thing about Drupal there are a lot of different options and different ways how you can save time and money the first one that we wanted to highlight as an example are you could use fully hosted solutions and we just have examples here there are a couple more out there that you could use something like sub hub or Drupal gardens so this is a great way to get your feet wet if you want to try out Drupal in a really easy way it is set up within minutes depending on which package you choose it's also free you might find some unique features in these products if you have a Drupal garden side you might have played around with the theme builder there which is pretty nice and if you had a chance to look at sub hub for example they did an amazing job when it comes to UI improvements and really making something trivial like placing a block really easy and intuitive and using that also brings the advantage that you have hosting and support included in the different packages that they offer so for smaller projects that might be the way for your organization to start off with and at any time you can also take your sites away from these providers if you want to grow later on now this is also going a little bit into the concept we have listed here limited to the features provided by the service well it might be that already has everything that you need but if you want to add other modules it is possible in some of the services or if you want to have custom development added to it sub hub for example then offers that as a paid service to continue to develop your site for you but then you also have to keep in mind that when you move the sites away from those service providers you might lose some of the features so for example if you have downloaded a Drupal garden site and use it locally you will find that the theme builder for example is lost you don't have that anymore one other solution are Drupal distributions there are a ton out there and they are really nice ones open public Drupal commons atrium these are all solutions that you have that have a ton of features they might already have more features than you will ever need for your organization or for your client even to the point where you would need to disable some of those features they're right there for you to download they're easy to install they all come with install profiles there's training and support and documentation usually provided on these websites that provide those distributions and as it is basically a Drupal installation that you have full control over you have also full control over extending these features and adding your own modules or adding any custom development that you need later on but if you're looking from an organization that is looking for a Drupal website on the con side of course have that you need someone who knows how to set up like a hosting for example how to install Drupal so it's not just one click thing like with the fully hosted services and in some of those some of these distributions you have a bit of a steeper learning curve in order to get things done so that is also a really good solution not only for developers or companies but also for organizations that look to use Drupal to look at the distributions that are available out there and use those as a starting point for your project and see what you can already leverage there and what has already been created there for you and use that for your projects but then another thing also to mention for developers and development shops is again to think about what we said before and not to try to reuse things and don't recreate things so if you build functionality for your clients think about if you can put that into a feature and set up maybe your own feature server which is done really easily keep your features that you create for yourself so that you can in the end reuse it so that is for example something that we at ImageX Media have started what Jenny mentioned a couple of years ago that we said we're building that news and event sites over and over again for our clients so how can we make that more cost efficient, how can we make that quicker and it's like okay well you know what let's build a feature that has all the views and all the content types in it that we reuse all the time and then if it's necessary we will adjust that for that specific client but that is something to keep in mind use tools like features like Strongarm in order to create to build up your own repository there are also features available on Drupal.org so you also can give those features back if you see fit or use some of the features that are already out there and created in order to cut down the cost for yourself and for your client that's basically how we got to a place where we could do fast, cheap and sorry can everybody hear me, that's basically where we got to a place where we could do fast, cheap and good in essence what Ben was referring to at our company ImageX we created sort of like a Chinese menu base where we had the same clients or different clients asking us repeatedly for the same things knowing that within each of these clients that they have specific requirements that they always want tailored and going back to the unique snowflake well no it has to be like this but if we can take them what we've built and kind of hand hold them and from our point of view push them into using stuff that is already in existence they can leverage what at one point cost us a lot of money to build and is actually quality features and functionalities and sites but for a fraction of the cost if they're willing to stay in line with our kind of Chinese menu of options and in doing so we found that now we don't have to, we stayed away in the past from taking on these 5, 10, 15, 20k clients because we just would find them a nightmare because we're always doing these things where we're allowing them to push us into building stuff that was uniquely for them which just obviously isn't feasible within that kind of a budget but once we started with this IXM base and kind of pushing clients in the opposite direction it's actually added a decent revenue stream for our company and it's filled in pockets of capacity and development time because our developers can pump this stuff out with their eyes closed because most of the work has been done we're just slightly altering it for the client but then holding the client to say listen it can do this, this and this but you can't get it this way for the money that you have but get something out get it tested, get feedback and decide where it makes the most sense to spend the money and if the requirements that you thought were really important to your business actually are providing business value based on real life feedback. What did you think? That's it. I mean I think with Drupal the answer is always can it do this or can it do that? Well sure it can do anything you want like how much money and how much time do you have and then that's when you get the answer of well I have 20k and I need it in six weeks and then that's when you got to get realistic and say for 20k in six weeks here's the things that we can do for you so you're definitely juggling between different clients' personalities and for some people that might not be the right fit a client will be like well if you can do it exactly how I want it I'll go somewhere else but more often than not we'll find those clients, we'll come back in the end and realize that no one's going to do what they want or if somebody says they're going to do what they want within their budget they've made a grave mistake and we'll regret it later so you're definitely changing profiles depending on the customer's particular personality and requirements. Yes, sometimes it is an issue the important thing is to really have that clear with a client beforehand kind of like and really explain them what the agile approach means. If you have these smaller projects sometimes you will not get around to do kind of like a hybrid solution where you kind of like agreeing to a fixed price but you do a bit of an agile approach as in like okay this is the fixed price so this is the limit that we're working in now let's break your requirements into all the little stories and prioritize them and then let's go through and you see how much time we spend and how things are progressing and after your first sprint or so the client has a product that he can work with and maybe he's changing things a little bit but then you need to also make clear to the client is like okay you know what we will let you know once we are reaching 90% of our agreed time so we're reaching the end of what we can do within that limit so sometimes that is it is a bit tricky but sometimes you kind of like need to try a mixed approach there I think something we also try and do when we're estimating to give clients an idea instead of I mean we'll break things the way that we work is we'll break things down by line items and show a client like how much time is being spent on each particular feature and requirement but another thing that we try and do especially when somebody has a lack of droopal knowledge is we add a column that says percentage of core functionality or existing module functionality so something that in their head seems like a really minor requirement could be like well that's only 30% core droopal functionality so what you're asking for is going to require 70% customization and that gives them a better idea in their head where the biggest time sinks of the project are going and we found that's been really helpful to show people and so many clients just think that the things that they're asking for are so little and meaningless why can't they just be done I just I just want to like write text in line no big deal you know whatever their requirement is and then when we show them well listen this is how droopal works and what you're asking is moving x percentage away from the core but here's what the core does what can we do within the core or within the contributed modules that's going to get close enough or you know maybe even extremely close to what you want to do if you're just willing to back off of a few custom things I mean it's a bit more difficult in a smaller budget to do a proper discovery phase but if we don't have the time typically we'll set it aside anywhere from 15 to 100 hours for discovery that's typically for larger projects you say have a 10 to 20k budget we'll do our best to understand your requirements but what we really try and do is outline in writing all the things it will not do so you know they have a requirement I don't know like I want social media on their site and to us you know if we don't dig deep into that it's like okay we can just throw up links to Twitter and Facebook but then later on they'll take that and be like no I wanted feeds I wanted you know like dynamically displayed on these pages etc etc so we'll say okay social media does not do this this this this this but we'll do this so really making you know a point to I mean in sales it's like get everything in writing up front because like you said assumptions will be you know misunderstood between the client and the person building the site so we try and actively outline what the things are that it will not do and that I think helps us stay out of trouble in a lot of in a lot of projects where a requirement that you think is simple can all of a sudden become really ambiguous and complicated so what we've created which we've sort of dubbed internally as launch kit that we're hoping to we haven't decided yet if we're going to do like a distribution or software of a service with it but right now it's kind of IXM base IXM is just short for image X media we find that that's kind of like a combination of the sub hub and the Drupal gardens but I mean that brings about an interesting point in certain situations when it's a simple site like let's say some kind of brochure site but maybe with something like an events calendar and a blog or something we'll just build it on Drupal gardens and like not if it's going to be more of a hassle to explain what Drupal gardens is to the client and sell them on the benefits of Drupal we'll just build it on Drupal gardens and they're none the wiser and we've created them a site that they think is beautiful I mean we've we've created them for you she was asking saying that as a project manager she finds it difficult when a client pushes back if she were to say well no we're not going to do that that that would create animosity and potentially throw the project off and I'm not a project manager I'm a salesperson but like I find with an upfront contract so first of all some of the things that we just mentioned what it is that you're delivering and what it's almost more important to say what it's not going to do versus what it is going to do because those are the things that you can point back to the client and say we told you it's not going to do this we can do that but it's not in scope but we as a company have went through a fair amount of I'd say project manager turnover and we really realized we needed people in the roles with the strong personality and reminding clients that in coming to us you saw this out because you said you wanted Drupal experts and the advice that we're giving you isn't because we're trying to save us money or screw you out of giving you something but we're trying to give you the best advice possible for your budget what you're trying to build for business value priorities we want the freedom and we seek out clients that if they come to us with something that we think is a really terrible idea that's a flag for us and then we say I don't know that unless you're willing to back off of this and maybe start small whatever you know when people how many people I'm sure tons of you get like Facebook requests but it's slightly different but totally unique and it's going to be the next big thing and that's just a flag and I think that leads to more problems than if you're clearly outlining things prior it's like setting like a communications standard before the project begins and then reminding client constantly throughout the process I think helps get out of trouble but definitely a client will in our experience well it's like with anything if you think you can get away with something you're going to try and as a project manager we've seen in our projects if you cave to one thing that opens the floodgates for way more things getting out of whack with scope and budget I remember one time where we made the mistake it was a bigger project but we were sitting in with a client and they were kind of like oh and we would like to have this and this and we're like well okay it's a larger project it's probably not going to be that much issue with the budget and we said because it was as part of the discovery phase and they had one idea after the other and we were just writing it down and then we sent the revised estimate and they were like what happened here why does it all of a sudden like went up like 100k and we spoke with the client and we explained it and the client was saying why didn't you tell me right in that meeting that what I'm asking is so far out from what Drupal core and the contributed module are doing because if you would have set that in that meeting I would have backed off so we find that you need to in the conversations with the client to same as with putting in a percentage of like how much can be achieved of this functionality with contributed modules and Drupal core really gives the client a good idea of like where do I add like really complicated things to the whole package and we really learned from that experience to push back right away at the beginning and saying you know it's not impossible but what you're just asking here just increased your budget properly by 20,000 yeah and I think that was an instance where like the client literally said to you like I just paid you to do this discovery because you're the experts and you and he wasn't being mean about it but he said you know you wasted my time going down the list of these requirements when you knew this was going to expand the scope by 2 to 400 hours you know you wasted your time scoping out everything for something that we just don't have another you know $75,000 to add for one feature on the site it is and it could be anything from a 400 hour job to a 600 depending on how we decide to build it if you were in a position, what would you tell the client with their secret budget would you go towards the higher end or would you go to the higher end possibly obviously risk being more expensive than everybody else or risk not maximizing profitability did everybody hear that question or should I repeat it what's that so you're asking if a client has a secret budget and you want to know whether you should bid high or low if it's fixed so if you bid too low you would potentially get yourself into trouble because it's fixed but if you bid too high you might price yourself out the way from fixed budgets would be my first thing and we're not against doing fixed budgets but if a client really harps on us to do a fixed budget we'll say we'll take it time and materials and then we'll like multiply it a couple of times because we're going to pad ourselves you know to protect ourselves but from a sales perspective I would bid low but with the caveat of coming to do a discovery which I think is absolutely necessary in a fixed bid project low ball but then with giant caveats all around it saying this could go up once we go but I mean that's kind of folly in its own right I don't like playing the games of the secret budget because that signals the client that is price shopping or a commodity understanding that in business if you're in a slow time you might have to potentially take on a job but right there that's a flag where someone's being at least trying to get ranges out of client so I'm like it can be super broad but if someone won't share a budget of any kind and then so within like government type bid right so are they making you sign off on that bid once you've submitted it saying yeah like that to me is like giant red flag especially because I find governments are they'll take an RFP for something that wasn't web related at all and just change like building a shed into like replacing that with like web design just because they're working off of standard templates and we got ourselves into a lot of trouble with a city project in the US same thing where we had to sign off on the bid and they had a clear set of requirements but then once the project started it just got ballooned out of the water and we had to we had to sever the relationship at a penalty but that's a tough one and you know our stance as an agency is we won't even submit to something like that unless we've got gaps in capacity I don't think I have like a right answer for you on on that one because it is a tough one just one second well it applies to like in software you can typically get 80% of what you need for 20% of the effort or the budget to build so if you looked at something you're getting 80% of what you need and the other 20% is a relevant so if you took like microsoft word for instance it has like 10,000 features but you're probably only ever going to use 20% of them where the other 80% aren't important it's called the what is it the pathetto rule the question was to repeat kind of like the idea behind the 80-20 rule okay if I got the question right so how to manage payment and how do you manage the loans in order to show the client the progress and the project so I'd say 90% of our projects are time and materials and we have a time report system that the client has 24-7 access to and it sounds a bit vigilant but we track by the minute and our developers are required to give a description of what they've done within that time bi-weekly or a monthly basis depending how quickly the project is progressing so the client's getting a really detailed summary of everything that's been done so even if within a 1-2 weeks sprint they might not have something that seems tangible that they can get their hands on and really get into they're seeing where each minute of work is going and the status of where that particular feature is within the development cycle does that answer your question? our developers do get stuck I'm sure like everybody else I think if it's within scope and we said we could do it and then the developer gets stuck we won't charge for it we call that we'd have our developers file that under resolution so the client would never see where those wouldn't see those hours something that the client has popped in as a new requirement and research would potentially be required to figure out a solution that is typically something we'd bill for unless we knew it would take half an hour of going to Drupal.org and finding an appropriate module or what have you and also regarding that because the clients have this where the time is spent one of the important things in the beginning of working with them is that we also let them know if you expect 5 hours spent on this item and let's say 20 hours on this item it could be that the developer is a little bit quicker with this but the time saved here is spent on another one that in the end is a little bit more complicated than initially but if it really is to the point where it is because a developer doesn't know any further and no one else can and requires quite a bit of time then that would be logged as non-villable so the client wouldn't get those hours just like estimate the hours the project might have and then you set it to the scope from 200 to 300 hours and tell that to the client because most of the time the client wants to know what he's going to pay and is not satisfied with it well then might be from 40 to 50k it goes somewhere between that most of our clients say they want to know if we want to pay and then we have to we agreed to estimate but then at the end there has to be some amount of money okay so the question is regarding if a client comes and they don't necessarily have a budget they just put in the requirements and then they want to know how much that costs usually what we do there is we give them we try to to get as much information as possible beforehand before we get back with an estimate and then usually also what we have is a low, medium and high number what we think the different functionalities that they requested will be so that they get an idea of once we get into a discovery phase with a client like that we always would say like okay let's do a discovery phase even afterwards in order to make sure that we're all on the same page but then we would say like okay if this is really if we understood you right and everything is going fine and we can use module A and B for this this will take 10 hours but if it turns out that there is a little bit complication in there because it needs to work together with a different module and we might need to do some custom work there this easily could be 30 hours so they get a range like a low and high range that they have right away to get a better idea of where the risks lie in the different line items that they have and if you have this along with the percentage that you think you can handle that with Drupal Core without custom development that usually gives the clients a really good idea of where risks lie and where hours could easily go up or stay steady and then from there we would go into the discovery phase to really narrow down all of those items and to see that we are on the same page there. If the customer wants a fixed bid in that type of scenario like if what we think it's going to be is 10 hours and the worst case scenario is 20 hours we'll like fix the bid at 40 hours like we'll really really pad it because we have shown we've been able to show proof to clients where clients think that time in materials means like you say it's going to be 200 hours and you'll just run up this giant budget and by the time we're done you're going to present me with an invoice for 600 hours but we've been able to show time and time again that in a lot of cases we're coming under the hours because we have padded a little bit and that time in materials works out cheaper than fixed bid unless you've gotten yourself into a really bad fixed bid scenario where you've fixed something that you knew you shouldn't have based on the scope of the project yet like what the hours are actually tracked at and we changed to that model I think about maybe like nine months ago we refused to give an exact amount of hours anymore just because we know little things come up even if we've done our best to get all the requirements we've done the things where we'll say it won't do this it won't do that things can still come up and it's like it's I don't know it's not like you're I don't know what would be a good example it's not a commodity right like it's a service that you're doing and I find it's hard to pinpoint the exact amount of hours even if you've done the same task over and over again it's never going to be perfect so to me it just doesn't make sense to have hours and say yes this is it if you didn't want to show that range or the client is against seeing ranges then my advice would be to show them one number but it's the padded number right like the high number so the question is if we calculate the project by by hours is that okay yeah I mean I'd say 99% of the time will gather their features and requirements and by each line I don't will assign hours probably the only scenarios we don't have that is we've had a couple of government jobs in Canada where like somebody's come to us and literally said like we want this five page brochure site that we know is going to cost $2500 to build they're like but we only have a $50,000 fixed bid and in that case we'll say alright we think we can do it in 50,000 and then we'll come in at like 49,000 and make them feel good and you know the government but that's a that's a far and few between scenario it's just a little secret I'm just interested in what's the going rate for let's say a model where you charge an hour or to take an example of the smaller brochure site for example the type of site the web designer might have for example which is you know 506 informational pages maybe a portfolio section nothing particularly sophisticated obviously some of the sites but you know the going rate for something like that really or the going rate for an hour I mean we don't have blended rates or anything like that so we so depending on the project and the risk level like we have a bare minimum profitability that we have to meet but our rates are typically between 125 and 200 an hour but if but yeah Canadian but we won't like we won't quote different prices within a single quote so at the lower end sometimes we give discounts for educational institutions that are working with tighter budgets like just as an example but basically our hourly rates are a complexity of the project and when I say complexity is because we would have all senior developers on it and they bill out at a higher rate then or we're paying them a higher rate than somebody intermediate junior like a junior person can bang out a five page brochure site like that so I can typically quote on the low end using somebody like that but if it's complex we need to quote on the high end and that's strictly for like just meeting profitability right well like I said in the past couple of months we've been taking on these smaller projects from the five to 20k model we can like bang those out in like two to three weeks but our sweet spot in projects is kind of like 50 to 150,000 and those range from two to six months and the timeline can obviously vary substantially depending on how fast the customer is moving anything else Josh you got a question for us Josh yeah thanks guys