Prospectus are a third-sector recruitment business. Their website provides job search opportunities as well as providing bespoke recruitment handling for their clients.

Having previously gone through a website re-design and rebuild, Larkswood Digital took over ongoing support and maintenance of the website.

Technologies used

  • Umbraco CMS
  • Razor templating
  • Service Stack
  • Third party APIs
  • Geolocation
  • Team City
  • Git

Introductions, Research and Design

The current site exists because of the strong groundwork laid down by the team at Pretty, which at the time included members of the LD team. When Pretty closed up shop, LD had the knowledge to ensure a smooth handover. Below we describe the technical input that the LD team had in the original project and what we've done since. For more background on the research and design that went into the project, you can see this at

Technical background

When we review the requirements for a project we like to understand the client's current systems. The data, processes, and what problems they need to solve. For Prospectus, one issue was the rigidity of their existing system that made it difficult to make the improvements they wanted.

With this in mind, we set about identifying the solutions that best fit their needs. With a new project, choices range from the modern darlings of node.js, python or ruby, or opting for old favourites like .NET or even PHP. In the end, we chose .NET because the Prospectus team were familiar with Microsoft technologies. One of the aims was to provide a final solution that Prospectus could take ownership when they were ready to do so.

We then picked a Content Management System (CMS) built with that framework. There were a few options, but in the end selected Umbraco. It has been around long enough that it’s stable, well documented, and open source. All things we’d look for when choosing a framework or system to keep cost and time low.

Not only was it easy to customise by the development team, but it was also easy to work with as a user. Adding content was quite intuitive and Prospectus’ team could pick it up and go with it too. It gave us the freedom to build and customise to the brief.

To ensure the site was responsive, we used Zurb Foundation framework for building the front end. Being able to use the site on mobile would allow candidates to search for jobs while commuting. Or on a device that wasn’t linked to their existing employer.

Streamlining processes

One of the things we wanted to achieve was to make their processes more fluid by cutting out any middlemen. Their old system had a convoluted way of sending data from the website to their internal system and back again. We automated and streamlined some of these processes, reducing some of the human interactions needed. This saves Prospectus time and money.

The right amount of flexibility

It's best practice to build a system to do what it needs to do right now. Building things you think they might need further down the line tends to result in wasted effort. Two well known software development principles are “You Ain't Gonna Need It” (YAGNI) and "Keep It Simple, Stupid" (KISS). They stop you building redundant flexibility and reduces scope creep, meaning deadlines are kept. But it's still worth thinking a little about certain possibilities so that you can minimise problems later.

One of the factors we had to consider was whether to store job and candidate as Umbraco data types or as custom data. In the end, we chose to keep it separate from Umbraco content. This gave us more flexibility for planned partnerships with third party aggregators and providers of job data. We wanted to make any future integrations with third parties as painless as possible.

We built the job search and candidate system using a Service Orientated Architecture (SOA) approach. meaning we're also taking the first step in providing a public API at a later date.

Optimising & testing

Logging was also an important thing to have from the outset. It gave us the tools we needed to identify where a problem occurred if something went wrong. With that in place, we were able to do a fair bit of optimisation. Some of which we were able to do up front during the initial testing phase as more testers began to use the system. A "soft launch" would not possible as we were replacing an existing site that we had no access to. The site was so crucial to the business functioning that it was vital it worked when we switched the DNS. A significant period of testing the end-to-end processes identified any remaining issues we needed to fix before we could go live.

But testing isn't just about finding and fixing bugs in code. Sometimes testing highlights issues with workflow, sometimes with usability. You don’t always pick up on some issues until a larger group of people start using it. But we were responsive and evaluated each bug report. Sometimes it was just a visitor using it in an unexpected way and just needed a tweak to a label to make it easier to use.

Ensuring smooth deployments and good habits

To provide ongoing maintenance of a project or have confidence in what you had over, you need a few things. Well documented and tested code, simple deployment processes, and a code base that is easy to work on.

For Prospectus, we set up a Team City install which is a continuous integration server. Team City monitors our changes and re-builds all project dependencies. It then runs tests to ensure the projects still work at the most fundamental level.

Another use of Team City is to perform a degree of code review. At LD we have an enforced house style. Some might feel this is overkill and can be annoying at first. But following a standard soon becomes second nature to a team. The result is that all team members understand the intention of code quicker when it has a consistent style.

The code review also identifies missing test coverage, missing documentation and poor coding practices. These things are vital when in a team but you also tend to benefit from it yourself. Quite often you come back to code you've written yourself, months later, and wonder what it was supposed to be doing. In existing code, we like to follow a "Boy Scout" rule, always committing something in a better state than you find it. This approach benefits the whole team.

Finally, we're able to package up those changes in a production-ready format, ready to deploy to the live environment. Automating some of these processes reduces the risk of error and makes it easier to change things often.

The outcome

Prospectus were impressed by the fact that there were no problems when they switched over. When the site went live, it worked, and people were applying for jobs without hitting any issues. Due, in equal measure, to the planning, the coding and the testing before it went live.

We managed to build a site that has pleased Prospectus and is easier for them to customise and move with the times. But mostly, it’s one that works better for the people who use it. And we know it just works because we’ve had SO much good feedback!

Visit the Prospectus site

Could you be our next success story?