First of all, let’s unpack the question: What's cheaper?

It’s hard to explain to someone (ie. a client) that the more you conceptualize what needs to be built, the cheaper it will be. In other words, having a dedicated and thorough discovery session. In this session the goal is to understand exactly what the expectations are and how to streamline the project. This should be paramount to simply jumping into client demands.

But we are realistic. And in reality, we all have limited time, budget, attention spans and patience.

If a client and their team is willing and able to put in their own time to lower costs, they should be encouraged to do so. These roles should be itemized and evaluated in a contract before that work is started. Asking how to help is, after all…helpful.

Here are some ways for you (the client) to get involved:

Before the discovery phase:

Know your goals. Brush up on your business plan and your brand values. Consult with your stakeholders to understand the key problems we’re here to solve and what you need your new software to accomplish. The clearer you can be with your goals the less time we will spend in discovery teasing them out.

Think Ahead. Adequate foresight and effort upfront can save you time and money in the long run. Is your online shop designed to accommodate the number of products you’ll have now, or will it grow with you to accommodate the number you plan to have in a few years? Is your hosting package large enough to support the number of users you hope will sign up for your app in the next year? Three years? For any decision-making requiring speculative features the enterprise might need in the future, consult as many stakeholders as possible so you know that everyone’s needs will be met before you start building.

What you like and what you don’t. Conduct an internal team brainstorming exercise to generate a list of examples of websites or applications you like. Detailing the reasons why you like certain features is just as important. Coming up with examples of things you’d like to avoid is helpful too. By providing a clear and detailed document before the discovery phase will put everyone a step ahead.

Have your branding materials ready. If rebranding or a brand refresh is part of the project, this would be a good time to generate new photography assets as well. It might be a larger upfront cost, but worth rolling it in. (See our post on High Quality Brand Imagery).

Does it stay or does it go? Do an inventory and site audit to identify what content is still relevant and what can be archived. Assess whether new content could live in existing components and templates or if custom updates are necessary.

Encourage a two-contract process. This simply breaks down the daunting task of a large web development project into parts: discovery and fulfillment. Thus allocating adequate time and effort to each phase. (See our post on Contracts - From Discovery to Fulfillment)

Before the design phase:

Optimize your assets. Compressing image files before sending them as a large zip file is often neglected. This is a very simple task that doesn’t take a full stack development firm to do, and there are various free websites that will let you do it without hassle. Compressing visual assets allows for optimal performance of your software; properly sizing images for the web will ensure good loading speeds.

Prep your design files. You can save a lot of time up front by having everything the design team needs prepped, ready to go and easily accessible. Folders sent with clear file names that reflect the content of the images will boost SEO and save time the designer would take doing it. Or if you’re doing your own content entry, maybe sure all assets are organized and uploaded into your content management system. With ALT text. Have any and all design assets organized, compressed, and compressed again into a zip folder. Before sending it over make sure there’s nothing left out. Here's what could be included:

• Brand guidelines
• Style guide
• Font files
• A document listing examples of other websites or applications you like and why
• Individual SVG files (if they exist). Designers can easily convert these to PNG, JPEG as needed
• Any assets in their original Photoshop or Sketch files. This gives easy access to all layers for the designers. (Yes, this may contradict sending large asset files, but could be worth it).
• Existing or new photography, ideally optimized/compressed (here's a free image compressor tool).



Block off enough time for your project. Being available to field any questions, give feedback, and approve mockups is vital. If turnaround time for design review/reiterations is quick, there will be less temptation for a designer to take stabs in the dark to meet a completion deadline.

Throughout and after development:

Plan for content strategy. Make use of the skills in your company. Do you have a copywriter as part of your marketing team? A business strategist? Social media expert? Intern? For projects that involve migrating large amounts of content from an old site to a new one, the roles for content entry must be clear early on. If there has been a brand pivot with your new site, this could be a great chance to update content to match a new direction. Many software firms will offer content entry as a service as well, but opportunities may be missed and chances are it will cost more. Doing content entry yourself is also a great way to get to know your new site or application and thoroughly test it out.

QA and testing, testing, testing. This step can make or break software...literally. In fact, you should gather as many team members as possible to do just that: break what’s been made. This is how you conduct thorough QA and ultimately improve the quality of the product. Divide and conquer. Explore all possible nooks and crannies. Having people who aren’t necessarily familiar with the software test it out can give new perspectives. Just make sure this is done before the final product is shipped ;)

Stick to the plan. Change orders are inevitable. It's part of the process to think of the future iterations of what is being built. However, keeping a simple and concise statement of work is much more preferred and quite rewarding. Constant change in direction can quickly rack up the cost, slow down delivery dates and even derail an entire project. Anyhow, if there are still major decisions being made at the development stage, it’s often a symptom of ill-planning.

We train you, you train you. Knowledge is power. Being present throughout the entire build process will benefit your organization in ways difficult to explain. And once completed, a final training session should be provided by the team who built it. Familiarizing as many people on your team with your new piece of software will only empower it as a tool, and them as team members who can use it. Having someone in house who knows the company’s website inside and out means less maintenance fees; but having many people know how to use the website is the true key to its success.