Some variables declared using let make more sense as const. For instance, here:

if (!error && response.statusCode === 200) {
      let name = JSON.parse(body).results[0].name;
      let firstName = capitalise(name.first);
      let lastName = capitalise(name.last);
      return cb(null, `${firstName} ${lastName}`);
}

In this example, you are not reassigning any of those three variables, so may as well use const. It won't break your code to leave it as is, but would be better practice to change.

You've defined some view files (index.html, results-page.html). It may be worth storing them in a directory called 'views', so in the server.views configuration you can set the path to 'public/views', just to keep things seperate

Original mockup

UX Prototype

links are not working

https://github.com/a-la-node/hapi-project/blob/master/src/identity.js#L43

Nice solution to this problem with your parallel function :) is there a reason why you're calling your callback with undefined in the error spot instead of null as in other functions? Not a big deal as they're both falsy but might as well be consistent.

For future reference, promises would be the other way to solve this problem, maybe Bluebird.props if you wanted the results in a nice object:

function getIdentity(type){
  return Promise.props({
    newName: getNewName(),
    newPlace: getNewPlace(type)
  })
}

getIdentity('witness').then(console.log) // { newName: 'someName', newPlace: 'somePlace' }

Not sure if you're meant to be using promises yet though!

return cb(null, randomCity.split('-').map(word => capitalise(word)).join(' '));

Perhaps join with a comma and a space, instead of just a space for formatting purposes.
So instead of this;

You'd get this;

... wait a minute, Ah.... that wouldn't work. hmmm...

https://github.com/a-la-node/hapi-project/blob/master/src/server.js#L69-L72

so that when you're testing your back-end code by requiring in server.js your server wont be started and you wont need to do server.stop()

https://github.com/a-la-node/hapi-project/blob/master/tests/server.test.js#L11

I think we can follow the example here to do our templates in the easiest way.

We need to create a user input field so we know weather to generate a male or female identity.

You could use let, lovely lovely let :)

https://github.com/a-la-node/hapi-project/blob/master/src/server.js#L53

I don't think you need to be calling server.register twice with the different plugins you're using - is there a reason you're doing it like this?

I think this would work just as well:

server.register([Vision, Inert], err => {
  // ... do all the stuff here

Heroku was working when the files were uploaded via git but not when directly from our Github. These are the error messages:

<div class="content overlay">
  <p> You are a...</p>
  <ul class="content--options">
    {{#each people}}
    {{{link this}}}
    {{/each}}
  </ul>
</div>

If content--options is dependent on content, it should be named content__options.

<div class="content overlay">
  <p> You are a...</p>
  <ul class="content__options">
    {{#each people}}
    {{{link this}}}
    {{/each}}
  </ul>
</div>

-- syntax is used for modifier rules, e.g. 'content__options--blue'.
See details about BEM naming conventions here

instead of just cheking that you don't get an error and the length is not zero, you can use mock responses and check actual values.

a description under the alt property on an image is needed for screen readers & co.

https://github.com/a-la-node/hapi-project/blob/master/public/index.html#L2