summaryrefslogtreecommitdiffstats
path: root/docs/content/en/showcase
diff options
context:
space:
mode:
Diffstat (limited to 'docs/content/en/showcase')
-rw-r--r--docs/content/en/showcase/1password-support/bio.md5
-rw-r--r--docs/content/en/showcase/1password-support/featured.pngbin0 -> 165718 bytes
-rw-r--r--docs/content/en/showcase/1password-support/index.md39
-rw-r--r--docs/content/en/showcase/aether/bio.md9
-rw-r--r--docs/content/en/showcase/aether/featured.pngbin0 -> 275219 bytes
-rw-r--r--docs/content/en/showcase/aether/index.md39
-rw-r--r--docs/content/en/showcase/arolla-cocoon/bio.md6
-rw-r--r--docs/content/en/showcase/arolla-cocoon/featured-template.pngbin0 -> 451984 bytes
-rw-r--r--docs/content/en/showcase/arolla-cocoon/index.md29
-rw-r--r--docs/content/en/showcase/bypasscensorship/bio.md6
-rw-r--r--docs/content/en/showcase/bypasscensorship/featured.pngbin0 -> 180903 bytes
-rw-r--r--docs/content/en/showcase/bypasscensorship/index.md24
-rw-r--r--docs/content/en/showcase/digitalgov/bio.md2
-rw-r--r--docs/content/en/showcase/digitalgov/featured.pngbin0 -> 65077 bytes
-rw-r--r--docs/content/en/showcase/digitalgov/index.md66
-rw-r--r--docs/content/en/showcase/fireship/bio.md6
-rw-r--r--docs/content/en/showcase/fireship/featured.pngbin0 -> 136959 bytes
-rw-r--r--docs/content/en/showcase/fireship/index.md17
-rw-r--r--docs/content/en/showcase/flesland-flis/bio.md8
-rw-r--r--docs/content/en/showcase/flesland-flis/featured.pngbin0 -> 309284 bytes
-rw-r--r--docs/content/en/showcase/flesland-flis/index.md24
-rw-r--r--docs/content/en/showcase/forestry/bio.md5
-rw-r--r--docs/content/en/showcase/forestry/featured.pngbin0 -> 227009 bytes
-rw-r--r--docs/content/en/showcase/forestry/index.md48
-rw-r--r--docs/content/en/showcase/hapticmedia/bio.md1
-rw-r--r--docs/content/en/showcase/hapticmedia/featured.pngbin0 -> 543922 bytes
-rw-r--r--docs/content/en/showcase/hapticmedia/index.md33
-rw-r--r--docs/content/en/showcase/hartwell-insurance/bio.md6
-rw-r--r--docs/content/en/showcase/hartwell-insurance/featured.pngbin0 -> 446603 bytes
-rw-r--r--docs/content/en/showcase/hartwell-insurance/hartwell-columns.pngbin0 -> 89018 bytes
-rw-r--r--docs/content/en/showcase/hartwell-insurance/hartwell-lighthouse.pngbin0 -> 9025 bytes
-rw-r--r--docs/content/en/showcase/hartwell-insurance/hartwell-webpagetest.pngbin0 -> 11653 bytes
-rw-r--r--docs/content/en/showcase/hartwell-insurance/index.md69
-rw-r--r--docs/content/en/showcase/keycdn/bio.md1
-rw-r--r--docs/content/en/showcase/keycdn/featured.pngbin0 -> 358740 bytes
-rw-r--r--docs/content/en/showcase/keycdn/index.md30
-rw-r--r--docs/content/en/showcase/letsencrypt/bio.md3
-rw-r--r--docs/content/en/showcase/letsencrypt/featured.pngbin0 -> 147459 bytes
-rw-r--r--docs/content/en/showcase/letsencrypt/index.md21
-rw-r--r--docs/content/en/showcase/linode/bio.md4
-rw-r--r--docs/content/en/showcase/linode/featured.pngbin0 -> 90149 bytes
-rw-r--r--docs/content/en/showcase/linode/index.md15
-rw-r--r--docs/content/en/showcase/over/bio.md5
-rw-r--r--docs/content/en/showcase/over/featured-over.pngbin0 -> 194841 bytes
-rw-r--r--docs/content/en/showcase/over/index.md17
-rw-r--r--docs/content/en/showcase/pace-revenue-management/bio.md4
-rw-r--r--docs/content/en/showcase/pace-revenue-management/featured.pngbin0 -> 298908 bytes
-rw-r--r--docs/content/en/showcase/pace-revenue-management/index.md28
-rw-r--r--docs/content/en/showcase/pharmaseal/bio.md7
-rw-r--r--docs/content/en/showcase/pharmaseal/featured-pharmaseal.pngbin0 -> 769739 bytes
-rw-r--r--docs/content/en/showcase/pharmaseal/index.md37
-rw-r--r--docs/content/en/showcase/quiply-employee-communications-app/bio.md4
-rw-r--r--docs/content/en/showcase/quiply-employee-communications-app/featured.pngbin0 -> 631206 bytes
-rw-r--r--docs/content/en/showcase/quiply-employee-communications-app/index.md29
-rw-r--r--docs/content/en/showcase/small-multiples/bio.md3
-rw-r--r--docs/content/en/showcase/small-multiples/featured-small-multiples.pngbin0 -> 374273 bytes
-rw-r--r--docs/content/en/showcase/small-multiples/index.md47
-rw-r--r--docs/content/en/showcase/stackimpact/bio.md4
-rw-r--r--docs/content/en/showcase/stackimpact/featured.pngbin0 -> 153794 bytes
-rw-r--r--docs/content/en/showcase/stackimpact/index.md16
-rw-r--r--docs/content/en/showcase/template/bio.md8
-rw-r--r--docs/content/en/showcase/template/featured-template.pngbin0 -> 41270 bytes
-rw-r--r--docs/content/en/showcase/template/index.md22
-rw-r--r--docs/content/en/showcase/tomango/bio.md6
-rw-r--r--docs/content/en/showcase/tomango/featured.pngbin0 -> 143336 bytes
-rw-r--r--docs/content/en/showcase/tomango/index.md29
66 files changed, 782 insertions, 0 deletions
diff --git a/docs/content/en/showcase/1password-support/bio.md b/docs/content/en/showcase/1password-support/bio.md
new file mode 100644
index 000000000..9187908d9
--- /dev/null
+++ b/docs/content/en/showcase/1password-support/bio.md
@@ -0,0 +1,5 @@
+
+**1Password** is a password manager that keeps you safe online. It protects your secure information behind the one password only you know.
+
+
+The [1Password Support](https://support.1password.com/) website was built from scratch with **Hugo** and enhanced with **React** and **Elasticsearch** to give us the best of both worlds: The simplicity and performance of a static site, with the richness of a hosted web app.
diff --git a/docs/content/en/showcase/1password-support/featured.png b/docs/content/en/showcase/1password-support/featured.png
new file mode 100644
index 000000000..8e46495e6
--- /dev/null
+++ b/docs/content/en/showcase/1password-support/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/1password-support/index.md b/docs/content/en/showcase/1password-support/index.md
new file mode 100644
index 000000000..2bcbff3fd
--- /dev/null
+++ b/docs/content/en/showcase/1password-support/index.md
@@ -0,0 +1,39 @@
+---
+
+title: 1Password Support
+date: 2018-02-22
+description: "Showcase: \"Compiles 400 pages in five languages in the blink of an eye.\""
+siteURL: https://support.1password.com/
+byline: "[Mitch Cohen](https://github.com/mitchchn), Documentation Team Lead"
+aliases: [/showcase/1password/]
+
+---
+
+At 1Password, we used to go through a different documentation platform every month: blog engines, ebooks, wikis, site generators written in Ruby and JavaScript. Each was inadequate in its own special way. Then we found **Hugo**. We made one last switch, and we're glad we did.
+
+### Not all static site generators are created equal
+
+Finding a tool that will make your customers, writers, designers, _and_ DevOps team happy is no easy task, but we managed it with Hugo:
+
+**Hugo is static**. We're a security company, so we swear by static sites and use them wherever possible. We feel much safer pointing customers at HTML files than at a complicated server which needs to be hardened.
+
+**Hugo is Go**. We love the Go programming language at 1Password, and we were delighted to learn that Hugo used the same Go template syntax that our designers and front-end developers had already mastered.
+
+**Hugo is FAST**. Our previous static site generator took nearly a minute to compile our (then much smaller) site. Developers might be used to this, but it wasn't cutting it for writers who wanted to see live previews of their work. Hugo did the same job in milliseconds, and to this day compiles 400 pages in five languages in the blink of an eye.
+
+**Hugo is flexible**. Thanks to Hugo's content and layout system, we were able to preserve our existing file and folder structure and port our entire production site in a few days. We could then create new content types that weren't possible before, like these snazzy [showcases](https://support.1password.com/explore/extension/).
+
+**Hugo is great for writers**. Our documentation team was already comfortable with Markdown and Git and could start creating content for Hugo with zero downtime. Once we added shortcodes, our writers were able to dress up articles with features like [platform boxes](https://support.1password.com/get-the-apps/) with just a bit of new syntax.
+
+**Hugo has an amazing developer community**. Hugo updates are frequent and filled to the brim with features and fixes. As we developed the multilingual version of our site, we submitted PRs for features we needed and were helped through the process by [@bep](https://github.com/bep) and others.
+
+**Hugo is simple to deploy**. Hugo has just the right amount of configuration options to fit into our build system without being too complicated.
+
+### Tech specs
+
+* [1Password Support](https://support.1password.com) uses Hugo with a custom theme. It shares styles and some template code with [1Password.com](https://1password.com), which we also moved to Hugo in 2016.
+* Code and articles live in a private GitHub repository, which is deployed to a static content server using Git hooks.
+* Writers build and preview the site on their computers and contribute content using pull requests.
+ * We use Hugo's [multilingual support](/content-management/multilingual/) to build the site in English, Spanish, French, Italian, German, and Russian. With the help of Hugo, 1Password Support became our very first site in multiple languages.
+* Our [contact form](https://support.1password.com/contact) is a single-page React app. We were able to integrate it with Hugo seamlessly thanks to its support for static files.
+* The one part of the support site which is not static is our search engine, which we developed with Elasticsearch and host on AWS.
diff --git a/docs/content/en/showcase/aether/bio.md b/docs/content/en/showcase/aether/bio.md
new file mode 100644
index 000000000..be1533367
--- /dev/null
+++ b/docs/content/en/showcase/aether/bio.md
@@ -0,0 +1,9 @@
+
+[**Aether**](https://getaether.net) is an open-source peer-to-peer network that hosts self-moderating online-communities.
+
+[**Aether Pro**](https://aether.app), based on Aether, is a collaboration tool for remote-friendly companies.
+
+The site is built by:
+
+* [Burak Nehbit](https://twitter.com/nehbit)
+
diff --git a/docs/content/en/showcase/aether/featured.png b/docs/content/en/showcase/aether/featured.png
new file mode 100644
index 000000000..509f938c7
--- /dev/null
+++ b/docs/content/en/showcase/aether/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/aether/index.md b/docs/content/en/showcase/aether/index.md
new file mode 100644
index 000000000..bd6116e8d
--- /dev/null
+++ b/docs/content/en/showcase/aether/index.md
@@ -0,0 +1,39 @@
+---
+
+title: Aether
+date: 2020-02-26
+description: "Showcase: \"Hugo is not just a static site generator for us, it's the core framework at the heart of our entire web front-end.\""
+
+# The URL to the site on the internet.
+siteURL: https://getaether.net
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+byline: "[Burak Nehbit](https://twitter.com/nehbit), Maintainer, Aether"
+
+---
+
+To say that this website, our main online presence, needed to do a lot would be an understatement.
+
+Our site is home to both *Aether* and *Aether Pro*, our **knowledgebase for each product**, a **server for static assets that we use in our emails**, the **interactive sign-up flows**, **payments client**, **downloads provider**, and even a **mechanism for delivering auto-update notifications** to our native clients. We are using a single Hugo site for all these — it's not a static site generator for us, it's the core framework at the heart of our *entire* web front-end.
+
+Not only that, this had to work with one developer crunched for time who spends most of his time working on two separate apps across 3 desktop platforms — someone whose main job is very far from building static websites. We only had scraps of time to design and build this Hugo site, make it performant and scalable, and Hugo did a phenomenal job delivering on that promise.
+
+The last piece is, funnily enough, moving our blog to Hugo, which it is not as of now. This was an inherited mistake we are currently rectifying. Soon, our entire web footprint will be living in Hugo.
+
+### Structure
+
+Our website is built in such a way that there is a separate Vue.js instance for each of the contexts since we are no using JS-based single-page navigation. We use Hugo for navigation and to build most pages. For the pages we need to make interactive, we use Vue.js to build individual, self-contained single-page Javascript apps. One such example is our sign-up flow at [aether.app](https://aether.app), an individual Vue app living within a Hugo page, with its own JS-based navigation.
+
+This is a relatively complex setup, and somewhat out of the ordinary. Yet, even with this custom setup, using Hugo was painless.
+
+### Tools
+
+**CMS**: Hugo
+
+**Theme**: Custom-designed
+
+**Hosting**: Netlify, pushed to production via `git push`.
+
+**Javascript runtime**: Vue.js
+
+
diff --git a/docs/content/en/showcase/arolla-cocoon/bio.md b/docs/content/en/showcase/arolla-cocoon/bio.md
new file mode 100644
index 000000000..dcccc8b50
--- /dev/null
+++ b/docs/content/en/showcase/arolla-cocoon/bio.md
@@ -0,0 +1,6 @@
+
+[Camping Arolla](https://www.camping-arolla.com) is located in the heart of the Swiss Alps, at an altitude of 1.950 meters.
+
+The site is built by:
+
+* [Didier Divinerites](https://github.com/divinerites)
diff --git a/docs/content/en/showcase/arolla-cocoon/featured-template.png b/docs/content/en/showcase/arolla-cocoon/featured-template.png
new file mode 100644
index 000000000..d95bc5c83
--- /dev/null
+++ b/docs/content/en/showcase/arolla-cocoon/featured-template.png
Binary files differ
diff --git a/docs/content/en/showcase/arolla-cocoon/index.md b/docs/content/en/showcase/arolla-cocoon/index.md
new file mode 100644
index 000000000..767f48269
--- /dev/null
+++ b/docs/content/en/showcase/arolla-cocoon/index.md
@@ -0,0 +1,29 @@
+---
+
+title: Cocoon & Cosy
+date: 2018-08-10
+description: "Showcase: \"Emergency setup a dedicated site in an afternoon.\""
+siteURL: https://www.cocoon-arolla.com
+byline: "[Didier Divinerites](https://github.com/divinerites)"
+
+---
+
+Swiss [Arolla campsite](https://www.camping-arolla.com) runs the highest campsite in Europe and I'm completely re-doing their actual Website with Hugo.
+
+But they just launch a brand new offer (luxury tents with bed and fire oven), and we couldn't wait for the proper new website for having this promoted: we needed the website up and running within 24h!
+
+So we decided to quickly launch a dedicated [independent web site](https://www.cocoon-arolla.com) using all the powerful tools included with [gohugo.io](https://gohugo.io) and some things we already knew & used:
+
+- Choose a spectacular landing theme in the rich [Hugo Themes](https://themes.gohugo.io/) collection : [Airspace Theme](https://themes.gohugo.io/airspace-hugo/) by Themefisher.
+- Replace the main images.
+- Add a [hugo-easy-gallery / photoswipe](https://github.com/liwenyip/hugo-easy-gallery) on the main page with attractive images.
+- Add the promo video with a simple *vimeo* shortcode.
+- Replace the Google Maps widget by the [OpenStreetMap](https://www.openstreetmap.org/) equivalent
+- Use a [Zotabox](https://www.zotabox.com) contact form.
+- Write the content in French & in English directly on the content pages, describe their services, add fun facts and true testimonies.
+- Setup a GDPR compliant site with the new Hugo options.
+- Use [Netlify](https://www.netlify.com) for publishing it in a breeze.
+
+The first version was up in 4 hours, and the polished 2 languages version was published on Netlify the next day.
+
+This would have been impossible to do it in such a short time without all the powerful Hugo tools and Netlify simplicity.
diff --git a/docs/content/en/showcase/bypasscensorship/bio.md b/docs/content/en/showcase/bypasscensorship/bio.md
new file mode 100644
index 000000000..6563e13ca
--- /dev/null
+++ b/docs/content/en/showcase/bypasscensorship/bio.md
@@ -0,0 +1,6 @@
+Bypass Censorship find and promote tools that provide Internet access to everyone.
+
+The site is built by:
+
+* [Leyla Avsar](https://www.leylaavsar.com/) (designer)
+* [Fredrik Jonsson](https://xdeb.net/) (dev) \ No newline at end of file
diff --git a/docs/content/en/showcase/bypasscensorship/featured.png b/docs/content/en/showcase/bypasscensorship/featured.png
new file mode 100644
index 000000000..d6f429112
--- /dev/null
+++ b/docs/content/en/showcase/bypasscensorship/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/bypasscensorship/index.md b/docs/content/en/showcase/bypasscensorship/index.md
new file mode 100644
index 000000000..a266797ea
--- /dev/null
+++ b/docs/content/en/showcase/bypasscensorship/index.md
@@ -0,0 +1,24 @@
+---
+title: Bypass Censorship
+date: 2019-06-16
+description: "Showcase: Bypass Censorship find and promote tools that provide Internet access to everyone."
+siteURL: https://www.bypasscensorship.org/
+byline: "[Fredrik Jonsson](https://xdeb.net/), Web developer & Linux sysadmin"
+
+---
+
+The British Broadcasting Corporation (BBC) (UK), Deutsche Welle (DW) (Germany), France Médias Monde (FMM) (France), the U.S. Agency for Global Media (USAGM) (US) and the Open Technology Fund (OTF) (US) co-sponsor the Bypass Censorship website.
+
+Websites of international news agencies are often blocked in many countries. In order to connect people to these sites, Bypass Censorship feature and recommend tools in the following languages: English, French, Spanish, Arabic, Farsi, Chinese, and Russian.
+
+One of the tools is the Bypass Censorship Extension for Firefox and Chrome. The extension help direct people to mirrors of partners sites if they are being censored.
+
+The first version of the site was built in Drupal 8 but it was relaunched as a static site built with Hugo in 2019.
+
+Security, page load time and easy of hosting is the main reasons for switching to a static site. As the lead developer I had good experience with Hugo and was interested in exploring the multilingual features.
+
+It's a simply site, basically one page in seven languages. I had no problems getting Hugo to output what I wanted. Found the multilingual support straight forward and easy to work with.
+
+Thanks to the design by [Leyla Avsar](https://www.leylaavsar.com/) the site also looks good. I used the [Hugo Zen theme](https://github.com/frjo/hugo-theme-zen) with a few custom templates and the needed CSS.
+
+The editors can maintain content via [Forestry.io CMS](https://forestry.io/) or directly via Git. Forestry does unfortunately not have multilingual support. All the language versions are in one pile making it harder to find the right file to edit, but it works. \ No newline at end of file
diff --git a/docs/content/en/showcase/digitalgov/bio.md b/docs/content/en/showcase/digitalgov/bio.md
new file mode 100644
index 000000000..db3ffafaf
--- /dev/null
+++ b/docs/content/en/showcase/digitalgov/bio.md
@@ -0,0 +1,2 @@
+
+**Digital.gov** helps people in the U.S. government deliver better, more accessible digital services through publishing essential guidance, resources, tools, and online events that make it easier for people to design, build, and deliver essential services for the public.
diff --git a/docs/content/en/showcase/digitalgov/featured.png b/docs/content/en/showcase/digitalgov/featured.png
new file mode 100644
index 000000000..5663180f9
--- /dev/null
+++ b/docs/content/en/showcase/digitalgov/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/digitalgov/index.md b/docs/content/en/showcase/digitalgov/index.md
new file mode 100644
index 000000000..63f44b645
--- /dev/null
+++ b/docs/content/en/showcase/digitalgov/index.md
@@ -0,0 +1,66 @@
+---
+title: Digital.gov
+date: 2020-05-01
+description: "Showcase: \"Guidance on building better digital services in government.\""
+siteURL: https://digital.gov/
+siteSource: https://github.com/gsa/digitalgov.gov
+---
+
+For over a decade, Digital.gov has provided guidance, training, and community support to the people who are responsible for delivering digital services in the U.S. government. Essentially, it is a place where people can find examples of problems being solved in government, and get links to the tools and resources they need.
+
+Through collaboration in our communities of practice, Digital.gov is a window into the people who work in technology in government and the challenges they face making digital services stronger and more effective. [Read more about our site »](https://digital.gov/2019/12/19/a-new-digitalgov/)
+
+Digital.gov is built using the [U.S. Web Design System](https://designsystem.digital.gov/) (USWDS) and have followed the [design principles](https://designsystem.digital.gov/maturity-model/) in building out our new site:
+
+- **Start with real user needs** — We used human-centered design methods to inform our product decisions (like qualitative user research), and gathered feedback from real users. We also continually test our assumptions with small experiments.
+- **Earn trust** —We recognize that trust has to be earned every time. We are including all [required links and content](https://digital.gov/resources/required-web-content-and-links/) on our site, clearly identifying as a government site, building with modern best practices, and using https.
+- **Embrace accessibility** — [Accessibility](https://digital.gov/resources/intro-accessibility/) affects everybody, and we built it into every decision. We’re continually working to conform to Section 508 requirements, use user experience best practices, and support a wide range of devices.
+- **Promote continuity** — We started from shared solutions like USWDS and [Federalist](https://federalist.18f.gov/). We designed our site to clearly identify as a government site by including USWDS’s .gov banner, common colors and patterns, and built with modern best practices.
+- **Listen** — We actively collect user feedback and web metrics. We use the [Digital Analytics Program](https://digital.gov/services/dap/) (DAP) and analyze the data to discover actionable insights. We make small, incremental changes to continuously improve our website by listening to readers and learning from what we hear.
+
+_More on the [USWDS maturity model »](https://designsystem.digital.gov/maturity-model/)_
+
+## Open Tools
+
+We didn’t start from scratch. We built and designed the Digital.gov using many of the open-source tools and services that we develop for government here in the [Technology Transformation Services](https://www.gsa.gov/tts/) (TTS).
+
+Using services that make it possible to design, build, and iterate quickly are essential to modern web design and development, which is why [Federalist](https://federalist.18f.gov/) and the [U.S. Web Design System](https://designsystem.digital.gov/) are such a great combination.
+
+**Why Hugo?** Well, with around `~3,000` files _(and growing)_ and `~9,000` built pages, we needed a site generator that could handle that volume with lightning fast speed.
+
+Hugo was the clear option. The [Federalist](https://federalist.18f.gov/) team quickly added it to their available site generators, and we were off.
+
+At the moment, it takes around `32 seconds` to build close to `~10,000` pages!
+
+Take a look:
+
+```bash
+
+ | EN
+-------------------+-------
+ Pages | 7973
+ Paginator pages | 600
+ Non-page files | 108
+ Static files | 851
+ Processed images | 0
+ Aliases | 1381
+ Sitemaps | 1
+ Cleaned | 0
+
+Built in 32.427 seconds
+
+```
+
+In addition to Hugo, we are proudly using a number of other tools and services, all built by government are free to use:
+
+- [Federalist](https://federalist.18f.gov/)
+- [Search.gov](https://www.search.gov/) — A free, hosted search platform for federal websites.
+- [Cloud.gov](https://www.cloud.gov/) — helps teams build, run, and authorize cloud-ready or legacy government systems quickly and cheaply.
+- [Federal CrowdSource Mobile Testing Program](https://digital.gov/services/mobile-application-testing-program/) — Free mobile compatibility testing by feds, for feds.
+- [Digital Analytics Program](https://digital.gov/services/dap/) (DAP) — A free analytics tool for measuring digital services in the federal government
+- [Section508.gov](https://www.section508.gov/) and [PlainLanguage.gov](https://www.plainlanguage.gov/) resources
+- [API.data.gov](https://api.data.gov/) — a free API management service for federal agencies
+- [U.S. Digital Registry](https://digital.gov/services/u-s-digital-registry/) — A resource for confirming the official status of government social media accounts, mobile apps, and mobile websites.
+
+
+**Questions or feedback?** [Submit an issue](https://github.com/GSA/digitalgov.gov/issues) or send us an email to [digitalgov@gsa.gov](mailto:digitalgov@gsa.gov) :heart:
diff --git a/docs/content/en/showcase/fireship/bio.md b/docs/content/en/showcase/fireship/bio.md
new file mode 100644
index 000000000..faf739bfa
--- /dev/null
+++ b/docs/content/en/showcase/fireship/bio.md
@@ -0,0 +1,6 @@
+
+**Fireship.io** is an ecosystem of detailed and practical resources for developers who want to build and ship high-quality apps.
+
+The site is built by:
+
+* [Jeff Delaney](https://fireship.io/contributors/jeff-delaney/)
diff --git a/docs/content/en/showcase/fireship/featured.png b/docs/content/en/showcase/fireship/featured.png
new file mode 100644
index 000000000..33d1a47c5
--- /dev/null
+++ b/docs/content/en/showcase/fireship/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/fireship/index.md b/docs/content/en/showcase/fireship/index.md
new file mode 100644
index 000000000..e9338a625
--- /dev/null
+++ b/docs/content/en/showcase/fireship/index.md
@@ -0,0 +1,17 @@
+---
+title: fireship.io
+date: 2019-02-02
+description: "Showcase: \"Hugo helps us create complex technical content that integrates engaging web components\""
+siteURL: https://fireship.io
+siteSource: https://github.com/fireship-io/fireship.io
+byline: "[Jeff Delaney](https://github.com/codediodeio), Fireship.io Creator"
+---
+
+After careful consideration of JavaScript/JSX-based static site generators, it became clear that Hugo was the only tool capable of handling our project's complex demands. Not only do we have multiple content formats and taxonomies, but we often need to customize the experience at a more granular level. The problems Hugo has solved for us include:
+
+- **Render speed.** We know from past experience that JavaScript-based static site generators become very slow when you have thousands of pages and images.
+- **Feature-rich.** Our site has a long list of specialized needs and Hugo somehow manages to cover every single use case.
+- **Composability.** Hugo's partial and shortcode systems empower us to write DRY and maintainable templates.
+- **Simplicity.** Hugo is easy to learn (even without Go experience) and doesn't burden us with brittle dependencies.
+
+The site is able to achieve Lighthouse performance scores of 95+, despite the fact that it is a fully interactive PWA that ships Angular and Firebase in the JS bundle. This is made possible by (1) prerendering content with Hugo and (2) lazily embedding native web components directly in the HTML and markdown. We provide a [detailed explanation](https://youtu.be/gun8OiGtlNc) of the architecture on YouTube and can't imagine development without Hugo.
diff --git a/docs/content/en/showcase/flesland-flis/bio.md b/docs/content/en/showcase/flesland-flis/bio.md
new file mode 100644
index 000000000..2fa6a7964
--- /dev/null
+++ b/docs/content/en/showcase/flesland-flis/bio.md
@@ -0,0 +1,8 @@
+
+A business page for Flesland Flis AS. A Norwegian Tiler located in Bergen.
+
+The page is designed and developed by Sindre Gusdal:
+
+* [Absoluttweb AS](https://www.absoluttweb.no)
+* [Sindre Gusdal](https://www.linkedin.com/in/sindregusdal/)
+
diff --git a/docs/content/en/showcase/flesland-flis/featured.png b/docs/content/en/showcase/flesland-flis/featured.png
new file mode 100644
index 000000000..a6dae684e
--- /dev/null
+++ b/docs/content/en/showcase/flesland-flis/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/flesland-flis/index.md b/docs/content/en/showcase/flesland-flis/index.md
new file mode 100644
index 000000000..935bb4661
--- /dev/null
+++ b/docs/content/en/showcase/flesland-flis/index.md
@@ -0,0 +1,24 @@
+---
+
+title: Flesland Flis AS
+date: 2018-04-24
+description: "showcase: Business Page for a tile shop in Bergen, Norway"
+siteURL: https://www.fleslandflis.no
+byline: "[Sindre Gusdal](https://www.absoluttweb.no), Absoluttweb AS"
+
+---
+
+For **Flesland Flis** I use a combination of **Hugo, Forestry.io and Netlify**. Static Site Generators and Hugo has been on my radar for a long time, and with all the nice features released in Hugo the last years, it's now my preferred solution for new clients. Also a huge thanks to the guys at [Forestry.io](https://forestry.io), for making such a smooth CMS for Hugo.
+
+The #1 reason why I love Hugo is the logic between content and layout, and of course the speed. Compared to solutions like Jekyll, Hugo is just better at all the stuff I value the most - speed, flexibility, theming and more.
+
+### Thanks, Hugo!
+
+Today I use Hugo in a combination with GULP and Foundation 6 + my own Hugo starter theme. This works great for me, and gives me all the flexibility I need. Then I can include FancyBox, Responsive Text and other Node Modules when needed.
+
+In the past I had to do a lot of changes to layout, content and css, if the client f.ex needed an extra PDF or an image-gallery to a certain page. Just small details not fitting in the template, would be a hassle. So updating existing webpages was boring and time consuming.
+
+Today I just copy-paste a new layout file, adds some frontmatter, Pushes to GIT and that special page is done.
+
+**Gotta love it:)**
+
diff --git a/docs/content/en/showcase/forestry/bio.md b/docs/content/en/showcase/forestry/bio.md
new file mode 100644
index 000000000..767365cc0
--- /dev/null
+++ b/docs/content/en/showcase/forestry/bio.md
@@ -0,0 +1,5 @@
+
+Forestry.io is a Git-backed CMS (content management system) for websites and web products built using static site generators such as Hugo.
+
+Forestry bridges the gap between developers and their teams, by making development fun and easy, while providing powerful content management for their teams.
+
diff --git a/docs/content/en/showcase/forestry/featured.png b/docs/content/en/showcase/forestry/featured.png
new file mode 100644
index 000000000..1ee315e78
--- /dev/null
+++ b/docs/content/en/showcase/forestry/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/forestry/index.md b/docs/content/en/showcase/forestry/index.md
new file mode 100644
index 000000000..1a9c0faaa
--- /dev/null
+++ b/docs/content/en/showcase/forestry/index.md
@@ -0,0 +1,48 @@
+---
+title: Forestry.io
+date: 2018-03-16
+description: "Showcase: \"Seeing Hugo in action is a whole different world of awesome.\""
+siteURL: https://forestry.io/
+siteSource: https://github.com/forestryio/forestry.io
+---
+
+It was clear from the get-go that we had to go with a static site generator. Static sites are secure, performant, and give you 100% flexibility. At [Forestry.io](https://forestry.io/) we provide Content Management Solutions for websites built with static site generators, so we might be a little biased. The only question: Which static site generator was the right choice for us?
+
+### Why Hugo?
+
+In our early research we looked at Ionic’s [site](https://github.com/ionic-team/ionic) to get some inspiration. They used Jekyll to build their website. While Jekyll is a great generator, the build times for larger sites can be painfully slow. With more than 150 pages plus many custom configurations and add-ons, our website doesn’t fall into the low-volume category anymore. Our developers want a smooth experience when working on the website and our content editors need the ability to preview content quickly. In short, we need our builds to be lightning fast.
+
+We knew Hugo was fast but we did [some additional benchmarking](https://forestry.io/blog/hugo-vs-jekyll-benchmark/) before making our decision. Seeing Hugo in action is a whole different world of awesome. Hugo takes less than one second to build our 150-page site! Take a look:
+
+```bash
+ | EN
++------------------+-----+
+ Pages | 141
+ Paginator pages | 4
+ Non-page files | 0
+ Static files | 537
+ Processed images | 0
+ Aliases | 60
+ Sitemaps | 1
+ Cleaned | 0
+
+Total in 739 ms
+```
+
+In fact, we liked Hugo so much that our wizard Chris made his workflow public and we started the open-source project [Create-Static-Site](https://github.com/forestryio/create-static-site). It's [a simple way to spin up sites](https://forestry.io/blog/up-and-running-with-hugo/) and set up a modern web development workflow with one line of code. Essentially it adds build configurations as a dependency for JS, CSS and Image Processing.
+
+Lastly, we want to take the opportunity to give some love to other amazing tools we used building our website.
+
+### What tools did we use?
+
+* Our Norwegian designer Nichlas is in love with [**Sketch**](https://www.sketchapp.com/). From what we hear it’s a designer’s dream come true.
+* Some say our main graphic is [mesmerizing](https://twitter.com/hmncllctv/status/968907474664284160). Nichlas created it using [**3DS Max**](https://www.autodesk.com/products/3ds-max/overview).
+* [**Hugo**](https://gohugo.io/) -- of course.
+* Chris can’t think of modern web development without [**Gulp**](https://gulpjs.com/) & [**Webpack**](https://webpack.js.org/). We used them to add additional build steps such as Browsersync, CSS, JS and SVG optimization.
+* Speaking about adding steps to our build, our lives would be much harder without [**CircleCI**](https://circleci.com/) for continuous deployment and automated testing purposes.
+* We can’t stop raving about [**Algolia**](https://www.algolia.com/). Chris loves it and even wrote a tutorial on [how to implement Algolia](https://forestry.io/blog/search-with-algolia-in-hugo/) into static sites using Hugo’s [Custom Outputs](https://gohugo.io/templates/output-formats/).
+* [**Cloudinary**](https://cloudinary.com/) is probably one of the easiest ways to get responsive images into your website.
+* We might be a little biased on this one - We think [**Forestry.io**](https://forestry.io/) is a great way to add a content management system with a clean UI on top of your site without interrupting your experience as a developer.
+* For hosting purposes we use the almighty [**AWS**](https://aws.amazon.com/).
+* [**Formspree.io**](https://formspree.io/) is managing our support and enterprise requests.
+* We also use browser cookies and JS to customize our user’s experience and give it a more dynamic feel. \ No newline at end of file
diff --git a/docs/content/en/showcase/hapticmedia/bio.md b/docs/content/en/showcase/hapticmedia/bio.md
new file mode 100644
index 000000000..4423edb70
--- /dev/null
+++ b/docs/content/en/showcase/hapticmedia/bio.md
@@ -0,0 +1 @@
+**Hapticmedia** provides interactive 3D configurators for eCommerce.
diff --git a/docs/content/en/showcase/hapticmedia/featured.png b/docs/content/en/showcase/hapticmedia/featured.png
new file mode 100644
index 000000000..a47ea9c2c
--- /dev/null
+++ b/docs/content/en/showcase/hapticmedia/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/hapticmedia/index.md b/docs/content/en/showcase/hapticmedia/index.md
new file mode 100644
index 000000000..b32879b69
--- /dev/null
+++ b/docs/content/en/showcase/hapticmedia/index.md
@@ -0,0 +1,33 @@
+---
+
+title: Hapticmedia Blog
+date: 2019-10-01
+description: "Showcase: \"A simple, but powerful, multilingual blog.\""
+siteURL: https://hapticmedia.fr/blog/en/
+byline: "[Cyril Bonnet](https://github.com/monsieurnebo), Web Developer"
+
+---
+
+Our goal was to create a simple, effective and multilingual blog on [3D technology](https://hapticmedia.fr/blog/en/3d-technology/) that could be managed by a non-technical profile.
+
+## Why Hugo?
+Hugo addresses all these needs, coupled with [Forestry.io](https://forestry.io/) for its administration via a "turnkey" interface. We have attached particular importance to SEO, and therefore to the creation of an advanced taxonomy system. Thus, each author and tag has a dedicated page, listing the related posts.
+
+
+## What we liked
+- The **multilingual** content support, especially simple to setup.
+- The **multiple environments** support (develop, staging, test, production, ...).
+- Although a hard start with the Go language, the power of the **Hugo's templating**.
+- The **partial layouts**, including the `internals` (e.g. social metas).
+- The **build time**, unbeatable ⚡️⚡️⚡️.
+
+
+## Tools & workflow
+- We used the same design as **[our website](https://hapticmedia.fr/en/)**, recreated as a Hugo HTML template.
+- **[Hugo](https://gohugo.io)** for the static website generator.
+- **[CircleCI](https://circleci.com)** for continuous integration & deployment.
+- **[AWS](https://aws.amazon.com/)** for web hosting.
+- **[Forestry.io](https://forestry.io)** for the content management.
+
+**All of these tools allow our editor to manage the blog's content without having to worry about its technical aspect, which is managed by the developers.**
+
diff --git a/docs/content/en/showcase/hartwell-insurance/bio.md b/docs/content/en/showcase/hartwell-insurance/bio.md
new file mode 100644
index 000000000..7fab74292
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/bio.md
@@ -0,0 +1,6 @@
+
+Hartwell Insurance is an insurance company set up solely to service the Broker community.
+
+By combining **Hugo**, **Service Worker** and **Netlify**, we were able to achieve incredible global site performance.
+
+The site was built by [Tomango](https://www.tomango.co.uk)
diff --git a/docs/content/en/showcase/hartwell-insurance/featured.png b/docs/content/en/showcase/hartwell-insurance/featured.png
new file mode 100644
index 000000000..ced251f98
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/hartwell-insurance/hartwell-columns.png b/docs/content/en/showcase/hartwell-insurance/hartwell-columns.png
new file mode 100644
index 000000000..c9d36b67d
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/hartwell-columns.png
Binary files differ
diff --git a/docs/content/en/showcase/hartwell-insurance/hartwell-lighthouse.png b/docs/content/en/showcase/hartwell-insurance/hartwell-lighthouse.png
new file mode 100644
index 000000000..a882f01fd
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/hartwell-lighthouse.png
Binary files differ
diff --git a/docs/content/en/showcase/hartwell-insurance/hartwell-webpagetest.png b/docs/content/en/showcase/hartwell-insurance/hartwell-webpagetest.png
new file mode 100644
index 000000000..f60994ea1
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/hartwell-webpagetest.png
Binary files differ
diff --git a/docs/content/en/showcase/hartwell-insurance/index.md b/docs/content/en/showcase/hartwell-insurance/index.md
new file mode 100644
index 000000000..925497949
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/index.md
@@ -0,0 +1,69 @@
+---
+
+title: Hartwell Insurance
+
+date: 2018-02-09
+
+description: "Showcase: \"Hugo + Netlify + PWA makes for a rapid website.\""
+
+siteURL: https://www.hartwell-insurance.com/
+
+byline: "[Trys Mudford](http://www.trysmudford.com), Lead Developer, Tomango"
+
+---
+
+We’ve just launched a shiny new website for [Hartwell Insurance](https://www.hartwell-insurance.com/) – I’m really proud of it. It was tackled in a different way to most previous Tomango site builds, using some fancy new tools and some vintage web standards.
+
+It’s a multi-page, single-page (!) website written in Hugo, a static site generator built with performance as a first-class feature. _I’ve outlined a load of benefits to Hugo & static sites [here](https://why-static.netlify.com/), in case you’re interested._
+
+> **In essence, a static site generator pre-renders the whole site into HTML files and serves them like it’s 1995.**
+
+There’s no Apache or Node backend that does compilation at runtime, it’s all done at the build step. This means the server; Netlify in this case, only has to do one thing – serve files. Unsurprisingly, serving simple files is VERY quick.
+
+The starter point was the [Victor Hugo](https://github.com/netlify/victor-hugo) repository that Netlify have created. It let me dive in with Hugo, PostCSS, BrowserSync and ES6 without setting up any tooling myself – always a win!
+
+I then took all the content from the design file and moved it into Markdown, putting shortcodes in where necessary. This site did need a number of custom shortcodes for the presentational elements like the expanding circles and full width backgrounds. But mostly it was just clean, semantic HTML with some CSS and JS enhancement thrown in.
+
+For example, this two column layout shown below. I used CSS Columns with a `break-after: always;` on the `<h1>`. No multi-wrapper or difficult-to-clear shortcodes, just clean HTML.
+
+![The multi-column setup on Hartwell Insurance](hartwell-columns.png)
+
+For the ripple effects on the section headings, I used JS to prepend a `<canvas>` element then animated it with `RequestAnimationFrame`. It adds a nice bit of movement on the page.
+
+On the Hartwell Profitmaker section, I toyed with the idea of using Vue.js for the calculator, but after giving it some thought, I decided to code in Vanilla. The result, all of the site JS comes in at 3.2KB!
+
+The plan was to host with Netlify and therefore get access to Netlify Forms. It meant spending 0 minutes on getting a backend set up – I could focus fully on the frontend.
+
+Cache invalidation isn’t normally something I spend all that much time thinking about when building a site. But as this site was going to be a Progressive Web App, invalidating files would be important to ensure the site didn’t appear broken when we made changes. As I was using Victor-Hugo, I wasn’t really sure how to best tackle this and sadly spent far too many hours wrangling with Webpack and Gulp files to try and get hashed file names working nicely.
+
+Then; while I was waiting for a haircut, I read a [Netlify blog post](https://www.netlify.com/blog/2017/02/23/better-living-through-caching/) on how they do cache invalidation with HTTP2 and it promptly blew my mind.
+
+When you request an asset, they send an ETag in the headers which is a hash of the file. There’s also a header to tell the browser not to trust it’s own cache (which sounds a little bit bonkers).
+
+So when you request the page, it opens a persistent HTTP2 connection up (so no new connections for file requests). When it gets to requesting that asset, the browser sends the ETag back to Netlify and they either return nothing if the ETag matches, or the new file with the new ETag. No `app.klfjlkdsfjdslkfjdslkfdsj.js` or `app.js?v=20180112`. Just a clean `app.js` with instant cache invalidation. Amazing.
+
+Finally, the [Service Worker](https://www.hartwell-insurance.com/sw.js) could be added. This turned out to be straightforward as the Netlify cache invalidation system solved most of the pain points. I went for a network-first, cache-fallback setup for both assets and HTML. This does mean flaky speeds are reliant on the page connection time, but given we’re on HTTP2, I’m hoping the persistent connection and tiny ETag size will keep it quick. For online connections, every request is up to date and instantly live after any update. Offline connections fall back to every assets’ last cached state. It seems to work really nicely, and there’s no need for an update prompt if assets have changed.
+
+---
+
+## The results
+
+The WebPageTest results are looking good. The speed index is 456, 10x smaller than the average Alexa top 300,000 score.
+
+![WebPageTest results](hartwell-webpagetest.png)
+
+[TestMySite.io](https://testmysite.io/5a7e1bb2df99531a23c9ad2f/hartwell-insurance.com) is return ~2ms time to first byte from the CDN edge nodes. Lighthouse audits are also very promising. There’s still some improvement to be gained lazy-loading the images and inlining the CSS. I’m less excited about the [second suggestion](http://www.trysmudford.com/css-in-2017/), but I’ll certainly look at some lazy-loading, especially as I’m already using `IntersectionObserver` for some animations.
+
+![Lighthouse results](hartwell-lighthouse.png)
+
+The most encouraging result is how quick the site is around the world. Most Tomango clients (and their customers) are pretty local and almost exclusively UK-based. We have a dedicated server in Surrey that serves our market pretty well. It did take me by surprise just how much slower a connection from the USA, Australia and Japan to our server was. They’re waiting ~500ms just for the first byte, let alone downloading each asset.
+
+[Hartwell Insurance](https://www.hartwell-insurance.com/) are a US company so by putting them on our server, we’d be instantly hampering their local response times by literally seconds. This was one of the main reasons for going with Netlify. They provide global CDN hosting that’s quick from anywhere in the world.
+
+---
+
+This project was such a blast to develop, it’s a real pleasure to put new technologies to good use in production, and to see real performance and usability benefits from them. Even using classic web methods of serving folders with files is fun when you’ve been databasing for a while – there’s something really ‘pure’ about it.
+
+---
+
+_This was originally posted on [my website](http://www.trysmudford.com/perfomance-wins-with-hugo-and-netlify/)_
diff --git a/docs/content/en/showcase/keycdn/bio.md b/docs/content/en/showcase/keycdn/bio.md
new file mode 100644
index 000000000..90f623dca
--- /dev/null
+++ b/docs/content/en/showcase/keycdn/bio.md
@@ -0,0 +1 @@
+[KeyCDN](https://www.keycdn.com) is a high performance content delivery network (CDN) offering many powerful features, including image processing that can transform and optimize images in real time. Our network offers global coverage to speed up content delivery and is capable of delivering entire static websites, like those built with Hugo, at the edge.
diff --git a/docs/content/en/showcase/keycdn/featured.png b/docs/content/en/showcase/keycdn/featured.png
new file mode 100644
index 000000000..46018a8f9
--- /dev/null
+++ b/docs/content/en/showcase/keycdn/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/keycdn/index.md b/docs/content/en/showcase/keycdn/index.md
new file mode 100644
index 000000000..d092aa07d
--- /dev/null
+++ b/docs/content/en/showcase/keycdn/index.md
@@ -0,0 +1,30 @@
+---
+
+title: KeyCDN
+date: 2020-04-10
+description: "Showcase: \"Hugo has become an integral part of our stack.\""
+siteURL: https://www.keycdn.com
+
+---
+
+At KeyCDN one of our primary focuses is on performance. With speed being ingrained in our DNA we knew from the start that we must use a fast static website generator that could meet our requirements. When evaluating the right solution, Hugo met our requirements and we looked no further as it was the fastest and most flexible.
+
+## Why we chose Hugo
+
+Before our migration to Hugo our website was powered by a PHP-based website that had about 50 pages and a WordPress website that had over 500 posts between our blog and knowledge base. This became harder to maintain as time continued. We felt like we were losing the speed and flexibility that we require. To overcome this we knew we needed to convert our website to be static. This would allow our website to be faster and more secure as it could be delivered by all of our edge locations.
+
+It wasn’t an easy task at the beginning, however, after evaluating Hugo and benchmarking it we knew we had found the ideal solution. Hugo was by far the fastest setup and offered an intuitive way to build our entire website exactly as needed. The Go-based templates, shortcodes, and configuration options made it easy to build a complex website.
+
+In the fall of 2018 we started the migration and within a couple short months we had built a custom static website with Hugo and migrated all content from our old systems. The simplicity and vast amount of functionality that Hugo offers made this process fast and left our entire team, including all of our writers and developers, happy with the migration. Since migrating to Hugo we haven’t looked back. Hugo has become an integral part of our stack. We’re grateful to all those who have contributed to make Hugo what it is today.
+
+## Technical overview
+
+Below is an overview of what we used with Hugo to build our website:
+
+* [KeyCDN](https://www.keycdn.com) uses a custom theme and is our primary hub for all style sheets and JavaScript. Our other websites, like [KeyCDN Tools](https://tools.keycdn.com), only import the required style sheets and JavaScript.
+* We use [Gulp](https://gulpjs.com) in our build process for many tasks, such as combining, versioning, and compressing our style sheets as well as our JavaScript.
+* Our search is powered by a custom solution that we’ve built. It allows our pages, blog, and knowledge base to be searched. It uses [Axios](https://github.com/axios/axios) to send a `POST` request containing the search query. An index file in JSON generated by Hugo is searched and the results are then returned.
+* Our commenting system is also powered by a custom solution that we’ve built. It uses Axios to send a `GET` request containing the slug to pull the comment thread and a `POST` request containing the name, email address, and comment when submitting a comment.
+* Our contact form is a simple HTML form, which uses Axios as well.
+* Our writers use shortcodes to enhance the capability of markdown.
+* Our entire website is delivered through KeyCDN using a Pull Zone, which means all of our edge locations are delivering our website.
diff --git a/docs/content/en/showcase/letsencrypt/bio.md b/docs/content/en/showcase/letsencrypt/bio.md
new file mode 100644
index 000000000..92551dc47
--- /dev/null
+++ b/docs/content/en/showcase/letsencrypt/bio.md
@@ -0,0 +1,3 @@
+
+
+Let's Encrypt is a free, automated, and open certificate authority (CA), run for the public's benefit. It is a service provided by the [Internet Security Research Group (ISRG)](https://www.abetterinternet.org/).
diff --git a/docs/content/en/showcase/letsencrypt/featured.png b/docs/content/en/showcase/letsencrypt/featured.png
new file mode 100644
index 000000000..9535d91bd
--- /dev/null
+++ b/docs/content/en/showcase/letsencrypt/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/letsencrypt/index.md b/docs/content/en/showcase/letsencrypt/index.md
new file mode 100644
index 000000000..8487a3c77
--- /dev/null
+++ b/docs/content/en/showcase/letsencrypt/index.md
@@ -0,0 +1,21 @@
+---
+title: "Let’s Encrypt"
+date: 2018-03-13
+description: "Showcase: Lessons learned from taking letsencrypt.org to Hugo."
+siteURL: https://letsencrypt.org/
+siteSource: https://github.com/letsencrypt/website
+byline: "[bep](https://github.com/bep), Hugo Lead"
+---
+
+The **Let’s Encrypt website** has a common set of elements: A landing page and some other static info-pages, a document section, a blog, and a documentation section. Having it moved to Hugo was mostly motivated by a _simpler administration and Hugo's [multilingual support](/content-management/multilingual/)_. They already serve HTTPS to more than 60 million domains, and having the documentation available in more languages will increase that reach.[^1]
+
+{{< tweet 971755920639307777 >}}
+
+I helped them port the site from Jekyll to Hugo. There are usually very few surprises doing this. I know Hugo very well, but working on sites with a history usually comes up with something new.
+
+That site is bookmarked in many browsers, so preserving the URLs was a must. Hugo's URL handling is very flexible, but there was one challenge. The website has a mix of standard and what we in Hugo call _ugly URLs_ (`https://letsencrypt.org/2017/12/07/looking-forward-to-2018.html`). In Hugo this is handled automatically, and you can turn it on globally or per language. But before Hugo `0.33` you could not configure it for parts of your site. You could set it manually for the relevant pages in front matter -- which is how it was done in Jekyll -- but that would be hard to manage, especially when you start to introduce translations. So, in [Hugo 0.33](https://gohugo.io/news/0.33-relnotes/) I added support for _ugly URLs_ per section and also `url` set in front matter for list pages (`https://letsencrypt.org/blog/`).
+
+The lessons learned from this also lead to [disableLanguages](/content-management/multilingual/#disable-a-language) in Hugo `0.34` (a way to turn off languages during translation). And I also registered [this issue](https://github.com/gohugoio/hugo/issues/4463). Once fixed it will make it easier to handle partially translated sites.
+
+
+[^1]: The work on getting the content translated is in progress.
diff --git a/docs/content/en/showcase/linode/bio.md b/docs/content/en/showcase/linode/bio.md
new file mode 100644
index 000000000..42fa92229
--- /dev/null
+++ b/docs/content/en/showcase/linode/bio.md
@@ -0,0 +1,4 @@
+
+**Linode** is a cloud hosting provider that offers high performance SSD Linux servers for your infrastructure needs.
+
+**Hugo** offers the documentation team incredible performance as we scale and continue providing quality Linux tutorials.
diff --git a/docs/content/en/showcase/linode/featured.png b/docs/content/en/showcase/linode/featured.png
new file mode 100644
index 000000000..8e517eacb
--- /dev/null
+++ b/docs/content/en/showcase/linode/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/linode/index.md b/docs/content/en/showcase/linode/index.md
new file mode 100644
index 000000000..5a341be8a
--- /dev/null
+++ b/docs/content/en/showcase/linode/index.md
@@ -0,0 +1,15 @@
+---
+title: Linode Docs
+date: 2018-02-12
+description: "Showcase: \"Hugo allows us to build thousands of pages in seconds.\""
+siteURL: https://linode.com/docs/
+siteSource: https://github.com/linode/docs
+---
+
+The documentation team at Linode has been writing guides since 2009, with the goal of helping new and experienced Linux users find the best tools and get the most out of their systems.
+
+As our library grew into thousands of guides, we needed a fast static site generator with intuitive templating and the flexibility to extend Markdown without constantly writing HTML and CSS.
+
+Hugo solved a lot of our growing pains with features like shortcodes, customizable URLs, LiveReload, and more. We have already brought our site build time down from minutes to just a few seconds, and we are excited to see what future developments in Hugo will bring.
+
+Thank you to all the [Hugo contributors](https://github.com/gohugoio/hugo/graphs/contributors) and especially [@bep](https://github.com/bep) for helping us with the adoption of Hugo.
diff --git a/docs/content/en/showcase/over/bio.md b/docs/content/en/showcase/over/bio.md
new file mode 100644
index 000000000..415668f9e
--- /dev/null
+++ b/docs/content/en/showcase/over/bio.md
@@ -0,0 +1,5 @@
+The site is built by:
+
+* [Lauren Waller](https://twitter.com/waller_texas)
+* [Wayne Ashley Berry](https://twitter.com/waynethebrain)
+
diff --git a/docs/content/en/showcase/over/featured-over.png b/docs/content/en/showcase/over/featured-over.png
new file mode 100644
index 000000000..7d1ba6060
--- /dev/null
+++ b/docs/content/en/showcase/over/featured-over.png
Binary files differ
diff --git a/docs/content/en/showcase/over/index.md b/docs/content/en/showcase/over/index.md
new file mode 100644
index 000000000..9640198db
--- /dev/null
+++ b/docs/content/en/showcase/over/index.md
@@ -0,0 +1,17 @@
+---
+title: Over
+date: 2018-09-12
+description: "Showcase: \"People from all disciplines contribute to our website; Hugo’s single static binary makes that possible.\""
+siteURL: https://madewithover.com/
+
+---
+
+At Over we're into creativity, and technology should not get in the way. We want it to be easy for everyone to create, and Hugo does the same for us. That's one of the reasons many of us are fond of using it.
+
+People from all disciplines contribute to our website, be it legal documentation, layout and design, recruiting, marketing and of course… engineering. Hugo allows us to do this with as little friction as possible. A lot of this comes down to Hugo being distributed as a single static binary. Copy, paste, run... and you're up and running!
+
+We use [Wercker](https://www.wercker.com/) for continuous integration and deployments, [GitHub](https://github.com/) for contributing to and writing markdown and [Firebase](https://firebase.google.com/docs/hosting/) for hosting.
+
+This infrastructure takes all the pressure off our engineers, anyone can contribute to our website. Anyone else can review the changes, and of course anyone with permission can deploy those approved changes as well!
+
+We're busy working on a few new features for our website, and Hugo continues to deliver above and beyond. We're so happy with the choice we made to use Hugo and to us it has become the de-facto static site generator. \ No newline at end of file
diff --git a/docs/content/en/showcase/pace-revenue-management/bio.md b/docs/content/en/showcase/pace-revenue-management/bio.md
new file mode 100644
index 000000000..7c7cc9c1c
--- /dev/null
+++ b/docs/content/en/showcase/pace-revenue-management/bio.md
@@ -0,0 +1,4 @@
+
+Pace was started in 2016 to give hotels the super-power to always have the right price.
+
+We've been using **Hugo+Gulp** from the very beginning and the workflow is proving to scale incredibly well with us as we grow the team and business.
diff --git a/docs/content/en/showcase/pace-revenue-management/featured.png b/docs/content/en/showcase/pace-revenue-management/featured.png
new file mode 100644
index 000000000..fa0948e5f
--- /dev/null
+++ b/docs/content/en/showcase/pace-revenue-management/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/pace-revenue-management/index.md b/docs/content/en/showcase/pace-revenue-management/index.md
new file mode 100644
index 000000000..092b86370
--- /dev/null
+++ b/docs/content/en/showcase/pace-revenue-management/index.md
@@ -0,0 +1,28 @@
+---
+
+title: Pace Revenue Management
+
+date: 2018-02-08
+
+description: "Showcase: \"When we came across Hugo we were blown away.\""
+
+siteURL: https://www.paceup.com/
+
+# Link to the site's Hugo source code if public and you can/want to share.
+# Remove or leave blank if not needed/wanted.
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+
+---
+
+From the beginning, at Pace, we were focused on solving customer needs and didn't want to over-engineer our marketing or sales. At the same time we didn't want to lock ourselves into a WordPress, Squarespace or the like.
+
+The ideal was a fast, simple, static site builder. When we came across Hugo we were blown away. Being a European company we wanted to be multi-lingual from the get-go and allow multiple team-members to collaborate and own their content. We also felt that a tech-company in 2018 should be capable of hosting its own blog in a simple way.
+
+Here was Hugo, that allowed us to completely separate content from layout. Our sales-team edit a markdown-file, the engineers commit and off we go -- immediately deployable or pre-viewable.
+
+The only other way to have all that Hugo offers is to go down the full rabbit-hole of building your own server-side React or some such. Possibly Jekyll but again very complex to work with. The alternatives come with too much work for what should be quite simple.
+
+**Hugo + Gulp + Netlify for the win! Don't over engineer your web presence!**
+
+Huge thanks to [@bep](https://github.com/bep) and [community](https://discourse.gohugo.io/) for Hugo.
diff --git a/docs/content/en/showcase/pharmaseal/bio.md b/docs/content/en/showcase/pharmaseal/bio.md
new file mode 100644
index 000000000..7477f1c32
--- /dev/null
+++ b/docs/content/en/showcase/pharmaseal/bio.md
@@ -0,0 +1,7 @@
+PHARMASEAL began in 2016 with the purpose of disrupting the Clinical Trials Management market through continuous validation and integration
+
+We've been using **Hugo + Webpack + Netlify** to provide a scalable, modular design for the website, complete with Forestry building blocks to quickly be able to generate engagement pages.
+
+The site is built by:
+
+- [Roboto Studio](https://roboto.studio)
diff --git a/docs/content/en/showcase/pharmaseal/featured-pharmaseal.png b/docs/content/en/showcase/pharmaseal/featured-pharmaseal.png
new file mode 100644
index 000000000..4a64325b7
--- /dev/null
+++ b/docs/content/en/showcase/pharmaseal/featured-pharmaseal.png
Binary files differ
diff --git a/docs/content/en/showcase/pharmaseal/index.md b/docs/content/en/showcase/pharmaseal/index.md
new file mode 100644
index 000000000..64e9960a3
--- /dev/null
+++ b/docs/content/en/showcase/pharmaseal/index.md
@@ -0,0 +1,37 @@
+---
+
+title: PHARMASEAL
+date: 2019-04-29
+
+description: "Pharmaseal website developed using Hugo, Forestry, hosted and deployed by Netlify."
+
+# The URL to the site on the internet.
+siteURL: https://pharmaseal.co/
+
+# Link to the site's Hugo source code if public and you can/want to share.
+# Remove or leave blank if not needed/wanted.
+
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+byline: "[Roboto Studio](https://roboto.studio), Jonathan Alford"
+
+---
+
+
+We wanted to shake the status quo with PHARMASEAL, opting for a fast and scalable website built with Hugo instead of slower monolithic systems the competitors were using.
+
+We had two goals:
+
+**Make it fast**
+
+We wanted to optimise the site as much as possible, so we opted for using Cloudinary, enabling us to take advantage of on-the-fly image manipulation, and thanks to the sheer speed of static sites, we achieved a perfect optimisation score with Google audits.
+
+Because we're hosting the site through Netlify and our target audience is in America, we are taking advantage of Netlify edge (Their alternative to a CDN). We're talking blazing fast.
+
+**Make it easy**
+
+We're big fans of simplicity, and that's what we delivered with the Forestry building blocks. Every element on the site is built with building blocks in mind, allowing PHARMASEAL to generate multiple pages in the blink of an eye.
+
+PHARMASEAL have found Forestry CMS combined with HUGO to be so effective at producing fast, purpose driven pages, that we have worked with them to add even more blocks in a scalable, modular fashion.
+
+**TLDR:** We're blown away with HUGO, the sheer speed, scalability and deployment possibilities with Netlify is the 💣 \ No newline at end of file
diff --git a/docs/content/en/showcase/quiply-employee-communications-app/bio.md b/docs/content/en/showcase/quiply-employee-communications-app/bio.md
new file mode 100644
index 000000000..f72a62554
--- /dev/null
+++ b/docs/content/en/showcase/quiply-employee-communications-app/bio.md
@@ -0,0 +1,4 @@
+**Quiply** is an employee communications app enabling mobile collaboration across an entire organization.
+Our customers get their own branded app enabling them to communicate fast and effectively with all employees, also non-desk and shift workers.
+
+As the Quiply app's build process is based on **Gulp**, we have started to build our company and product website using **Gulp + Hugo** which is super-fast and gives us exactly the flexibility we need.
diff --git a/docs/content/en/showcase/quiply-employee-communications-app/featured.png b/docs/content/en/showcase/quiply-employee-communications-app/featured.png
new file mode 100644
index 000000000..a4e9f046e
--- /dev/null
+++ b/docs/content/en/showcase/quiply-employee-communications-app/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/quiply-employee-communications-app/index.md b/docs/content/en/showcase/quiply-employee-communications-app/index.md
new file mode 100644
index 000000000..a8c31cc33
--- /dev/null
+++ b/docs/content/en/showcase/quiply-employee-communications-app/index.md
@@ -0,0 +1,29 @@
+---
+
+# A suitable title for this article.
+title: Quiply Employee Communications App
+
+# Set this to the current date.
+date: 2018-02-13
+
+description: "\"It became immediately clear that we'd use Hugo going forward as it compiles super-fast, is intuitive to use and offers all the features we need.\""
+
+# The URL to the site on the internet.
+siteURL: https://www.quiply.com
+
+# Link to the site's Hugo source code if public and you can/want to share.
+# Remove or leave blank if not needed/wanted.
+# siteSource: https://github.com/gohugoio/hugoDocs
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+byline: "[Sebastian Schirmer](mailto:sebastian.schirmer@quiply.com), Quiply Co-Founder"
+
+---
+
+With the launch of our Employee Communications app Quiply we created a very simple and static one-page website to showcase our product.
+
+As our customer base and demand for marketing and communication started to grow, we needed a solution to easily grow and extend the contents of our web presence. As we do not have the need to serve dynamic content, we decided to use a static site generator. Amongst a couple of others, we tried Hugo and it became immediately clear that we'd use Hugo going forward as it compiles super-fast, is intuitive to use and offers all the features we need.
+
+Our website which we launched a couple of weeks ago is still growing and new content is being added constantly. By using Hugo, this can be easily done by content authors writing markdown files without always having to touch HTML or CSS code. It is available in German only for the time being, an English version is in the works.
+
+Huge thanks to everyone involved in making Hugo a success.
diff --git a/docs/content/en/showcase/small-multiples/bio.md b/docs/content/en/showcase/small-multiples/bio.md
new file mode 100644
index 000000000..3e0c1f14a
--- /dev/null
+++ b/docs/content/en/showcase/small-multiples/bio.md
@@ -0,0 +1,3 @@
+
+Small Multiples is a multidisciplinary team of data specialists, designers and developers that help people make the best use of their data, a journey that starts from strategy, to concepts, mock-ups, prototypes, design, and development.
+
diff --git a/docs/content/en/showcase/small-multiples/featured-small-multiples.png b/docs/content/en/showcase/small-multiples/featured-small-multiples.png
new file mode 100644
index 000000000..a278f464d
--- /dev/null
+++ b/docs/content/en/showcase/small-multiples/featured-small-multiples.png
Binary files differ
diff --git a/docs/content/en/showcase/small-multiples/index.md b/docs/content/en/showcase/small-multiples/index.md
new file mode 100644
index 000000000..e2b80ea9a
--- /dev/null
+++ b/docs/content/en/showcase/small-multiples/index.md
@@ -0,0 +1,47 @@
+---
+
+title: Small Multiples
+date: 2018-02-28
+description: "\"Hugo has excellent support and integration with Netlify and we were immediately blown away by how fast it was.\""
+siteURL: https://smallmultiples.com.au/
+byline: "[Small Multiples](https://smallmultiples.com.au/)"
+draft: true
+---
+
+Previously we had built and hosted our website with SquareSpace. Although SquareSpace was adequate for quickly showcasing our work, we felt it didn’t reflect our technical capabilities and the types of products we build for our clients.
+
+For many client applications, static front-end sites provide fast, scalable solutions that can easily connect with any back-end service, API or static data. We wanted to use the same processes and infrastructure that we use to host and deploy many of our products, so we felt that building a static site was the right solution for our website.
+
+Netlify is a hosting and deployment service that we use for many products. Our developers really like it because it has strong integration with GitHub and it works with the build tools we use such as Yarn and Webpack. It creates a production build every time we commit to our GitHub repository. This means we can share and preview every change internally or with clients.
+
+Application development has become increasingly complex and there is a strong motivation to simplify this process by avoiding complicated backends in favour of applications that consume static data and APIs (a JAMstack).
+
+Libraries like React make this easy, but we also wanted something that was server rendered. This led us to look at React based tools for static site generation such as GatsbyJS. We liked GatsbyJS, but in the end, we didn’t choose it due to the lack of availability of a simple CMS driven data source.
+
+For this, we considered Contentful. Contentful is a beautifully designed application. It’s basically a headless CMS, but it’s not specifically designed for websites and it becomes quite expensive at a commercial level. Their free tier is possibly a good option for personal sites especially with Gatsby. We also evaluated prose.io. This is a free service for editing markdown files in a GitHub repository. It works well, but it’s quite basic and didn’t provide the editing experience we were looking for.
+
+At the same time, we started exploring Hugo. Hugo is a static site generator similar to Jekyll, but it’s written in Go. It has excellent support and integration with Netlify and we were immediately blown away by how fast it was.
+
+We had been closely following the redevelopment of the Smashing Magazine website. We knew this was being powered by Hugo and Netlify and this showed us that Hugo could work for a large scale sites.
+
+The deciding factor, however, was the availability of CMS options that integrate well with Hugo. Netlify has an open source project called NetlifyCMS and there are also hosted services like Forestry.io. These both provide a CMS with an editing interface for markdown files and images. There is no database, instead, changes are committed directly back into the GitHub repository.
+
+In the end, we chose Hugo on Netlify, with Forestry as our CMS. The site is built and redeployed immediately with Netlify watching for changes to the GitHub repository.
+
+Was this the right choice? For us, yes, but we learnt a few things along the way.
+
+The Hugo templating language was very powerful, although also frustrating at times. The queries used to filter list pages are concise but difficult to read. Although it’s easy to get started, Hugo can have a significant learning curve as you try to do more complicated things.
+
+Hugo has particular expectations when it comes to CMS concepts like tags, categories, RSS, related content and menus. Some parts of our initial design did not match perfectly with how these work in Hugo. It took some time to figure out how to make things work the way we wanted without losing all the benefits of structured content.
+
+There were a few teething issues. We picked some relatively new technologies and as a result, we encountered some bugs. We were forced to find some workarounds and logged some issues with Hugo during the course of development. Most of these were fixed and features were added with releases happening frequently over the time we were working on the project. This can be exciting but also frustrating. We can see Hugo is developing in the right direction.
+
+NetlifyCMS was also very new when we first looked at it and this is partly why we opted for Forestry. Forestry is an excellent choice for an out-of-the-box CMS and it needs very little code configuration. It provided a better editing experience for non-technical users. I would still say this is true, but it also provides fewer options for customisation when compared with NetlifyCMS.
+
+Fortunately, the site is more portable now than it was, or would have been with a dynamic CMS like WordPress, or a fully hosted service like SquareSpace. It should be comparatively easy to swap the publishing functions from Forestry to NetlifyCMS or to change the templates. No part of the pipe-line is tightly coupled, the hosting, the CMS and the templates and the build process can all be updated independently, without changing anything else.
+
+We have complete control over the design and mark-up produced. This means we can implement a better responsive design and have a stronger focus on accessibility and performance.
+
+These technology choices gave us a good performance baseline. It was important to implement a site that took advantage of this. As a data visualisation agency, it can be difficult to optimise for performance with a small bundle size, while also aiming for high-quality visuals and working with large datasets. This meant we spent a lot of time optimising assets making sure there was little blocking the critical path for faster rendering and lazy-load images and videos.
+
+The end result is a high performance site. We think this could have been achieved with GatsbyJS, Hugo or any another static site generator. However, what was important was the decision to use static infrastructure for speed, security, flexibility and hopefully a better ongoing development experience. If you are looking at choosing a static site generator or wondering whether a static is the right choice for you, we hope this has helped.
diff --git a/docs/content/en/showcase/stackimpact/bio.md b/docs/content/en/showcase/stackimpact/bio.md
new file mode 100644
index 000000000..e6206dd03
--- /dev/null
+++ b/docs/content/en/showcase/stackimpact/bio.md
@@ -0,0 +1,4 @@
+
+**StackImpact** is a production-grade performance profiler for production and development environments.
+
+The [stackimpact.com](https://stackimpact.com/) website is built with awesome Hugo. Grunt is used for CSS minification and bundling. \ No newline at end of file
diff --git a/docs/content/en/showcase/stackimpact/featured.png b/docs/content/en/showcase/stackimpact/featured.png
new file mode 100644
index 000000000..49a3bc500
--- /dev/null
+++ b/docs/content/en/showcase/stackimpact/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/stackimpact/index.md b/docs/content/en/showcase/stackimpact/index.md
new file mode 100644
index 000000000..fcfcb1157
--- /dev/null
+++ b/docs/content/en/showcase/stackimpact/index.md
@@ -0,0 +1,16 @@
+---
+title: StackImpact
+date: 2018-02-20
+description: "\"Hugo is a perfect choice for a product website.\""
+siteURL: https://stackimpact.com/
+---
+
+After gradually handing over the control of our website to WordPress plugins, we realized that we needed to act.
+
+Static web sites have natural advantages such as security, performance and content versioning (e.g. with Git). Static site generators such as Hugo made static websites cool again. Importantly, the best practices of software development (e.g. peer reviews, multi-stage deployments, rollbacks) can now be easily applied to websites.
+
+Besides the blog and documentation sections, our website needed custom sections with own templates. Hugo supported it beautifully.
+
+Hugo is written in Go language and uses Go templates. StackImpact is a performance profiler that has an advanced support for Go applications. Being aware of the advantages of Go in terms of speed and productivity, this was another strong reason for choosing Hugo.
+
+Thanks to all Hugo contributors for making such a beautiful and fast site generator!
diff --git a/docs/content/en/showcase/template/bio.md b/docs/content/en/showcase/template/bio.md
new file mode 100644
index 000000000..597163340
--- /dev/null
+++ b/docs/content/en/showcase/template/bio.md
@@ -0,0 +1,8 @@
+
+Add some **general info** about the site here.
+
+The site is built by:
+
+* [Person 1](https://example.com)
+* [Person 1](https://example.com)
+
diff --git a/docs/content/en/showcase/template/featured-template.png b/docs/content/en/showcase/template/featured-template.png
new file mode 100644
index 000000000..4f390132e
--- /dev/null
+++ b/docs/content/en/showcase/template/featured-template.png
Binary files differ
diff --git a/docs/content/en/showcase/template/index.md b/docs/content/en/showcase/template/index.md
new file mode 100644
index 000000000..06e4a6548
--- /dev/null
+++ b/docs/content/en/showcase/template/index.md
@@ -0,0 +1,22 @@
+---
+
+title: Hugo Showcase Template
+date: 2018-02-07
+description: "A short description of this page."
+siteURL: https://gohugo.io/
+siteSource: https://github.com/gohugoio/hugoDocs
+byline: "[bep](https://github.com/bep), Hugo Lead"
+
+---
+
+Have a **notable Hugo site[^1]**? We would love to feature it in this **Showcase Section**
+
+We would really appreciate if you could:
+
+1. Fork https://github.com/gohugoio/hugoDocs
+2. Run `hugo new showcase/your-site` (this requires >= Hugo 0.49). This will use the archetype bundle in the [docs repo](https://github.com/gohugoio/hugoDocs/tree/master/archetypes).
+3. Follow the instructions in the newly created page bundle.
+3. Create a new pull request in https://github.com/gohugoio/hugoDocs/pulls
+
+
+[^1]: We want this to show Hugo in its best light, so this is not for the average Hugo blog. In most cases the answer to "Is my site [notable](https://www.dictionary.com/browse/notable)?" will be obvious, but if in doubt, create an [issue](https://github.com/gohugoio/hugoDocs/issues) with a link and some words, and we can discuss it. But if you have a site with an interesting Hugo story or a company site where the company itself is notable, you are most welcome.
diff --git a/docs/content/en/showcase/tomango/bio.md b/docs/content/en/showcase/tomango/bio.md
new file mode 100644
index 000000000..052bd93cd
--- /dev/null
+++ b/docs/content/en/showcase/tomango/bio.md
@@ -0,0 +1,6 @@
+
+We help ambitious businesses grow by getting more of the customers they want.
+
+Our new site runs quickly, anywhere in the world, regardless of internet connectivity.
+
+The site was built by [Tomango](https://www.tomango.co.uk)
diff --git a/docs/content/en/showcase/tomango/featured.png b/docs/content/en/showcase/tomango/featured.png
new file mode 100644
index 000000000..d4b037e0f
--- /dev/null
+++ b/docs/content/en/showcase/tomango/featured.png
Binary files differ
diff --git a/docs/content/en/showcase/tomango/index.md b/docs/content/en/showcase/tomango/index.md
new file mode 100644
index 000000000..5252c02a8
--- /dev/null
+++ b/docs/content/en/showcase/tomango/index.md
@@ -0,0 +1,29 @@
+---
+
+title: Tomango
+
+date: 2018-05-04
+
+description: "Showcase: \"Tomango site relaunch: Building our JAMstack site\""
+
+siteURL: https://www.tomango.co.uk
+
+siteSource: https://github.com/trys/tomango-2018
+
+byline: "[Trys Mudford](http://www.trysmudford.com), Lead Developer, Tomango"
+
+---
+
+Hugo is our static site generator (SSG) of choice. It's **really quick**. After using it on a number of [client projects](/showcase/hartwell-insurance/), it became clear that our new site _had_ to be built with Hugo.
+
+The big benefit of an SSG is how it moves all the heavy lifting to the build time.
+
+For example in WordPress, all the category pages are created at runtime, generating a lot of database queries. In Hugo, the paginated category pages are created at build time - so all the computational complexity is done once, and doesn't impact the user at all.
+
+Similarly, instead of running a live, or even a heavily cached Instagram feed that checked for new photos on page load, we used IFTTT to flip the feature to work performantly. I've [written about it](https://www.trysmudford.com/blog/making-the-static-dynamic-instagram-importer/) in detail on my blog but in essence: IFTTT sends a webhook to a Netlify Cloud Function every time a photo is uploaded. The function scrapes the photo and commits it to our GitHub repo which triggers a Hugo build on Netlify, deploying the site immediately!
+
+Shortcodes allow copy editors to continue using WordPress-esque features, Markdown keeps our developers happy, and our users don't have any of the database overheads. It's win-win!
+
+---
+
+This is an extract from our [technical launch post](https://www.tomango.co.uk/thinks/tomango-progressive-web-app/).