Bridging Your Web App and Marketing Site

The rockstar combination to connect your marketing website and your web application without sucking the joy out of life.

If you’ve launched a software product, you’ve undoubtably felt the friction between your tech product and the marketing website.

If you’re managing software engineers or sales people, you’ve heard their cries. On one hand, updating the marketing website is a vital part of keeping prospective customers informed. At the same time, it can feel like a waste of time and money for a software engineer to push content changes when the backlog of bugs or features is a mile long. There is a constant tension between work that needs doing and eager people pursuing meaningful work.

We’ve wrestled with ourselves, with clients, and product teams for years about this dilemma.

  • Do we build the marketing site into the product?
  • Do we have two systems that talk to each other?
  • Can we build something static?
  • Should use use a Content Management System (CMS)?
  • Which CMS should we use?
  • Should we just build the CMS?
  • How often will we need to make edits?
  • …the list goes on

It seems trivial to some, but to Chief Marketing Officers, Chief Technology Officers, or Product Owners it can feel like a battle. Each option, regardless of how viable, has a never ending list of tradeoffs.

We’ve tried them all.

At Polar Notion, our site is static html. At Sharpp, our SAAS product, the marketing site is baked into the app. At New Story, we’ve gone from CMS to static site and back again. For hundreds of projects over nearly a decade, we’ve created combinations everywhere in between. With each attempt, I’ve witnessed the pressure, the drawbacks, and the pains that emerge.


To determine if this is truly a problem for your team, here are symptoms we noticed that you might be experiencing too:

  • Content Cards (website copy change requests) for Engineers.
  • Outdated website copy.
  • Sales and Marketing team members can’t change images or copy.
  • Multiple people have to be involved in making edits.
  • Traffic spikes to your homepage reduce app performance.
  • Your team or advisor page is outdated.

Solving the Problem

In 2017, the teams at New Story and Polar Notion co-created the best solution yet. After more than a year with a static site which required individual deployments to make changes, the growth of the New Story’s team necessitated a different approach. We couldn’t continue bogging engineers down with copy and image changes, but more people than ever wanted website edits.

The landed on a solution we’ve been very pleased with. Months after the solution has been implemented, the results include:

  • Simple execution of site changes
  • Zero Engineer effort on marketing site
  • Access for nontechnical team members
  • Website copy is more up-to-date than ever
Photo by Chris Becker

Here is how it worked

  1. We redesigned the marketing site. Consistency is key for a greater user experience and a powerful CMS, which is where this story is heading. This step may not be necessary for everyone, but it prevented us from institutionalizing inconsistency.
  2. We looked at the site in terms of sections, not pages. Rather than treating each page like a snowflake, we strived to create a core list of components. The uniqueness would emerge from changing colors, images, and content…not reinventing the wheel.
  3. We developed the entire marketing site, static first. Without having to deal with the pains of a CMS, we were able to QA and polish things quickly. This allowed us to remove inconsistencies in the design and built a customer-centered experience. Since we knew this one only temporary, we built it using php partials which converts almost seamlessly into Wordpress.
  4. We wrote custom integrations to the web application. There are a few areas throughout the marketing site that pull live data from the database of the web application. We created public endpoints that served up the data and built a lite bridge between the two systems. In most cases, a simple link between systems does the trick.
  5. We converted the static site into a custom Wordpress theme. This gave us complete control of implementation. We pulled out key areas that get edited often and made custom post types that had isolated behaviors. This step is the capstone of the project, be wise. Use an existing theme and you’ll likely regret it. Hack apart a theme with your needs changes, you’ll regret it. Get your cousin’s, boyfriend’s brother to take a crack at it because he’ll cut you a deal…regret. This is not necessarily the case for traditional companies, but tech companies need to take extra precautions here.
  6. Now on Wordpress, we deployed the marketing site to WP Engine. Though we’re not paid by WP Engine, there service is worth noting because it addresses a number of the drawbacks we have experienced in the past with Wordpress. Optimized for Wordpress, their sites function great and spinning up other environments is a breeze. One click additions of SSL certificates and caching services further reduce the weight of management. Distributing the load and hosting the marketing site off our servers makes it easier to handle spikes in traffic and engagement. Finally, security. Every one of WP Engine’s customers is on Wordpress which incentivizes them to keep their eye on the ball. Rolling your own Wordpress hosting may seem easy but you’ll pay long term.
  7. We setup subdomains. The app lives on the same base domain but a different subdomain than the marketing site. ‘’ and ‘’ can be a nice combination where few notice but none seem to care.
  8. We got back to work. For most roles within a product team, editing the marketing website is wasted effort. If should be fast and easy so everyone can get back to working on the areas that provide the most value to the customers and the organization.

The Tech Overview

  • Web Application (or Mobile App, though it would look a little different)
  • Customer Wordpress Theme
  • Javascript to bridge Wordpress and App
  • Hosted on WP Engine


Like any problem, the best solution will vary greatly based on what you’re optimizing for. For product companies and SAAS businesses, a solution that requires zero-engineering effort should be strongly considered.

The more we’ve sought to maximize everyones’ strengths and passions, the more impactful this solution has become.

If you’ve got more technical questions or what to see a demo of this rockstar in action,


It was not ‘cheap’ but it was the least expensive. It took some upfront costs. To lighten the burden on the New Story team, Polar Notion handled the Wordpress work and WP Engine configuration. The opportunity costs of New Story trying to handle in house would have been far greater than short term contractor costs. Factoring in the mental freedom this decision has yielded over the last 6 months and it’s safe to save we could have paid three times as much and still got a deal. Pay nor or pay later, as always.

You need a solid wordpress theme. Polar Notion built a custom theme for New Story specifically designed for a rapidly evolving startup environment. Team Members and Job Openings are custom post types that making adding and removing entries painless.