Dear Karen,

After this year of working at Peninsula Temple Sholom, I believe even more strongly in the second sentence of my original web-development quote: A vibrant, evolving, and engaged community like PTS should have a website that reflects everything the congregation is and aspires to be.

It’d be an honor to have the opportunity to continue my service to PTS by working with you to build a new site befitting Temple Sholom and its members.

What follows is a formal proposal for the project, including a description of some of the key aspects of both my process and the site I plan to build. The timeline for the project reflects a 12-week process from when I would begin this work to the actual full-launch of the site. Though there are many factors that can influence a timeline like this — and these sort of timelines are, by nature, a bit of a ‘moving target’ — I am nonetheless confident that if we stay on target, it is absolutely feasible to build this site in that time.

As I said in my previous proposal, I intend these documents to be part of a conversation. That means that this proposal isn’t written in stone, and that the plans, prices, and project parameters can be adjusted to meet any needs or limitations I haven’t considered. Please let me know if you have any questions, or if you’d like to discuss possible changes to this proposal.

Kol tuv,

Josh Mason-Barkin, rje
(after August 31:

Project Overview

Peninsula Temple Sholom (PTS), a major Reform congregation in Burlingame, California. Community members regard PTS as “an inclusive Jewish community where everyone can find peace, inspiration, and their own connection to Judaism.”

PTS’ current website utilizes the Joomla content management system and RocketTheme for page templates. It is updated (primarily) by a lay leader. The site’s templates seem to be ill-equipped to easily display more than the most basic formatting for text and images, resulting in web pages that feature textual information accompanied by links which tell visitors, “Click here to download this information in a colorful PDF file.” Furthermore, the site’s general design — though not particularly “offensive” or egregious from a graphic-design perspective — is in need of complete overhaul. A new design needs to appeal to site visitors used to websites with far more “current” and clean user interfaces, and it needs to be compatible with the smaller touch-interface screens found on mobile devices. (This compatibility would improve user experience, and would also be advantageous for the site’s search engine rank, since Google recently announced that their search algorithm would give preference to mobile-optimized sites.)

Though the congregation’s public (and internal) organizational calendars are maintained by Temple staff using the cloud-based CalendarWiz service, the embeddable calendars generated by CalendarWiz are not compatible with the site’s design templates. As a result, calendar events must be re-entered individually into the website’s backend. Presumably, this is time-consuming and it provides extra opportunities for human-error, resulting in incorrectly inputted information.

(It should be noted that PTS utilizes Google Apps for Nonprofits to provide organizational email, though the congregation does not use Google Calendars — a part of the Google Apps suite — for institutional calendaring and resource allocation. It seems that some of Google Calendars’ allocation features were unavailable when the Temple began using Google Apps, prompting the adoption of CalendarWiz for Temple-wide calendaring.)

In addition to the Temple’s main website, PTS’ preschool and youth programs / religious school each operate independent sites for their programs. These sites were created because the respective schools’ directors each needed an online space where information could be easily updated, and that offered features like multiple blogs (for preschool classes, for example) and easy file hosting for important documents (like PDF files of registration forms).

[The past year saw the creation of new, but still technically separate, sites for the preschool and religious school: and Though they are now more incorporated into PTS’ main domain, they still exist as freestanding sites, independent of]

Certainly, the religious school and preschool sites were meant to temporarily address immediate needs. (Obviously, these “sub-sites” would be part of the Temple’s main website for a number of reasons: consistency of design/branding and messaging, clarity of oversight, search engine optimization, simplification of the visitor experience… just to name a few.) But insofar as they were created in response to the insufficiencies of the main website, these independent sites illuminate some of the immediate challenges that must be addressed by a new Temple website:

  • In order for it to serve as an effective tool for disseminating information to congregants (and others) the site needs to allow for Temple staff to easily (read: in minimal time, and without requiring intensive specialized training) post updates and other important content.
  • To these degree that it’s possible, the site needs to integrate with systems currently in use by the Temple. For example: The public calendar on the site needs to automatically display designated events (and updates to them) as they appear in the Temple’s internal calendar system.
  • The site needs to offer a variety of features (and/or the flexibility to add new functionalities as needed) in order to provide staff with adequate (if not excellent!) tools for communicating with congregants. For example, the site should include the option to create multiple “blogs” like those in use for individual classes on the preschool site.
  • The site should be able to accommodate “sub-sites” for certain parts of the Temple — like the preschool and religious school — as well as for those events, programs, or other areas of the synagogue’s operation where such a functionality would be beneficial. These “sub-sites” would each have a main “homepage” (or, in actuality, a “sub-homepage”) and their own organizational/navigational structure (or “sub-nav”), and the ability to integrate unique design elements like color palettes, departmental logos, or event-specific graphics. At the same time, the existing school websites highlight the need for these sub-sites to share consistent “branding” with the rest of the Temple site. (For other examples of such “sub-sites”
  • The site needs to have a robust system for designating levels of “permission” for staff members (and anyone else with “backend” access). Such a system would allow specific members of staff — like school directors and school admin staff — to have the ability to update their own sections of the site without concern that they could inadvertently make changes to other site content.

This proposal is intended to address the challenges presented by the website’s “status quo,” and endeavors to imagine a new website for PTS that provides adequate functionality for staff and publicly presents the synagogue in the best possible light. Our imagined and intended result is a website that is well-suited to serve PTS’ needs today and far into the foreseeable future.

Goals of the Project

In my conversations with Karen Wisialowski, chief community officer, the following primary goals emerged:

1. Ease of Management.

The site needs to be incredibly simple to update and maintain. Temple staff and leadership need to be able to keep information current (and add new information) without it being a confusing, difficult, time-consuming, or technologically complicated task. Ideally, site content should integrate easily with the synagogue’s other communication vehicles (print newsletter and email bulletin, for example) so as to streamline staff workflow. (See #4, below, for more on this.)

Furthermore, the site needs to allow for certain staff and lay leaders to manage their own sections of the site (or “sub-sites” in some cases). Currently, the religious school and preschool are operating their own sites using an outside web provider. The new site should negate the need for this sort of segmentation, while allowing for certain areas of the site to be ‘semi-autonomous.’

2. Telling PTS’ Story.

The new site needs to effectively reflect the unique qualities of Peninsula Temple Sholom, with an emphasis on the congregation’s mission and core values.

In order to achieve this goal, the site also needs to convey the enormous range of programs and opportunities for community engagement at PTS while at the same time presenting the synagogue as a cohesive community. Given that the site needs to allow for (at least a few of) the aforementioned ‘semi-autonomous’ areas/sub-sites, the larger site design needs to have a naturally (even effortless) sense of visual consistency.

3. Accessibility of Information (for All Site Visitors).

One of the site’s primary objectives is to be a clearinghouse of information for Temple members. That information needs to be simple for site users to find, organized as intuitively as possible, and easy to use.

Furthermore, non-members (especially prospective members) visiting the site need to be able to quickly find relevant and accurate information about the Temple. The site needs to be simple to navigate, while projecting warmth, inclusivity, excitement, and professionalism.

There are perhaps numerous sub-groups within these primary audiences (members and non-members). From a “big picture” perspective, however, the site redesign’s focus may be understood as a balancing act between these two. In many (perhaps most) cases, the needs of both groups are similar (if not identical) or complementary. For example, both members and non-members require site navigation that’s intuitive and clear. In areas where the needs of each audience differ, the site’s design and organizational structure need to be flexible enough to effectively serve both.

4. A Tool for Temple Management

The site needs to serve as a primary tool for various aspects of the Temple’s communications and day-to-day management. Wherever possible and prudent, it needs to incorporate existing administrative tools (the synagogue database, email system, calendaring and room/resource management, online forms, event RSVPs, etc.). In cases where it makes sense, the site may incorporate solutions that replace some existing tools. Regardless, the site needs to integrate with existing systems organically and with minimal ‘friction.’

How We Work

The Motech Agency Approach to Website Projects

Before jumping into the proposal itself, you should know a little about how we work on websites.

Our process is based on four principles:

1. Listen

A great synagogue website needs to tell a story and it also needs to be a workhorse. It needs to successfully convey what makes a place special, it needs to ‘fit’ the character and culture of the community, and all the while it needs to effectively accomplish all the functions imagined (and not yet imagined!) by the committee behind it. Of course anyone in my line of work needs to be good at listening to the needs of the client (and good at delivering a product that meets those needs). But, because it needs to accomplish multiple goals, and because synagogues are such unique institutions run by diverse groups of people, the success of a synagogue website is almost entirely dependent on the capacity of the person building and implementing it to listen to the people making the investment.

2. The Big Picture Matters

A website doesn’t stand alone. (Or at least it shouldn’t.) Rather, it’s part of a synagogue’s broader communications strategy. The point is that the website needs to work in concert with printed communication like newsletters and bulk mailings, e-newsletters and e-blasts, and every other medium by which the synagogue communicates to members and potential members.
Of course that means that there should be consistent ‘branding’ that permeates all those things: fonts, logos, colors, and other elements that contribute to ‘look-and-feel.’ It also means that there should be a consistent voice, a ‘vibe’, and a tone to the messaging. Branding is part of that, but it’s just one ingredient.

A website tells a story, and good storytelling is about a lot more than the words (and the fonts, colors, and logos).

Our outlook is predicated on the notion that a good designer works with the client to develop a holistic understanding of the narrative(s) that the website is helping to convey. Then, it’s our job to build a website that accomplishes exactly that.

3. Revise All the Time

Many designers and design agencies provide (contractually) for one or two stages of feedback and revision. It makes sense for them because they need to protect their time and resources, and they can’t go back-and-forth forever.

We don’t work that way. We won’t consider the project done until it meets your expectations.

It’s the developer’s job to make sure he’s listening to the client, and to maintain clear and open communication so that he’s not surprised to find out the client would like something to be different. For that reason, we don’t set aside specific periods for revision, and we don’t see the revision process as something that needs to be limited, or that even can be quantified. It’s all revision. (Our proposed pricing reflects this. We won’t charge you extra for time spent making you happy if it exceeds some predetermined time limit. With few exceptions, we work on contract, not by the hour.) We choose to work with clients who are a good fit for this style, and who won’t bog the project down with unreasonable expectations.

4. Commit to Longterm Success

Our web design/development agreements always include training for staff (and/or lay leadership, if applicable) and a significant period — at least six months, and in most cases one year — of technical support, site maintenance, ongoing tweaking, and general problem-solving. If we build a seemingly-amazing site that synagogue staff can’t maintain, then we haven’t done our job. (And the site won’t seem amazing, or even adequate, for very long.) We’re committed to your success as you move forward with your new site, and we promise to be there to help for the entirety of the initial “break-in” period.

The Proposal:Core Offerings


This proposal is for the creation and implementation of a WordPress-based website. WordPress is a free content management system (CMS). That means it’s software that is installed on your server, managing your site’s content as well as the “theme” that determines the site’s look-and-feel and any other site-based functionality/features. Though there are many choices for a CMS to manage a site like this, WordPress is an ideal choice for PTS’s site because:

It’s simple yet powerful. WordPress is incredibly easy to use because it’s based on an intuitive interface (things are where you’d expect them to be) that emphasizes simplicity and is designed to be learned quickly. On the other hand, WordPress is extremely robust and powerful. It can be used to manage massive sites integrated with enormous user databases and e-commerce solutions. This unique balance of simplicity and power make it an ideal choice for many synagogue and non-profit settings.
It’s extensible. WordPress has a built-in plugin system that allows site managers to add a virtually infinite number of functionalities and features to their website: e-commerce, image hosting, registration and donation forms, and integration with most cloud-based services (to name just a few). This system has two important advantages for PTS. First, it means that the site’s future functionality isn’t limited by what we build now, but rather that it’s easy to add functionality as needed. Second, it means that it’s relatively simple (and inexpensive) to integrate the site with other services like mass email providers, file hosting services, payment processors, and more. (PTS’s current mass email provider and credit card payment system can be integrated into WordPress, making it easy to use the website for email list management and to receive online payments and donations.)
It’s ubiquitous. WordPress is the world’s most popular CMS (by a longshot). As a result, it’s easy to find WordPress developers and site management experts, and there are numerous resources available for WordPress to find training and support. That’s an advantage for PTS because it means the synagogue isn’t ‘locked in’ to working with the Motech Agency for future site needs (since WordPress developers are easy to find), and doesn’t require finding a highly-specialized (and therefore expensive!) web developer every time something needs to be adjusted or fixed.

Aspects of Website Development

WordPress CMS Installation & Implementation

The Motech Agency will install the WordPress software package on PTS’ web server (though initially, we’ll develop the site in a private “development space” and then move it onto PTS’ server when it’s ready to launch). We’ll create pages and configure user permissions for staff and leadership. We’ll also install and configure systems for high-level security, backup, and spam-protection.

“Bespoke” WordPress Customization

WordPress utilizes a modular system of “themes,” which allow site managers to change the look and functionality of a website without altering the information content or structure of the site. That means that the site’s customizations can be built as part of this theme framework, and that future customizations to site appearance or functionality can be easily added without major alteration to site content.

As part of the customization process, the Motech Agency will:

  • Select and install WordPress plugins to enable specific functionalities required. If necessary, develop custom plug-ins to meet these needs.
  • Design customizations to an existing theme or develop a custom theme. (Assessment of which option is preferable will depend on specific site needs and design parameters.)
  • Install and implement the theme.

Dynamic Content

In addition to “static” pages for general site content, WordPress allows for sections of the site to be populated with dynamic content (news, blog posts, upcoming or recently-past events, etc.). The PTS site will utilize this functionality (using WordPress’ “custom post type” architecture) to create dynamic sections of the website that will be configured to automatically show the latest information. PTS staff and leadership will also have the ability to post content (text, pictures, video, calendar events, links, etc.) via email or mobile app, and will be able to utilize user permissions to designate various levels of site updating abilities to different individuals.

Furthermore, we’ll be able to designate specific site sections (or even specific content) in which site visitors may add comments. (This functionality allows for full moderation, and can also be turned off by default.)

“Sub-Sites” & Multiple Blogs

In order to address the need for semi-autonomous site-within-a-site sections for departments like the religious school and preschool, the site will provide the ability to create sub-sections (or “sub-sites”) within the main Temple site. These sub-sections will be able to utilize separate (though graphically similar) sets of page templates (including designs for unique features, like school forms or class blogs) and their own organizational/navigational structure.

[In order to implement this functionality, we will utilize WordPress’ Multisite feature, which provides the ability to create separate-but-interrelated websites under the auspices and management of a single website. This allows for “sub-sites” to function independently, while maintaining a singularly maintained “web space” for the entirety of the Temple site.]

Furthermore, the site will include tools for creating and maintaining multiple “blogs” (or: collections of dynamic, frequently-updated content) on an as-needed basis. These can be used for a virtually infinite number of purposes, including classroom communication (as currently employed by the preschool), podcasts, clergy sermons and articles, musical/liturgical content (including uploaded sound files), and categorized Temple news.

The Motech Agency will port existing “sib-sites” over to the new website (as individual Multisite sub-sites), allowing them to be managed from within the main WordPress Multisite environment:

Calendar Implementation

CalendarWiz, which PTS currently uses for managing the Temple’s public calendar, is a workable calendaring solution, but it falls far short of ideal:

  • Though the calendar can be embedded via iframe on any web page, it offers very limited options for graphic customization, resulting in the need for PTS to use a totally separate calendaring system for the public web calendar.
  • The embedded calendar is not responsive.
  • CalendarWiz does not properly implement the ICAL protocol. As a result, calendar subscriptions don’t work as they should. (In particular, multi-day events and multi-category events are handled improperly.)
  • CalendarWiz’s user interface is kludgy and awkward at best.

Utilizing existing WordPress plugins, we would implement a calendaring solution that integrates perfectly with the website and has none of CalendarWiz’s shortcomings.

This includes the following:

  • Implementation of the calendaring system, which includes robust venue management, full ical (calendar subscription, “add to my calendar”) functionality, and total website integration.
  • Training for staff members in calendar usage, including assistance integrating with Google Calendar.
  • Full import of existing calendar data into the new system.

SEO Optimization

The PTS site will be built to maximize search engine visibility. The Motech Agency will implement strategic tools for SEO that maintain this optimization and allow flexibility for future SEO needs. This aspect of site development includes ensuring that all elements of the site utilize customizable SEO-friendly metadata.

Development Environment

During development, build the entire site within a (password-protected) construction environment, enabling the ability to test and preview all aspects of site development before launch. When ready, we’ll move the entire site (preserving SEO optimization and related metadata) to the live server.

Aspects of the Graphic Design Process

Fonts, Colors, Aesthetic Styles

We’ll design the website’s “look” to be fully consistent with the congregation’s “visual identity.” We’ll adapt PTS’ existing branding guidelines (fonts, colors, etc.) for web usage to create a web style that’s consistent with the Temple’s printed graphics.

Site Mockups & Site Design

In preparation for site development, The Motech Agency will undertake an iterative design process in collaboration with PTS’ team. We’ll create visual representations of the site’s design (sometimes referred to as “wireframes,” but that term is used in so many ways by site designers that its usage can be confusing) and we’ll keep editing and adjusting those designs until they meet the PTS team’s approval. Then, we’ll turn the final mockups into the design for the site itself.

Mobile-Optimized Design

By implementing a “responsive” site design, the PTS website will be fully optimized for visual clarity and usability on mobile devices. We won’t be building a separate set of “mobile templates” that result in having a mobile version of the site. Rather, the site will be designed to effectively scale to different viewport sizes utilizing CSS media query. (For a thorough discussion of this concept, see Ethan Marcotte’s excellent and definitive article, “Responsive Web Design.”)

Other Aspects of Site Production

Internal Systems Consultation

Before launch, we’ll consult with Karen (et al) on the development of internal systems for maintaining and updating the site. We’ll help configure workflows, tweak user settings and permissions, and advise the process so that a year after project completion, the site still looks and feels as great as it did when it was first launched and that it continues to serve the congregation’s needs without placing undue burdens on staff and volunteers.

Training & Continued Support

The Motech Agency will provide full training to any PTS staff members or lay leaders who will be involved in managing the site and/or posting site content. We’ll customize our training to meet the specific needs of the site users being trained, and we’ll provide ongoing technical support and assistance for the first six months (or for the first year, see “Pricing Options”, below) after project completion. Further support will be provided based on an agreed upon retainer plan or on an hourly basis.

Technical Guarantee

The Motech Agency will guarantee the operation of the site and all its installed components (as configured by us) for five years after product completion. During that period, any repairs or necessary updates will be completed in a timely fashion and at no cost to PTS. Repairs, updates, and site additions beyond the scope of the initial site installation will be quoted on a case-by-case basis and/or billed at the rate of $100 per hour.

Site Development Timeline

Following is a proposed timeline for site development. It is intended to be flexible (to allow for Jewish holidays, for example), and it represents an initial conceptualization. A more final timeline would take into account a number of other factors (to be determined after consultation with PTS staff).

(Swipe right to browse the table on mobile devices.)

MilestoneDate in Weeks(“Week 1” means one week from the start date of the project)

Submission of first mockups for PTS team’s review. Mockup feedback session.


Final mockups submitted and approved.


Theme development and WordPress configuration. Beginning of content migration/integration process.


Edits/additions to site content due from PTS.


Continued theme/template development. Plugin configuration. External integrations configuration.


Continued theme/template development. Internal systems consultation with Karen. User roles configuration.


Soft launch of site for final content migration and “break-in” period.


Trial/“break-in” period. Site tweaks, adjustments, and additions. Initial staff training (for staff/laity with main web responsibilities).


Launch. Staff training (for remaining staff).


Optional Add-Ons

The following are modular aspects of the web development project that may be added-on. Note: Incorporation of any of these may affect the project timeline.

Option: Members-Only Community Portal


buddypressUsing a package of add-on software called BuddyPress, it’s possible to implement a “social networking” platform within a WordPress-based site.

While technically capable of offering many features similar to a social network like Facebook, Buddypress’ capability for full customization allows for the implementation of more limited “social” functionality. In other words, we can create a protected, members-only area of the website in which PTS members could maintain personal profiles, interact with other members, and download protected content.

This sort of implementation is not without potential tzuris, but the potential payoff in added interactivity could be enormous.

Please note: This system can be implemented with varying degrees of complexity and capability. Most of the specifics (beyond the basics, detailed below) could be determined after some initial discussion.


This optional add-on would include:

  • Implementation of a BuddyPress-based members-only portal.
  • Configuration and customization of BuddyPress features and functionalities, per PTS’ needs.
  • Consistent design of the portal’s member-facing graphical elements.
  • Implementation of site user management system (logins/passwords, a server-based auto-reset for members who lose their password, etc.; necessary for BuddyPress )

Background Info

More About BuddyPress

BuddyPress is an open source social networking software package owned by Automattic (the folks behind WordPress) since 2008. It is a plugin that can be installed on WordPress to transform it into a social network platform. BuddyPress is designed to allow schools, companies, sports teams, or any other niche community to start their own social network or communication tool. BuddyPress inherits and extends upon the integral functional elements of the WordPress engine including themes, plugins, and widgets. As it is built on WordPress, it is written using the same primary technologies, PHP and MySQL. It includes all of the features you’ve come to expect from any online community, like user profiles, groups, activity streams, notifications, and more.

Some example uses:

  • Campus wide social-network for universities, schools, and colleges.
  • Internal communication tool for companies.
  • Niche social-networks for very specific interest groups.
  • Focused communities for products & services.

You can learn more about BuddyPress at the project’s homepage.

Proceed With Caution

There are a lot of reasons why creating a members-only “online community” is an attractive option. (And we’d be excited to build it.) But it’s also important to note that maintaining a functional, vibrant, worthwhile online communal space requires consistent attention, carefully considered policies, skillful and politically-savvy moderation, and an immense amount of hand-holding/cheerleading/persuading. We encourage our clients to take on such a project after thoughtful consideration and with as much clarity as possible.

[If for those reasons, or any others, you’d like to designate this specific feature for implementation at a later date, it still might be worthwhile to build the system now (with the ability to “activate” it when you’re ready). Though BuddyPress can certainly be added-on to an existing site, sometimes there are significant savings in development/design costs when it’s implemented from the beginning. In other words, the price quoted below is for building this functionality as part of initial site development. It will likely cost more to add it at a later time.]

Option: Online Workspace for Leadership


workspaceImplementing the functionality to host online workspaces for Temple committees would look similar to the Community Portal option (above), except it would feature tools specific to committee work like robust document sharing, sophisticated privacy controls, live note-taking (for use during phone meetings, for example), committee calendaring, and various options for grouping committee members (like: the ability to create hierarchically-organized workspaces to reflect sub-committees and ad-hoc committees of a single “parent” committee).


See the “Specifics” listed in the Community Portal option, above. Technologically, this is essentially a simpler version of a Community Portal, with the main difference being one of scale. Whereas a member portal requires constant management, policy enforcement, etc., using a similar sort of tool for the more limited scope of committee management may be more sustainable in the near future because the total user base is much smaller (and more personally engaged). Furthermore, implementation of such a toolset might have immediate benefits in that it could bring consistency and central management to committee communications.

Important Details

Expectations of the Client

We’ll need a few things from you.

Content Collation

PTS will be responsible for collecting and organizing site content (whether it’s existing content to be migrated or new content to be generated), including text, photographs, and graphical elements.

An important note: In our experience, lack of clarity and/or organization around site content is a major reason for delays to the site development timeline. If you're committed to staying on schedule, our recommendation is to make sure you really stay on top of gathering, generating, editing, and organizing the text and images that we'll need in order to build the site.

Consistent Communication Loop

We’d like to work with a small (3-5 people) group of lay and/or professional leadership on the ongoing progress of the site. This group will give feedback about design and will sign-off on any decisions to be made. (Alternatively, we can work with a single person who can sign-off of any decisions.)

In our experience, this process is enhanced by the use of an online project management platform, which allows the entire team to keep track of progress, assign “to-do” items, and share files, notes, and other information. We highly recommend Basecamp, which costs $20 per month, and can be discontinued at the end of the project. (We’re happy to set up an account and include the cost in your invoice.)


  • Payment should be made in the form of a check made out to The Motech Agency.
  • For additional work outside the scope of agreed-upon work, the Motech Agency charges $100/hour. We'll provide a basic time estimate before undertaking such work. (Additional charges will apply for anything that requires additional personnel or outside equipment rental. Those charges can be discussed if a potential need arises.)
  • For all web development work, an initial payment of 50% is due at the time of agreement. (We'll begin work upon receipt of this payment, which is not a deposit. It is payment for expenses and services rendered, as well to cover the unlikely event of The Motech Agency incurring liquidated damages as the result of client cancellation or postponement.) The balance is due on completion.

Pricing Options

(Swipe right to browse the table on mobile devices.)

  Basic Web Package à la carteMember Portal à la carteOnline Workspace Complete Package
Installation and custom-configuration of WordPress on client webserver    
includes full server/DNS configuration
custom types for dynamic content    
custom template design    
implementation of existing calendar    
development of new integrated web-based calendar system    
creation of a protected, members-only area of the website  
creation of leadership/committee online workspaces  
full search engine optimization (SEO)    
implementation of branding elements (Fonts, Colors, and Aesthetic Styles)    
creation of Stylesheet and Web Usage Guide    
mobile-optimized responsive design    
compatibility with existing internal workflows    
Training & Continued Support
6 months
one year
technical guarantee for operation of the site and all its installed components
five years
five years
ongoing tweaks, adjustments, edits
Cost $13,000 $2000 $2000 $17,000

An Important Note About the Add-Ons

The pricing listed here — especially the ‘Complete Package’ — reflect the fact that it’s easier to create the member portal and/or online workspace if we are able to put the necessary foundational pieces in place during the initial site build. Even if we know that those pieces will be implemented at a later date and that most of their development will happen at that time, if we know that they’re part of the long-term plan, we can save ourselves significant time and energy by including designated space for them as we create the site’s internal structures.

It’s very easily comparable to running electrical or network cabling in a building: Doing so during initial construction is much simpler, easier, and cleaner than adding new wiring inside already-finished walls.

As a result, if it’s clear that PTS will want one or both of these features, it may make sense to pay for them now, because the prices listed above reflect the cost savings related to ‘running the wires during construction.’ Not including them now and adding either (or both) at a later date is certainly possible, but will undoubtedly cause the price of both add-ons to increase significantly and the timeline for their implementation to be extended.

Ready to get started?Questions?

Give us a call.